Messages in this thread | | | From | Andy Lutomirski <> | Date | Thu, 10 Jan 2019 16:56:02 -0800 | Subject | Re: [PATCH v3 0/6] Static calls |
| |
On Thu, Jan 10, 2019 at 3:02 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Thu, Jan 10, 2019 at 12:52 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > Right, emulating a call instruction from the #BP handler is ugly, > > because you have to somehow grow the stack to make room for the return > > address. Personally I liked the idea of shifting the iret frame by 16 > > bytes in the #DB entry code, but others hated it. > > Yeah, I hated it. > > But I'm starting to think it's the simplest solution. > > So still not loving it, but all the other models have had huge issues too. >
Putting my maintainer hat on:
I'm okay-ish with shifting the stack by 16 bytes. If this is done, I want an assertion in do_int3() or wherever the fixup happens that the write isn't overlapping pt_regs (which is easy to implement because that code has the relevant pt_regs pointer). And I want some code that explicitly triggers the fixup when a CONFIG_DEBUG_ENTRY=y or similar kernel is built so that this whole mess actually gets exercised. Because the fixup only happens when a really-quite-improbable race gets hit, and the issues depend on stack alignment, which is presumably why Josh was able to submit a buggy series without noticing.
BUT: this is going to be utterly gross whenever anyone tries to implement shadow stacks for the kernel, and we might need to switch to a longjmp-like approach if that happens.
--Andy
| |