[Adding Alex Barcelo to the CC] On Thu, Feb 27, 2014 at 6:20 AM, Michael Matz <m...@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. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
