Re: [Qemu-devel] [PATCHv3 1/5] seccomp: adding new syscalls (bugzilla 855162)

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

On 11/26/2012 04:48 PM, Paul Moore wrote:
> On Monday, November 26, 2012 03:41:00 PM Paul Moore wrote:
>> On Monday, November 26, 2012 02:59:21 PM Corey Bryant wrote:
>>> On 11/26/2012 12:08 PM, Paul Moore wrote:
>>>> On Monday, November 26, 2012 11:41:06 AM Corey Bryant wrote:
>>>>> On 11/21/2012 10:24 AM, Paul Moore wrote:
>>>>>> On Wednesday, November 21, 2012 11:20:44 AM Eduardo Otubo wrote:
>>>>>>> Hello folks,
>>>>>>>
>>>>>>> Does anyone had a chance to take a look at this? We would like to get
>>>>>>> this into the 1.3 release.
>>>>>>>
>>>>>>> Thanks again :)
>>>>>>
>>>>>> I way a bit delayed due to travel, but I started playing with it a bit
>>>>>> yesterday afternoon and unfortunately it still doesn't work for me
>>>>>> (using the same test/reproducer I documented in the RH BZ).  I've
>>>>>> tried running QEMU both via libvirt and the command line (using a
>>>>>> libvirt derived command line).
>>>>>>
>>>>>> I'm applying the patches to the F17 QEMU 1.2 package; there is some
>>>>>> minor fixup needed in the configure script but nothing major.
>>>>>>
>>>>>> What is further frustrating is that the debug code (patch 5/5) doesn't
>>>>>> seem to output the problematic syscall.  I wanted to investigate this
>>>>>> a bit more before responding, but with the holiday approaching
>>>>>> (Thanksgiving in the US), I'm not sure how much progress I'll be able
>>>>>> to make for the remainder of this week.  Sorry about that.
>>>>>>
>>>>>> If you have any further questions about how, or what, I'm testing,
>>>>>> just ask.
>>>>>
>>>>> Paul, Is your host 32 or 64-bit?
>>>>
>>>> 64-bit
>>>
>>> I'm having trouble recreating this.  I'm running a Fedora 17 64-bit host
>>> and a Fedora 17 64-bit guest with domain XML that mirrors yours.
>>>
>>> Here's the domain XML I'm using and the resulting QEMU command line:
>>>
>>> Domain XML:   http://pastebin.com/DWa4RQ1Y
>>> Command line: http://pastebin.com/2QTWsUhP
>>>
>>> I'm running with QEMU commit 8db972cfa469b4e4afd9c65e54e796b83b5ce3a2
>>> which is 1.2.0 with: (a) just the first patch applied, as well as with
>>> (b) all of this patch series applied.
>>>
>>> Any thoughts on what could be different?
>>
>> Like I said earlier, I'm running with the F17 QEMU 1.2 package,
>> qemu-1.2.0-16.fc18 to be exact, with Eduardo's patches applied on top.
>>
>> I'm currently testing another set of interim patches from Eduardo that was
>> sent off-list for testing (you were CC'd); hopefully that will resolve the
>> problem.
>
> Unfortunately, the latest patches from Eduardo met with the same fate.  Here
> is more detailed information on my system (HP DL160 G5, F17, 64-bit):
>
> # uname -r
> 3.6.7-4.fc17.x86_64
>
> [NOTE: standard F17 kernel]
>
> # rpm -qa | grep qemu
> qemu-kvm-tools-1.2.0-16.pm5.fc17.x86_64
> qemu-common-1.2.0-16.pm5.fc17.x86_64
> qemu-kvm-1.2.0-16.pm5.fc17.x86_64
> ipxe-roms-qemu-20120328-1.gitaac9718.fc17.noarch
> qemu-img-1.2.0-16.pm5.fc17.x86_64
> qemu-system-x86-1.2.0-16.pm5.fc17.x86_64
>
> [NOTE: the 'pm5' is my designation indicating the patched version]
>
> # ./qemu_seccomp.sh -sandbox off
> char device redirected to /dev/pts/0
> do_spice_init: starting 0.10.1
> spice_server_add_interface: SPICE_INTERFACE_MIGRATION
> spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
> spice_server_add_interface: SPICE_INTERFACE_MOUSE
> spice_server_add_interface: SPICE_INTERFACE_QXL
> red_worker_main: begin
> display_channel_create: create display channel
> cursor_channel_create: create cursor channel
> spice_server_add_interface: SPICE_INTERFACE_PLAYBACK
> spice_server_add_interface: SPICE_INTERFACE_RECORD
> [NOTE: I hit Ctrl-C at this point]
> qemu: terminating on signal 2
> spice_server_remove_interface: remove SPICE_INTERFACE_PLAYBACK
> spice_server_remove_interface: remove SPICE_INTERFACE_RECORD
>
> # ./qemu_seccomp.sh -sandbox on
> char device redirected to /dev/pts/0
> do_spice_init: starting 0.10.1
> spice_server_add_interface: SPICE_INTERFACE_MIGRATION
> spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
> spice_server_add_interface: SPICE_INTERFACE_MOUSE
> spice_server_add_interface: SPICE_INTERFACE_QXL
> red_worker_main: begin
> ./qemu_seccomp.sh: line 28: 21085 Bad system call         /usr/bin/qemu-kvm -S
> -M pc-0.14 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name f16-
> test-1 -uuid 13c7da9b-a79a-0688-267a-8206136bc8d6 -nodefconfig -nodefaults -
> chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/f16-
> test-1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control
> -rtc base=utc -no-shutdown -device virtio-serial-pci,id=virtio-
> serial0,bus=pci.0,addr=0x5 -device piix3-usb-
> uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/f16-
> test-1.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-
> pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-
> disk0,bootindex=1 -netdev user,id=hostnet0 -device virtio-net-
> pci,netdev=hostnet0,id=net0,mac=52:54:00:9a:9d:63,bus=pci.0,addr=0x3 -chardev
> pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev
> spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-
> serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -
> device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing
> -vga qxl -global qxl-vga.vram_size=67108864 -device intel-
> hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-
> codec0,bus=sound0.0,cad=0 -device virtio-balloon-
> pci,id=balloon0,bus=pci.0,addr=0x7 $*
>
> [NOTE: my test script, qemu_seccomp.sh, is attached]
>

Thanks for the additional details.  They were very useful.  I was able 
to reproduce this when I manually built spice release 0.10.1, but not 
with the Fedora 0.10.1 package.  One difference I noticed is that the 
Fedora version wasn't logging info messages.

Nonetheless, we'll send new patches soon.  It looks like the following 
were missing: epoll_create, epoll_wait, and epoll_ctl

-- 
Regards,
Corey Bryant