From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ6vX-0003vp-F5 for qemu-devel@nongnu.org; Thu, 27 Feb 2014 14:47:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WJ6vT-0002RZ-4d for qemu-devel@nongnu.org; Thu, 27 Feb 2014 14:47:27 -0500 Received: from mail-we0-f175.google.com ([74.125.82.175]:63125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WJ6vS-0002Qq-VE for qemu-devel@nongnu.org; Thu, 27 Feb 2014 14:47:23 -0500 Received: by mail-we0-f175.google.com with SMTP id q59so3329229wes.34 for ; Thu, 27 Feb 2014 11:47:22 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <87sirhyi1b.fsf@linaro.org> <87txbnfuw1.fsf@linaro.org> Date: Thu, 27 Feb 2014 12:47:21 -0700 Message-ID: From: Dann Frazier Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Matz Cc: Peter Maydell , linaro-dev , Alex Barcelo , qemu-devel , "linaro-toolchain@lists.linaro.org" , Alexander Graf , Wook Wookey , =?ISO-8859-1?Q?Alex_Benn=E9e?= , Christoffer Dall [Adding Alex Barcelo to the CC] On Thu, Feb 27, 2014 at 6:20 AM, Michael Matz wrote: > Hi, > > On Wed, 26 Feb 2014, Dann Frazier wrote: > >> I've narrowed down the changes that seem to prevent both types of >> segfaults to the following changes that introduce a wrapper around >> sigprocmask: >> >> https://github.com/susematz/qemu/commit/f1542ae9fe10d5a241fc2624ecaef5f0948e3472 >> https://github.com/susematz/qemu/commit/4e5e1607758841c760cda4652b0ee7a6bc6eb79d >> https://github.com/susematz/qemu/commit/63eb8d3ea58f58d5857153b0c632def1bbd05781 >> >> I'm not sure if this is a real fix or just papering over my issue - > > It's fixing the issue, but strictly speaking introduces an QoI problem. > SIGSEGV must not be controllable by the guest, it needs to be always > deliverable to qemu; that is what's fixed. > > The QoI problem introduced is that with the implementation as is, the > fiddling with SIGSEGV is detectable by the guest. E.g. if it installs a > segv handler, blocks segv, then forces a segfault, checks that it didn't > arrive, then unblocks segv and checks that it now arrives, such testcase > would be able to detect that in fact it couldn't block SIGSEGV. > > Luckily for us, the effect of blocking SIGSEGV and then generating one in > other ways than kill/sigqueue/raise (e.g. by writing to NULL) are > undefined, so in practice that QoI issue doesn't matter. > > To fix also that latter part it'd need a further per-thread flag > segv_blocked_p which needs to be checked before actually delivering a > guest-directed SIGSEGV (in comparison to a qemu-directed SEGV), and > otherwise requeue it. That's made a bit complicated when the SEGV was > process-directed (not thread-directed) because in that case it needs to be > delivered as long as there's _any_ thread which has it unblocked. So > given the above undefinedness for sane uses of SEGVs it didn't seem worth > the complication of having an undetectable virtualization of SIGSEGV. Thanks for the explanation. >> but either way, are these changes reasonable for upstream submission? > > IIRC the first two commits (from Alex Barcelo) were submitted once in the > past, but fell through the cracks. Alex: are you interested in resubmitting these - or would you like me to attempt to on your behalf? -dann > > Ciao, > Michael.