Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.

[David Daney]

On 10/06/2014 02:58 PM, Rich Felker wrote:
> On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
> > On 10/06/2014 02:31 PM, Rich Felker wrote:
> > > On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> > > > > Userspace should play no part in this; requiring userspace to help
> > > > > make special accomodations for fpu emulation largely defeats the
> > > > > purpose of fpu emulation.
> > > >
> > > > That is certainly one way of looking at it.  Really it is opinion,
> > > > rather than fact though.
> > >
> > > It's an opinion, yes, but it has substantial reason behind it.
> > >
> > > > GLibc is full of code (see ld.so) that in earlier incantations of
> > > > Unix/Linux was in kernel space, and was moved to userspace.  Given
> > > > that there is a partitioning of code between kernel space and
> > > > userspace, I think it not totally unreasonable to consider doing
> > > > some of this in userspace.
> > > >
> > > > Even on systems with hardware FPU, the architecture specification
> > > > allows for/requires emulation of certain cases (denormals, etc.)  So
> > > > it is already a requirement that userspace cooperate by always
> > > > having free space below $SP for use by the kernel.  So the current
> > > > situation is that userspace is providing services for the kernel FPU
> > > > emulator.
> > > >
> > > > My suggestion is to change the nature of the way these services are
> > > > provided by the userspace program.
> > >
> > > But this isn't setup by the userspace program. It's setup by the
> > > kernel on program entry. Despite that, though, I think it's an
> > > unnecessary (and undocumented!) constraint; the fact that it requires
> > > the stack to be executable makes it even more harmful and
> > > inappropriate.
> >
> > The management of the stack is absolutely done by userspace code.
> > Any time you do pthread_create(), userspace code does mmap() to
> > allocate the stack area, it then sets permissions on the area, and
> > then it passes the address of the area to clone().
>
> This is hardly management.
>
> > Furthermore the
> > userspace code has to be very careful in its use of the $sp
> > register, so that it doesn't store data in places that will be
> > used/clobbered by the kernel.
>
> This is not "being careful". The stack pointer can never become
> invalid unless you do wacky things in asm or invoke UB.
>
> > All of this is under the control of the userspace program and done
> > with userspace code.
>
> For the most part it just happens by default. There is no particular
> intentionality needed, and certainly no hideous MIPS-specific hacks
> needed.

Yes, it happens by default.  But it wasn't magic.  It took careful work 
by the ABI and toolchain designers to make it work.


> > I appreciate the fact that libc authors might prefer *not* to write
> > more code, but they could, especially if they wanted to add the
> > feature of non-executable stacks to their library implementation.
>
> So your position is that:

It is not really a position that I have.  Rather a proposal for one 
possible way to make non-executable stacks work on MIPS.

> 1. A non-exec-stack system can only run new code produced to do extra
>     stuff in userspace.

Any non-executable stack solution for MIPS will require changes to the 
toolchain/libc.  So it is merely a question of what form the change 
should take.


> 2. The startup code needs to do special work in userspace on MIPS to
>     setup an executable area for fpu emulation.

Yes. Similar to how startup code has to do special work to set up the 
TLS areas, and load shared libraries.

> 3. Every call to clone/CLONE_VM needs to be accompanied by a call to
>     mmap and this new syscall to set the address, and every call to
>     SYS_exit needs to be accompanies by a call to munmap for the
>     corresponding mapping.

No, We don't have to mmap() on each thread creation.  Many threads 
(perhaps 512) could be handled by a single page, so the normal case 
would be a single mmap() for the life of the program.


> This is a huge ill-designed mess.

Have you seen the alternatives?

Have you ever wondered why MIPS doesn't have non-executable stack support?

> Rich

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/