On 04/30/2013 12:24 PM, Paul Moore wrote:
On Monday, April 29, 2013 05:52:10 PM Corey Bryant wrote:
On 04/26/2013 05:07 PM, Paul Moore wrote:
[snip]
3. Debugging and/or learning mode - third party libraries still
have the
problem of interfering in the Qemu's signal mask. According to some
previous discussions, perhaps patch all external libraries that
mass up
with this mask (spice, for example) is a way to solve it. But not
sure
if it worth the time spent. Would like to hear you guys.
I think patching all the libraries is a losing battle, I think we
need to
pursue alternate debugging techniques.
I agree. It would be nice to have some sort of learning mode that
reported all denied syscalls on a single run, but signal handlers
doesn't seem like the right way. Maybe we could improve on this
approach, since it never gained traction:
https://lkml.org/lkml/2013/1/7/313
At least we can get a single denied syscall at a time today via the
audit log that the kernel issues. Eduardo, you may want to see if
there's a good place to document that for QEMU so that people know where
to look.
Lately I've been using the fact that the seccomp BPF filter result
generates
an audit log; it either dumps to syslog or the audit log (depending on
your
configuration) and seems to accomplish most of what we wanted with
SECCOMP_RET_INFO.
I'm always open to new/better ideas, but this has been working
reasonably well
for me for the past few months.
I think this feature would fits well on Qemu if we could have a "normal"
signal handling. But external libraries interfere a lot on this matter.
Paolo, am I the first one to complain about signal handling on Qemu
(being interfered by other libraries)? I believe this may cause some
trouble in other parts of the project as well. Wouldn't be this a good
time to, perhaps, just think about a signal handling refactoring?