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

[David Daney <ddaney@caviumnetworks.com>]

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
>