This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.
- From: Andy Lutomirski <luto at amacapital dot net>
- To: David Daney <ddaney at caviumnetworks dot com>
- Cc: Linux MIPS Mailing List <linux-mips at linux-mips dot org>, libc-alpha <libc-alpha at sourceware dot org>, David Daney <ddaney dot cavm at gmail dot com>, David Daney <david dot daney at cavium dot com>, Rich Felker <dalias at libc dot org>, David Daney <david dot s dot daney at gmail dot com>, "linux-kernel at vger dot kernel dot org" <linux-kernel at vger dot kernel dot org>
- Date: Tue, 7 Oct 2014 11:16:54 -0700
- Subject: Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.
- Authentication-results: sourceware.org; auth=none
- References: <5433071B dot 4050606 at caviumnetworks dot com> <20141006213101 dot GA23797 at brightrain dot aerifal dot cx> <54330D79 dot 80102 at caviumnetworks dot com> <20141006215813 dot GB23797 at brightrain dot aerifal dot cx> <543327E7 dot 4020608 at amacapital dot net> <54332A64 dot 5020605 at caviumnetworks dot com> <20141007000514 dot GD23797 at brightrain dot aerifal dot cx> <543334CE dot 8060305 at caviumnetworks dot com> <20141007004915 dot GF23797 at brightrain dot aerifal dot cx> <54337127 dot 40806 at gmail dot com> <20141007111102 dot GH23797 at brightrain dot aerifal dot cx> <54341013 dot 2030509 at caviumnetworks dot com>
On Oct 7, 2014 9:09 AM, "David Daney" <ddaney@caviumnetworks.com> wrote:
>
> On 10/07/2014 04:11 AM, Rich Felker wrote:
>>
>> On Mon, Oct 06, 2014 at 09:50:47PM -0700, David Daney wrote:
>>>>>
>>>>> the out-of-line execution trick, but do it somewhere other than in
>>>>> stack memory.
>>>>
>>>> How do you answer Andy Lutomirski's question about what happens when a
>>>> signal handler interrupts execution while the program counter is
>>>> pointing at this "out-of-line execution" trampoline? This seems like a
>>>> show-stopper for using anything other than the stack.
>>>
>>> It would be nice to support, but not doing so would not be a
>>> regression from current behavior.
>>
>>
>> It's not just "nice" to support, it's mandatory. Otherwise you will
>> execute essentially *random instructions* in this case, providing a
>> very nice attack vector that can almost certainly be elevated to
>> arbitrary code execution via timing of signals during floating point
>> code.
>>
>> The current behavior in regards to this is correct: because you have a
>> *stack*, each trampoline is pushed onto the stack in its own context,
>> and popped when it's no longer needed. You can have arbitrarily many
>> such trampolines up to the stack size. Note that each nested signal
>> handler already requires sizeof(ucontext_t) in stack space, so these
>> trampolines are a negligible additional cost without major effects on
>> the number of signal handlers you can nest without overflowing the
>> stack.
>
>
> Yes, the stack takes care of the allocations, but the current implementation has many problems:
>
> 1) Signals clobber the emulation area.
> 2) Signals caused by the emulation, have incorrect saved machine state.
>
> We have a low bar to pass, any new solution doesn't have to be perfect, it only has to be an improvement.
>
> Keep in mind that we are not starting from a clean slate, there are many years of legacy code that has built up here.
A lesson I learned when doing the x86 vsyscall stuff: Don't waste time
improving legacy crap without a really good reason. Especially don't
extend the interface. Deprecate it (without breaking working user
code) and move on.
--Andy
>
> David Daney