Received: by 10.223.176.5 with SMTP id f5csp1040083wra; Tue, 6 Feb 2018 11:30:51 -0800 (PST) X-Google-Smtp-Source: AH8x227B1BXoAWH9qT1oSXxn1t396uVuzX6DECgzggcUYkPYZ9nXs9IpHjmj4ELIwtbSKN+QJCbA X-Received: by 2002:a17:902:c81:: with SMTP id 1-v6mr3414977plt.281.1517945451060; Tue, 06 Feb 2018 11:30:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517945451; cv=none; d=google.com; s=arc-20160816; b=KxPBZ+nruoWWY49fcYg+u37VcbLvN6C4YnXHgoJwtPp5QfTy3TGFDhMo5P3Il3BRK0 9sbSgZIovYowE2fvpeNKYen5rj0USNWJ6Os9k8eKP3h0ogAAZX5SpcjJ3lCfU0iNk3JK hqTdRhjbVjLcI6U11mut7vEsCW56B53ZlVHdB0l0SjpUbI/bSRNO54ncR2YAYj9vujwZ f2weJrMo8e/f5/X6Q4b50BRPibVwoE6j8ajYJPhxOVqGEyZMVwMk3UZ1P3o1oVaPiekV p4rdzfB4LzV/xE3o5oyMG41oDdW/Ido7gQ3YpxmqI44qKy+PNd605ZuI7Mi55bubtKKb fbfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=xMMsgH/A7T9efs4+qoOauKDAB5QyZqGANTBjxAiHwC8=; b=LgrvEDEG/porbI6drZYGdo0f36L4tjRw7jSkbyPq/jUBKIQUp/wdpBlc69vAyQc2r7 AqySZimuVLp4efbrAo6aY598wen+DAPkBmDDHoO4gpTXanigPqyQ0tfqyYhLH1FPLN2S 9sIdqm1Syl8GKigX/9aa7kWsQ3LCDsdKw6dASfJgnP+mBIdBvhATxRjx8P0ZjHj6+xz6 OVXQbZf6IPBZyajIXRyyTnx4qzXd+PpfrVBby4Dvn2aqLhglT+2m21ZI8KXiBaALI7ht flS3ooRUlzVJaZgSBEpRdUdIyizqiQmb1f2tmrt/vZOLYo2paLRrvJTCEUi55CXps6QX w7cw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d8-v6si2024364pli.337.2018.02.06.11.30.36; Tue, 06 Feb 2018 11:30:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752968AbeBFT33 (ORCPT + 99 others); Tue, 6 Feb 2018 14:29:29 -0500 Received: from mx2.suse.de ([195.135.220.15]:52225 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751554AbeBFT3Z (ORCPT ); Tue, 6 Feb 2018 14:29:25 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C0A66ACB2; Tue, 6 Feb 2018 19:29:23 +0000 (UTC) Date: Tue, 6 Feb 2018 19:29:25 +0000 From: Luis Henriques To: Dan Williams Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, kernel-hardening@lists.openwall.com, gregkh@linuxfoundation.org, x86@kernel.org, Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , tglx@linutronix.de, torvalds@linux-foundation.org, akpm@linux-foundation.org, alan@linux.intel.com Subject: Re: [PATCH v4 07/10] x86: narrow out of bounds syscalls to sys_read under speculation Message-ID: <20180206192925.qkmghwsbaysr4iv2@hermes.olymp> References: <151632009605.21271.11304291057104672116.stgit@dwillia2-desk3.amr.corp.intel.com> <151632014097.21271.16980532033566583357.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <151632014097.21271.16980532033566583357.stgit@dwillia2-desk3.amr.corp.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 18, 2018 at 04:02:21PM -0800, Dan Williams wrote: > The syscall table base is a user controlled function pointer in kernel > space. Like, 'get_user, use 'MASK_NOSPEC' to prevent any out of bounds > speculation. While retpoline prevents speculating into the user > controlled target it does not stop the pointer de-reference, the concern > is leaking memory relative to the syscall table base. This patch seems to cause a regression. An easy way to reproduce what I'm seeing is to run the samples/statx/test-statx. Here's what I see when I have this patchset applied: # ./test-statx /tmp statx(/tmp) = -1 /tmp: Bad file descriptor Reverting this single patch seems to fix it. Cheers, -- Lu?s > > Reported-by: Linus Torvalds > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: x86@kernel.org > Cc: Andy Lutomirski > Signed-off-by: Dan Williams > --- > arch/x86/entry/entry_64.S | 2 ++ > arch/x86/include/asm/smap.h | 9 ++++++++- > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > index 4f8e1d35a97c..2320017077d4 100644 > --- a/arch/x86/entry/entry_64.S > +++ b/arch/x86/entry/entry_64.S > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -264,6 +265,7 @@ entry_SYSCALL_64_fastpath: > cmpl $__NR_syscall_max, %eax > #endif > ja 1f /* return -ENOSYS (already in pt_regs->ax) */ > + MASK_NOSPEC %r11 %rax /* sanitize syscall_nr wrt speculation */ > movq %r10, %rcx > > /* > diff --git a/arch/x86/include/asm/smap.h b/arch/x86/include/asm/smap.h > index 2b4ad4c6a226..3b5b2cf58dc6 100644 > --- a/arch/x86/include/asm/smap.h > +++ b/arch/x86/include/asm/smap.h > @@ -35,7 +35,14 @@ > * this directs the cpu to speculate with a NULL ptr rather than > * something targeting kernel memory. > * > - * assumes CF is set from a previous 'cmp TASK_addr_limit, %ptr' > + * In the syscall entry path it is possible to speculate past the > + * validation of the system call number. Use MASK_NOSPEC to sanitize the > + * syscall array index to zero (sys_read) rather than an arbitrary > + * target. > + * > + * assumes CF is set from a previous 'cmp' i.e.: > + * cmp TASK_addr_limit, %ptr > + * cmp __NR_syscall_max, %idx > */ > .macro MASK_NOSPEC mask val > sbb \mask, \mask > >