Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation

From: Dann Frazier <dann.frazier@canonical.com>
To: Michael Matz <matz@suse.de>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	linaro-dev <linaro-dev@lists.linaro.org>,
	"Alex Barcelo" <abarcelo@ac.upc.edu>,
	qemu-devel <qemu-devel@nongnu.org>,
	"linaro-toolchain@lists.linaro.org"
	<linaro-toolchain@lists.linaro.org>,
	"Alexander Graf" <agraf@suse.de>,
	"Wook Wookey" <wookey@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Christoffer Dall" <Christoffer.Dall@linaro.org>
Subject: Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Date: Thu, 27 Feb 2014 12:47:21 -0700	[thread overview]
Message-ID: <CALdTtnu_FGkH9e7ZYfORup5+=yDq=A-7OA3qkmbDsMPwfoVFog@mail.gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1402271403280.7694@wotan.suse.de>

[Adding Alex Barcelo to the CC]

On Thu, Feb 27, 2014 at 6:20 AM, Michael Matz <matz@suse.de> 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.