Am 07.06.2012 23:39, schrieb Martin Pärtel:
> On 06/08/2012 12:26 AM, Richard Weinberger wrote:
> 
>> Am 07.06.2012 22:59, schrieb Martin Pärtel:
>>> Signal handlers in UML guest processes now get correct siginfo_t fields
>>> for SIGTRAP, SIGFPE, SIGILL and SIGBUS. Specifically, si_addr and si_code
>>> are now correct where previously they were si_addr = NULL and si_code = 128.
>>
>> What exactly is broken?
>> In my SIGSEGV test case si_addr is not NULL, it contains the correct faulting address.
>>
> 
> 
> SIGSEGV is probably fine. At least SIGFPE is not. Test program below.
> 
>>> +
>>> +            ptrace(PTRACE_GETSIGINFO, pid, 0,&si);
>>> +
>>
>> Doesn't this leak the host siginfo_t into the guest?
>>
> 
> 
> Docs for PTRACE_GETSIGINFO say `si' gets a copy. After that, `si' is not used for anything other than giving it to the guest. But I really can't say I
> understand the surrounding code too well so please review carefully :)

I was not talking about a memory leak.
What I meant was a information leak.
Using the host siginfo_t a guest process may get it's UID, PID, memory location, etc... on the host side.

Anyway, thanks for the test case!
This seems to be really broken.
I had only a few minutes to look at the issue but I think the correct way to fix is changing
arch/um/kernel/trap.c:relay_signal() to use force_sig_info() instead of force_sig().
Create siginfo_t and fill by hand like segv() does.

Thanks,
//richard