lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 7 Oct 2014 09:08:51 -0700 From: David Daney <ddaney@...iumnetworks.com> To: Rich Felker <dalias@...c.org> CC: David Daney <david.s.daney@...il.com>, Andy Lutomirski <luto@...capital.net>, David Daney <ddaney.cavm@...il.com>, <libc-alpha@...rceware.org>, <linux-kernel@...r.kernel.org>, <linux-mips@...ux-mips.org>, David Daney <david.daney@...ium.com> Subject: Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area. 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. David Daney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists