From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752662AbbF3K7Z (ORCPT ); Tue, 30 Jun 2015 06:59:25 -0400 Received: from mail.skyhub.de ([78.46.96.112]:54688 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751817AbbF3K7R (ORCPT ); Tue, 30 Jun 2015 06:59:17 -0400 Date: Tue, 30 Jun 2015 12:58:55 +0200 From: Borislav Petkov To: Andy Lutomirski Cc: x86@kernel.org, linux-kernel@vger.kernel.org, =?utf-8?B?RnLDqWTDqXJpYw==?= Weisbecker , Rik van Riel , Oleg Nesterov , Denys Vlasenko , Kees Cook , Brian Gerst , paulmck@linux.vnet.ibm.com Subject: Re: [PATCH v4 02/17] x86/entry/64/compat: Fix bad fast syscall arg failure path Message-ID: <20150630105855.GB23297@pd.tnic> References: <903010762c07a3d67df914fea2da84b52b0f8f1d.1435602481.git.luto@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <903010762c07a3d67df914fea2da84b52b0f8f1d.1435602481.git.luto@kernel.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. :) > + */ > + > + 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. --