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

From: Peter Maydell <peter.maydell@linaro.org>
To: Michael Matz <matz@suse.de>
Cc: linaro-dev <linaro-dev@lists.linaro.org>,
	"Dann Frazier" <dann.frazier@canonical.com>,
	"Alexander Graf" <agraf@suse.de>,
	"linaro-toolchain@lists.linaro.org"
	<linaro-toolchain@lists.linaro.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	"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: Fri, 14 Mar 2014 14:20:25 +0000	[thread overview]
Message-ID: <CAFEAcA-i_hV6DdtZphbY5XFMaGNBn6FjNS3RV7X36cty2A1TQw@mail.gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1402271403280.7694@wotan.suse.de>

On 27 February 2014 13:20, Michael Matz <matz@suse.de> wrote:
> 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 -

I've cleaned up these a bit (and added a bunch of missing
wrapper calls) and am testing them now. I'll post them to
qemu-devel when that's done.

> 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.

My rework opts to track with a flag whether SIGSEGV is blocked
by the guest or not; this is fairly straightforward.

> 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.

I don't bother to emulate to this level though -- if we get a guest
directed SIGSEGV and the target has it blocked then we assume it was
a from-the-kernel SEGV (ie guest dereferenced NULL or similar) and
treat it as the kernel force_sig_info() does: behave as if the
default SEGV handler was installed. This seems a reasonable compromise
since I assume people don't typically go around sending manual SEGVs
to other processes and threads.

thanks
-- PMM