On Mon, Nov 20, 2017 at 11:20 PM, Ingo Molnar <[email protected]> wrote: > > * Andy Lutomirski <[email protected]> wrote: > >> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c >> index 1ea03027a4a9..e4a941be96cf 100644 >> --- a/arch/x86/kernel/traps.c >> +++ b/arch/x86/kernel/traps.c > >> -asmlinkage __visible notrace >> +asmlinkage __visible notrace __no_sanitize_address >> struct bad_iret_stack *fixup_bad_iret(struct bad_iret_stack *s) >> { >> /* >> * This is called from entry_64.S early in handling a fault >> * caused by a bad iret to user mode. To handle the fault >> - * correctly, we want move our stack frame to task_pt_regs >> - * and we want to pretend that the exception came from the >> - * iret target. >> + * correctly, we want move our stack frame to where it would >> + * be had we entered directly on the entry stack (rather than >> + * just below the IRET frame) and we want to pretend that the >> + * exception came from the iret target. >> */ >> struct bad_iret_stack *new_stack = >> - container_of(task_pt_regs(current), >> - struct bad_iret_stack, regs); >> + (struct bad_iret_stack *)this_cpu_read(cpu_tss.x86_tss.sp0) - >> 1; >> >> /* Copy the IRET target to the new stack. */ >> memmove(&new_stack->regs.ip, (void *)s->regs.sp, 5*8); > > So the addition of the __no_sanitize_address attribute to fixup_bad_iret() > made > the 64-bit allyesconfig/allmodconfig kernels fail the build:
Yeah, I *hate* the way this works. Apparently getting __no_sanitize_address to be fully reliable involves just building the whole file without KASAN. That being said, I have this fixed much better in my latest tree: I fixed up KASAN so that I don't need to turn it off for these helpers.
