On 08/03/2012 02:54 PM, Anthony Liguori wrote: > Eduardo Otubo <ot...@linux.vnet.ibm.com> writes: > >> The new 'trap' (debug) mode will capture the illegal system call before it is >> executed. The feature and the implementation is based on Will Drewry's >> patch - https://lkml.org/lkml/2012/4/12/449 >>
>> + if (syscall_num < 0 || syscall_num >= __NR_syscalls) {
>> + if ((safe_warn("seccomp: error reading syscall from register\n") <
>> 0)) {
>> + return;
>> + }
>> + return;
>> + }
>> + int_to_asc(syscall_num, syscall_char);
>
> I assume you're doign this because of fear of signal safety? Is there a
> reason to believe that snprintf() wouldn't be signal safe? Even if it's
> not on the white list, the implementation can't reasonably rely on
> global data, can it?
Unfortunately snprintf can malloc (seriously! even in glibc), which
therefore involves not just global data, but a potential for deadlock
while handling the malloc locks. True, the situations in which snprintf
mallocs are limited to a subset of possible % directives, and while it
differs between libc implementations which set triggers questionable
behavior, you can at least argue that this seccomp code is heavily tied
to Linux and therefore an audit of the code path in glibc for your
particular format string will not malloc. But I'd rather not play those
sorts of games; it is easier to just follow the rule and stick to
async-signal-safe functions from within signal handlers, which rules out
the entire *printf family.
--
Eric Blake ebl...@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
