[parisc-linux] syscall restart block.

[parisc-linux] syscall restart block.

[Carlos O'Donell]

jda,

Oh, I realized today we still have a hole in the way we handle
restartable syscalls. Normally the restarter function is placed in a
function descriptor, a stack trampoline is laid down, the user process
is allowed to return, execute the stack trampoline with the modified
syscall number (indicating restart), upon entry to the kernel the
restart function is executed with arugments. 

The problem is that we should in general disable restartable syscalls as
we walk the userspace return trampoline. If the user took a signal
during the trampoline walk, the signal handler could execute a
restartable syscall, and if that syscall was interrupted, the restorer
function would be changed (there is only one entry for a restorer, they
aren't chained). This means that you technically call the wrong syscall
when you unwind from the signal that you took on the stack trampoline.

If we move stack trampolines to the gateway pagethen signals can't be
delivered to the returning process during the trampoline walk (signals
are not allowed to be delivered for processes on the gateway page). So
it fixes our hole too.

It also allows us to interpret PT_GNU_STACK properly, since the kernel
no longer needs to execute a trampoline on the users stack. The
toolchain can now correctly mark the stack as non-exec.

I only just realized we still had this hole and it might manifest itself
under heavy signal load.

Randolph, comments?
Does this analysis sound correct?

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] syscall restart block.

[James Bottomley]

On Sun, 2004-09-12 at 14:45, Carlos O'Donell wrote:
> The problem is that we should in general disable restartable syscalls as
> we walk the userspace return trampoline. If the user took a signal
> during the trampoline walk, the signal handler could execute a
> restartable syscall, and if that syscall was interrupted, the restorer
> function would be changed (there is only one entry for a restorer, they
> aren't chained). This means that you technically call the wrong syscall
> when you unwind from the signal that you took on the stack trampoline.

If I read this scenario correctly it can only be triggered on an SMP
system (where another user process executing on a different CPU sends a
singnal to this process) or if the process is unlucky enough to take an
interrupt while executing the trampoline ... still, the window exists
and should be plugged

> I only just realized we still had this hole and it might manifest itself
> under heavy signal load.

Precisely, because heavy load usually implies higher disc or network
interrupt load.

James


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: syscall restart block.

[Randolph Chung]

> If we move stack trampolines to the gateway pagethen signals can't be
> delivered to the returning process during the trampoline walk (signals
> are not allowed to be delivered for processes on the gateway page). So
> it fixes our hole too.
> 
> It also allows us to interpret PT_GNU_STACK properly, since the kernel
> no longer needs to execute a trampoline on the users stack. The
> toolchain can now correctly mark the stack as non-exec.
> 
> I only just realized we still had this hole and it might manifest itself
> under heavy signal load.

i think the analysis is correct, but i don't like the solution! :-)

various pieces of software (gcc, gdb) need to be able to read and
analyze the signal trampoline for unwinding. putting the trampoline 
onto the gateway page will break these applications, because the 
gateway page is not readable by the user.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] [RFC] hppa needs a vDSO? Solves signal trampolines and opens up new possibilities.

[Carlos O'Donell]

> i think the analysis is correct, but i don't like the solution! :-)
> 
> various pieces of software (gcc, gdb) need to be able to read and
> analyze the signal trampoline for unwinding. putting the trampoline 
> onto the gateway page will break these applications, because the 
> gateway page is not readable by the user.

We need a vDSO implementation for hppa, and stick the trampolines into
the vDSO. gdb can still use mprotect on the vDSO mapping created by the
kernel. We can use the powerpc implementation as a reference. I think
it's sorta neat for the kernel to create a virtual DSO that userspace
can leverage. All the ELF rules apply for symbols and you can get all
the debugging info right.

Secondly the vDSO could override the CAS symbol from libc with an LWS
version since it knows that LWS exists. The older code can continue to
call a non-atomic libc version. I'm not quite sure how this works...

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux