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

[Dann Frazier]

[Adding Alex Barcelo to the CC]

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