On Thu, Mar 14, 2019 at 07:15:10AM -0400, Stefan Berger wrote: > On 3/14/19 5:59 AM, Daniel P. Berrangé wrote: > > On Wed, Mar 13, 2019 at 03:43:13PM -0400, Stefan Berger wrote: > > > Hello! > > > > > > If you have some feedback regarding a seccomp profile extension for > > > swtpm > > > for v0.2, please let me know. I created this github issue here: > > > > > > > > > https://github.com/stefanberger/swtpm/issues/115 > > > > > > > > > Basically the choice is whether to make the creation of the seccomp > > > profile > > > a default behavior or have the caller explicitly pass the '--seccomp > > > profile=default' on the command line, which then in turn would require > > > libvirt for example to check whether this current version of swtpm > > > supports > > > the feature either by swtpm version or by strstr() the help page. > > In QEMU we can't enable seccomp by default because its wide range of > > features means any default profile would be effectively useless. Libvirt > > knows that it uses a restricted set of QEMU features, so it can enable > > a more useful seccomp by default. > > > > I think swtpm won't have this complexity problem. Its functionality is > > relatively narrow & well understood & so it is practical to define a > > good seccomp profile & use that by default. So personally I'd merely > > provide an opt-out to turn it off unless you think this is likely to > > break something important. > > Thanks. What makes me a bit hesitant now to activate it is the fact that I > found several unexpected syscalls in places like openssl DRBG and glibc. The > latter for example uses some #define ARCH_FORK (iirc), which was not fork or > vfork but clone on F29. It will obviously break if it is something different > on another machine or if it runs into branches that I haven't exercised with > the limited coverage the test suite I have provides...
Yes, seccomp rules are arguably specific to the C library impl, though I'd expect most C impls are largely the same. The use of clone instead of fork is pretty long standing, as it is basically a more generalized API so there's little reason to use the old fork() syscall. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
