From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxQji-0005NO-Ul for qemu-devel@nongnu.org; Fri, 03 Aug 2012 18:52:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SxQjh-0007Ws-MQ for qemu-devel@nongnu.org; Fri, 03 Aug 2012 18:52:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxQjh-0007Wm-ET for qemu-devel@nongnu.org; Fri, 03 Aug 2012 18:52:49 -0400 Message-ID: <501C563A.1000101@redhat.com> Date: Fri, 03 Aug 2012 16:52:42 -0600 From: Eric Blake MIME-Version: 1.0 References: <87obmru25r.fsf@codemonkey.ws> In-Reply-To: <87obmru25r.fsf@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig495998B43328DF6602F57BB2" Subject: Re: [Qemu-devel] [PATCHv5 3/4] Adding qemu-seccomp-debug.[ch] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: pmoore@redhat.com, blauwirbel@gmail.com, wad@chromium.org, qemu-devel@nongnu.org, Eduardo Otubo This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig495998B43328DF6602F57BB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 08/03/2012 02:54 PM, Anthony Liguori wrote: > Eduardo Otubo writes: >=20 >> The new 'trap' (debug) mode will capture the illegal system call befor= e 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 >=3D __NR_syscalls) { >> + if ((safe_warn("seccomp: error reading syscall from register\= n") < 0)) { >> + return; >> + } >> + return; >> + } >> + int_to_asc(syscall_num, syscall_char); >=20 > 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. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig495998B43328DF6602F57BB2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJQHFY6AAoJEKeha0olJ0NqpSUH/A/4CVLi3AHU5X8lqCcSOYOC V+ADh2tukFTc66cCtS7zAnq2NSSlIk/Qyq86tlxJrGyseRMeYPnwVAZjH5zAcO1j iKgduT6E1SxYYFXMXUTpu9cCeXWKQC8GG8M4bH0HGaF7HEFpzyyhwOB7i1RbJk1u 2iZ/7/3i25RR923w1cAuCuScWt8EiBalJ8Z6BJnf7FFEOUOBUu7RMZwMhg3RpQcV KAiNFjt9JVU2AovV1yekcK+LzbFsxzT0V52cZoZ+gxcL565o0AGNGLh37vsSlaJj gtW8GoY9HGE6TJ5AMt3pRthyyjlJ1SQh15NHnFcxEdiqeh45M2qj6pK9FkaMZcY= =J6RO -----END PGP SIGNATURE----- --------------enig495998B43328DF6602F57BB2--