Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753460AbbF3QEc (ORCPT ); Tue, 30 Jun 2015 12:04:32 -0400 Received: from mail-la0-f45.google.com ([209.85.215.45]:34830 "EHLO mail-la0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751105AbbF3QEZ (ORCPT ); Tue, 30 Jun 2015 12:04:25 -0400 MIME-Version: 1.0 In-Reply-To: <20150630105855.GB23297@pd.tnic> References: <903010762c07a3d67df914fea2da84b52b0f8f1d.1435602481.git.luto@kernel.org> <20150630105855.GB23297@pd.tnic> From: Andy Lutomirski Date: Tue, 30 Jun 2015 09:04:04 -0700 Message-ID: Subject: Re: [PATCH v4 02/17] x86/entry/64/compat: Fix bad fast syscall arg failure path To: Borislav Petkov Cc: Kees Cook , "Paul E. McKenney" , "linux-kernel@vger.kernel.org" , Oleg Nesterov , Denys Vlasenko , Brian Gerst , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , X86 ML , Rik van Riel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3535 Lines: 104 On Jun 30, 2015 3:59 AM, "Borislav Petkov" wrote: > > On Mon, Jun 29, 2015 at 12:33:34PM -0700, Andy Lutomirski wrote: > > diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S > > index bb187a6a877c..efe0b1e499fa 100644 > > --- a/arch/x86/entry/entry_64_compat.S > > +++ b/arch/x86/entry/entry_64_compat.S > > @@ -425,8 +425,39 @@ cstar_tracesys: > > END(entry_SYSCALL_compat) > > > > ia32_badarg: > > - ASM_CLAC > > - movq $-EFAULT, RAX(%rsp) > > + /* > > + * So far, we've entered kernel mode, set AC, turned on IRQs, and > > + * saved C regs except r8-r11. We haven't done any of the other > > + * standard entry work, though. We want to bail, but we shouldn't > > + * treat this as a syscall entry since we don't even know what the > > + * args are. Instead, treat this as a non-syscall entry, finish > > + * the entry work, and immediately exit after setting AX = -EFAULT. > > + * > > + * We're really just being polite here. Killing the task outright > > + * would be a reasonable action, too. Given that the only valid > > + * way to have gotten here is through the vDSO, and we already know > > + * that the stack pointer is bad, the task isn't going to survive > > + * for long no matter what we do. > > You mean something like > > force_sig_info(SIGSEGV, &si, current); > > ? > > I'd say we do it and not noodle unnecessarily with zeroing out pt_regs > if the task is going to die anyway. IOW, make it die faster. :) That's even more complicated. To send a signal, we need valid pt_regs when we save our context in do_signal. I was thinking do_exit. In any case, we can certainly change the behavior here, but I did it this way at the beginning of the series because this patch mostly preserves existing behavior while fixing what is arguably a bug and because without something like this we'll have context tracking issues later in the series. My eventual goal is to try to turn entry_SYSENTER_32 into a minimal piece of asm that pushes regs and calls a C function like do_SYSENTER_32. Once that happens, we can just write: enter_from_user_mode(); local_irq_enable(); if (__get_user(...) != 0) { fail(); } pt_regs->whatever = the thing we just read; ... and do the syscall Given the current state of the asm, I think I'd rather get farther along in the cleanups before trying to change behavior here. --Andy > > > + */ > > + > > + ASM_CLAC /* undo STAC */ > > + movq $-EFAULT, RAX(%rsp) /* return -EFAULT if possible */ > > + > > + /* Fill in the rest of pt_regs */ > > + xorl %eax, %eax > > + movq %rax, R11(%rsp) > > + movq %rax, R10(%rsp) > > + movq %rax, R9(%rsp) > > + movq %rax, R8(%rsp) > > + SAVE_EXTRA_REGS > > + > > + /* Turn IRQs back off. */ > > + DISABLE_INTERRUPTS(CLBR_NONE) > > + TRACE_IRQS_OFF > > + > > + /* And exit again. */ > > + jmp retint_user > > + > > ia32_ret_from_sys_call: > > xorl %eax, %eax /* Do not leak kernel information */ > > movq %rax, R11(%rsp) > > -- > > 2.4.3 > > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/