Messages in this thread | | | Date | Mon, 6 Oct 2014 15:17:03 -0700 | From | David Daney <> | Subject | Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area. |
| |
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 >
| |