Messages in this thread | | | Subject | Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64 | From | Andy Lutomirski <> | Date | Thu, 29 Nov 2018 09:02:23 -0800 |
| |
> On Nov 29, 2018, at 8:50 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> On Thu, Nov 29, 2018 at 8:33 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote: >> >> This seems to work... >> >> + .if \create_gap == 1 >> + .rept 6 >> + pushq 5*8(%rsp) >> + .endr >> + .endif >> + >> -idtentry int3 do_int3 has_error_code=0 >> +idtentry int3 do_int3 has_error_code=0 create_gap=1 > > Ugh. Doesn't this entirely screw up the stack layout, which then > screws up task_pt_regs(), which then breaks ptrace and friends? > > ... and you'd only notice it for users that use int3 in user space, > which now writes random locations on the kernel stack, which is then a > huge honking security hole. > > It's possible that I'm confused, but let's not play random games with > the stack like this. The entry code is sacred, in scary ways. > > So no. Do *not* try to change %rsp on the stack in the bp handler. > Instead, I'd suggest: > > - just restart the instruction (with the suggested "ptregs->rip --") > > - to avoid any "oh, we're not making progress" issues, just fix the > instruction yourself to be the right call, by looking it up in the > "what needs to be fixed" tables. > > No?
I thought that too. I think it deadlocks. CPU A does text_poke_bp(). CPU B is waiting for a spinlock with IRQs off. CPU C holds the spinlock and hits the int3. The int3 never goes away because CPU A is waiting for CPU B to handle the sync_core IPI.
Or do you think we can avoid the IPI while the int3 is there?
| |