qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] seccomp breakage on arm


From: Peter Maydell
Subject: Re: [Qemu-devel] seccomp breakage on arm
Date: Fri, 10 Apr 2015 13:44:32 +0100

On 10 April 2015 at 00:46, Paul Moore <address@hidden> wrote:
> On Thursday, April 09, 2015 11:32:51 PM Peter Maydell wrote:
>> On 9 April 2015 at 22:27, Paul Moore <address@hidden> 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. 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 on other architectures. Otherwise every
project using seccomp has to manually say "don't try to use this
on non-x86". If seccomp failed to build on the other architectures
you'd find out about problems from distro packagers without unusable
packages escaping into the wild. (QEMU's use case doesn't seem to
be particularly complex so it would be possible to write a
compile-only seccomp test case that made sure SCMP_SYS(foo)
worked for every 'foo' seccomp has ever supported on any arch.)

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?

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]