Re: [Qemu-devel] seccomp breakage on arm

["Andreas Färber" <afaerber@suse.de>]

Am 10.04.2015 um 17:16 schrieb Paul Moore:
> On Friday, April 10, 2015 01:44:32 PM Peter Maydell wrote:
>> On 10 April 2015 at 00:46, Paul Moore <pmoore@redhat.com> wrote:
>>> On Thursday, April 09, 2015 11:32:51 PM Peter Maydell wrote:
>>>> On 9 April 2015 at 22:27, Paul Moore <pmoore@redhat.com> wrote:
>>>>> Regardless, I think I see what the problem is, and if I'm correct it
>>>>> affects time, umount, stime, alarm, utime, getrlimit, select, readdir,
>>>>> mmap, socketcall, syscall, and ipc.  I'm traveling at the moment so a
>>>>> patch may be a bit delayed, but I'll be sure to CC you on the fix in
>>>>> case
>>>>> you are able to do some testing.
>>>>
>>>> I was expecting seccomp 2.2.x to fix this by not requiring the
>>>> existence in particular of *any* __NR_* define.
>>>
>>> I'm sorry to tell you that it doesn't work that way.
>>>
>>>> If you don't make the header cope with any of them being missing then
>>>> this is going to continue to be fragile and liable to breakage on new
>>>> architectures into the future, I suspect :-(
>>>
>>> There are always going to be teething problems with support for new
>>> architectures, especially ones that I do not personally have in front of
>>> me for testing.
>>
>> I appreciate the testing issue, but ARM is not a new architecture.
>> 32-bit ARM has been around for decades, and 64-bit ARM now for
>> several years.
> 
> ARM support is relatively new to libseccomp; I assumed we all recognized that 
> ARM as an architecture/ABI has been around for some time.
> 
>> If in practice the only architecture you can test and support is i386/x86_64
>> then it might be better to ensure you only build for that, so distros don't 
>> auto-build and ship unusable versions of the library ... {snip}
> 
> Both your tone and unsolicited advice have been noted.
> 
>> It's not clear to me how the current APIs QEMU is using would
>> cope with trying to whitelist a new syscall that the system's
>> libseccomp didn't know about; presumably SCMP_SYS(fancy_new_thing)
>> will be a compile failure. Is there a runtime function we can
>> call to pass it a string "fancy_new_thing" so we can get a runtime
>> check on whether the syscall is supported by seccomp instead?
> 
> I would suggest looking at the libseccomp man pages and header file.  
> Admittedly our documentation could be better (what project couldn't improve on 
> their documentation?), but it should answer your questions about runtime 
> detection.
> 
> Also, if anyone even cares, I just committed a fix for the syscall problem 
> Andreas reported:
> 
> https://github.com/seccomp/libseccomp/commit/d1019115acdc8460c9a1f8a878768001a3c32431

Appreciated, I was already looking into patching our package.

Maybe it helps your understanding that Peter is about to release QEMU
v2.3.0, so everyone is on edge when build issues get found last minute.

My main concern - that you apparently misunderstood - was whether this
is a QEMU or a libseccomp issue. If it's on libseccomp's side then it's
less urgent for QEMU and any new configure checks are just candy IMO.

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)