Re: [Qemu-devel] [PATCHv2 1/4] Adding new syscalls (bugzilla 855162)

[Paul Moore]

On Friday, November 02, 2012 10:43:41 AM Corey Bryant wrote:
> On 11/02/2012 10:38 AM, Paul Moore wrote:
> > On Friday, November 02, 2012 10:10:02 AM Paul Moore wrote:
> >> On Friday, November 02, 2012 09:48:55 AM Corey Bryant wrote:
> >>> On 11/01/2012 05:43 PM, Paul Moore wrote:
> >>>> On Tuesday, October 23, 2012 03:55:29 AM Eduardo Otubo wrote:
> >>>>> According to the bug 855162[0] - there's the need of adding new
> >>>>> syscalls
> >>>>> to the whitelist whenn using Qemu with Libvirt.
> >>>>> 
> >>>>> [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162
> >>>>> 
> >>>>> v2: Adding new syscalls to the list: readlink, rt_sigpending, and
> >>>>> 
> >>>>>       rt_sigtimedwait
> >>>>> 
> >>>>> Reported-by: Paul Moore <address@hidden>
> >>>>> Signed-off-by: Eduardo Otubo <address@hidden>
> >>>>> ---
> >>>>> 
> >>>>>    qemu-seccomp.c | 13 ++++++++++++-
> >>>>>    1 file changed, 12 insertions(+), 1 deletion(-)
> >>>> 
> >>>> I had an opportunity to test this patchset on a F17 machine using QEMU
> >>>> 1.2
> >>>> and unfortunately it still fails.  I'm using a relatively basic guest
> >>>> configuration running F16, the details are documented in the RH BZ that
> >>>> Eduardo mentioned in the patch description.
> >>> 
> >>> Paul, Here's the latest diff for the whitelist.  We're looking to get
> >>> the patches out in the next few days after a bit more testing.
> >> 
> >> Okay, thanks for the updated list ... I'm rebuilding QEMU right now and
> >> I'll report back with the results later today.
> > 
> > Sadly, no luck, it still fails.
> 
> Hmm, let me send you the current patch set off-line, which includes
> debug support to write the failing syscall out.  If you don't mind could
> you try it out?

Sure, no problem.

On a related note, I think it would be a *really* good idea to also submit the 
debug code upstream, just in a disabled state by default.  You could either 
bracket it with #ifdefs or get fancy and allow it at runtime with '-sandbox 
debug' or something similar.

-- 
paul moore
security and virtualization @ redhat