From: Stroesser, Bodo <Bodo.S<troesser@fu...> - 2004-10-01 09:02:59
> Can you fix your mailer so that it doesn't wrap patches?
> I mostly applied that (by hand since it was corrupt :-).
I would really like to fix this. The problem is, I *have* to use
Outlook, and I could not find a menu to change the behavior. Until now I
only could change the mail format to be plain text (instead of http).
I'm trying to get help from our system admins, but still got none :-(.
> > But if a user directly calls sys_sigaction() without glibc being=20
> > involved (e.g. via "int 0x80"), he can reset SA_RESTORER. Now the=20
> > kernel should use it's own restorer-stub. On i386 it's located in
> > vsyscall-page. UML must use the old method of putting it onto the=20
> > stack. The patch modifies the signal-stack-setup to get the restorer
> > on the stack working.
> This is the part I didn't apply. As the comment says, gdb uses that
as a signature, and I don't want to change it for that reason. Let's
just leave it the same as as x86, even if that's wrong.
I don't know exactly, which part of the patch you talk about. If it is
writing the restorers code to stack, please note, there have to be
different restorers in setup_signal_stack_sc() and
setup_signal_stack_si(). They must use different systemcalls
(sys_sigreturn / sys_rt_sigreturn) to remove the signal stack frame
(refer to arch/i386/kernel/signal.c). With the patch applied, UML
exactly does, what i386 does. And it must do so, because in UML the code
on the stack could be used in special cases.
> > While testing that stuff, I could crash UML by using the wrong=20
> > systemcall-number in the restorer-stub (has been wrong for=20
> > sys_sigreturn). I think, there is no check in sys_(rt_)sigreturn(),=20
> > whether the contents of the stack is wrong.
> If the syscall number is wrong, then it'll never hit sys_sigreturn.
It sounds like there's some other sanity-checking that's missing.
No. The restorer written in setup_signal_stack_sc() has been wrong. So
the wrong syscall has been done with the wrong stack pointer (missing a
"popl %eax" at the beginning of the restorer.
> > Unfortunately at the moment I can't see, what UML prints out,
> > messages to console are not displayed (don't know why, yet). If the=20
> > system runs, I can use dmesg, but when it is crashed ...
> At gdb, printf "%s", log_buf
Thank you. I'll try that.