qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Matz
Subject: Re: [Qemu-devel] Call for testing QEMU aarch64-linux-user emulation
Date: Thu, 27 Feb 2014 14:20:34 +0100 (CET)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)

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.

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


Ciao,
Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]