Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()
On 3/19/10, Jamie Lokier wrote: > Blue Swirl wrote: > > But what if in addition to > > this, the user process forked and the other process ptraced the QEMU > > process, > > > How good is the cross-arch ptrace() emulation, anyway? :-) Probably as good as SIGABRT abuse support. But the case could be native as well, not cross-arch. Actually cross-arch execution of strace could be interesting. GDB not so much. UML?
Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()
Blue Swirl wrote: > But what if in addition to > this, the user process forked and the other process ptraced the QEMU > process, How good is the cross-arch ptrace() emulation, anyway? :-) -- Jamie
Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()
> The guest replacing one of QEMU's handlers with SIG_IGN or SIG_DFL would > be "fun", too. No idea whether that's actually possible; I know next to > nothing about user mode emulation. No, the guest program cannot replace QEMU's handlers; the host OS always sees host_signal_handler for all signals. But since host_signal_handler is used also for SIGABRT, after all this is not so obscure... Paolo
Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()
Jamie Lokier writes: > Markus Armbruster wrote: >> Paolo Bonzini writes: >> >> > On 03/15/2010 07:36 PM, Markus Armbruster wrote: >> >> Please don't tell me that user emulators make abort() return. abort() >> >> is declared __noreturn__, and the optimizer may well rely on that. >> > >> > If the user programs make a "signal (SIGABRT, SIG_IGN)" call, I >> > suppose abort() will return. >> >> I program doing that gets what it asks for, and richly deserves. > > A guest program is also allowed to trap SIGABRT with a signal handler, > and that does have some uses. E.g. cleaning up temporary files and > shmem segments following a crash when calling 3rd party code. I'd expect such handler not to return, but SIG_DFL, clean up, then re-raise the signal. Regardless, a guest program can do whatever it pleases, and that includes the stupid as well as the clever. But the guest's doings should never unduly interfere with QEMU's use of signals. > Whatever the guest does with SIGABRT, it should not result in _QEMU_ > crashing - whether due to abort() returning, or QEMU's control flow > jumping to the guest's signal handler from an unexpected location. Agreed. The guest replacing one of QEMU's handlers with SIG_IGN or SIG_DFL would be "fun", too. No idea whether that's actually possible; I know next to nothing about user mode emulation.
Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()
On 3/17/10, Paolo Bonzini wrote: > On 03/16/2010 06:55 PM, Jamie Lokier wrote: > > > A guest program is also allowed to trap SIGABRT with a signal handler, > > and that does have some uses. E.g. cleaning up temporary files and > > shmem segments following a crash when calling 3rd party code. > > > > Whatever the guest does with SIGABRT, it should not result in_QEMU_ > > crashing - whether due to abort() returning, or QEMU's control flow > > jumping to the guest's signal handler from an unexpected location. > > > > That's very hard to ensure however if QEMU was already in unstable state, > as witnessed by its call to abort(). Things can only go downhill. > > Maybe there should be a qemu_abort wrapper (and a QEMU_ASSERT companion) > that does simply abort/assert under system emulation, but under user-mode > emulation does > > signal (SIGABRT, SIG_DFL); > abort (); Fine, we cover this obscure corner case. But what if in addition to this, the user process forked and the other process ptraced the QEMU process, and when QEMU attempts to install the default signal handler, the call is instead diverted to somewhere else with ptrace?
Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()
On 03/16/2010 06:55 PM, Jamie Lokier wrote: A guest program is also allowed to trap SIGABRT with a signal handler, and that does have some uses. E.g. cleaning up temporary files and shmem segments following a crash when calling 3rd party code. Whatever the guest does with SIGABRT, it should not result in_QEMU_ crashing - whether due to abort() returning, or QEMU's control flow jumping to the guest's signal handler from an unexpected location. That's very hard to ensure however if QEMU was already in unstable state, as witnessed by its call to abort(). Things can only go downhill. Maybe there should be a qemu_abort wrapper (and a QEMU_ASSERT companion) that does simply abort/assert under system emulation, but under user-mode emulation does signal (SIGABRT, SIG_DFL); abort (); Paolo
Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()
Jamie Lokier writes: > Paolo Bonzini wrote: >> On 03/15/2010 07:36 PM, Markus Armbruster wrote: >> >Please don't tell me that user emulators make abort() return. abort() >> >is declared __noreturn__, and the optimizer may well rely on that. >> >> If the user programs make a "signal (SIGABRT, SIG_IGN)" call, I suppose >> abort() will return. > > On Linux, man abort says: > >If the SIGABRT signal is ignored, or caught by a handler that returns, >the abort() function will still terminate the process. It does this by >restoring the default disposition for SIGABRT and then raising the sig‐ >nal for a second time. > > However I have a suspicious that I've seen abort() return on some > other OS in the distant past, maybe SunOS 4. Dark age. > I wouldn't rely on abort() always terminating the process on all OSes. Such behavior is not permitted by ISO C: 7.20.4.1 The abort function [...] The abort function causes abnormal program termination to occur, unless the signal SIGABRT is being caught and the signal handler does not return. [...] The abort function does not return to its caller.
Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()
Markus Armbruster wrote: > Paolo Bonzini writes: > > > On 03/15/2010 07:36 PM, Markus Armbruster wrote: > >> Please don't tell me that user emulators make abort() return. abort() > >> is declared __noreturn__, and the optimizer may well rely on that. > > > > If the user programs make a "signal (SIGABRT, SIG_IGN)" call, I > > suppose abort() will return. > > I program doing that gets what it asks for, and richly deserves. A guest program is also allowed to trap SIGABRT with a signal handler, and that does have some uses. E.g. cleaning up temporary files and shmem segments following a crash when calling 3rd party code. Whatever the guest does with SIGABRT, it should not result in _QEMU_ crashing - whether due to abort() returning, or QEMU's control flow jumping to the guest's signal handler from an unexpected location. -- Jamie
Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()
Paolo Bonzini wrote: > On 03/15/2010 07:36 PM, Markus Armbruster wrote: > >Please don't tell me that user emulators make abort() return. abort() > >is declared __noreturn__, and the optimizer may well rely on that. > > If the user programs make a "signal (SIGABRT, SIG_IGN)" call, I suppose > abort() will return. On Linux, man abort says: If the SIGABRT signal is ignored, or caught by a handler that returns, the abort() function will still terminate the process. It does this by restoring the default disposition for SIGABRT and then raising the sig‐ nal for a second time. However I have a suspicious that I've seen abort() return on some other OS in the distant past, maybe SunOS 4. I wouldn't rely on abort() always terminating the process on all OSes. -- Jamie
Re: [Qemu-devel] Re: [PATCH, RFC] Replace assert(0) with abort() or cpu_abort()
Paolo Bonzini writes: > On 03/15/2010 07:36 PM, Markus Armbruster wrote: >> Please don't tell me that user emulators make abort() return. abort() >> is declared __noreturn__, and the optimizer may well rely on that. > > If the user programs make a "signal (SIGABRT, SIG_IGN)" call, I > suppose abort() will return. I program doing that gets what it asks for, and richly deserves.
