Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2647773imm; Thu, 11 Oct 2018 13:49:48 -0700 (PDT) X-Google-Smtp-Source: ACcGV63gfiC8rnoYzu8QiIDvt7fB8ySlIl1OQi/PYM16SPzL2n6YSQXZQ0D2u8zbQyGxjfZm6ifL X-Received: by 2002:a63:3152:: with SMTP id x79-v6mr2805979pgx.323.1539290988545; Thu, 11 Oct 2018 13:49:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539290988; cv=none; d=google.com; s=arc-20160816; b=Gzo7D0hxJIcmmW1gBxFvzYQtiGUB++Xd8W2maveX4Ss3gNY1w2Vyk96jSCQeqiqc3k LIdcaQrZ4KWp1XCwZyNpXeBUuGmrFQuRFdT5XV6JqI7u5vy0N+mzYZi3PwX9BffmTyBe L3qObNfK6G1XFmQgqpJ16TbVpTdP18Z9IX2tWrNoHL15shITftiry/RA0SaqkNqCM7Cs lC+yRN3QJhWoPrAlILJb899l64EbeIvAhiimdV2ZeRykOs2aSxOSZv77u3aQft9WxGOz AG80u74Qu73PZIZbMjXUCwBmSs3xYKSWlXQ6jKJfpiQfIQQgP9x1HFeXenDvd55jnSwh He3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=toKAlTnPz4ltCMQE2Peo+7Mvgoj+rz4zSkVxmZP/KCA=; b=hy4VJ+6AemcHh7ImMzkuKxzYw+Ap4bvhoc1TPjfgPZ5ENZFgR1t9L1V/0lsvjh9Hws 1+wIq3CUf6xtOl7l1lkfgfAPXpGCiGTpwis6549NFrpe1g1LHpBhMKx//gcVZ1ydTTs7 1f/Wfnco4JYJOtXhV5FpFdxBNupc5r9ENq2sF5RRnVif+aK7IVwYKoY+LtmuBZLLdP3d fHWJb6d21CiqdOMgyQ7y+O91NFg+E7VnILxs9Gf5WHQozFwqT4lURVYRJcUXdqaZh9OX aA37zv+y+s6/V1fZPAJdEVO/tZCzeVUJDczyHeuZT2qkmF31yJNMjzumo1MUHWsK83RO m65g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=w5KFK4Mq; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q15-v6si25287048pgm.595.2018.10.11.13.49.33; Thu, 11 Oct 2018 13:49:48 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=w5KFK4Mq; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726712AbeJLESF (ORCPT + 99 others); Fri, 12 Oct 2018 00:18:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:34586 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725903AbeJLESF (ORCPT ); Fri, 12 Oct 2018 00:18:05 -0400 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 11CA321470 for ; Thu, 11 Oct 2018 20:49:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1539290947; bh=XYtyvz9/iIeRtZ9DI6HakUMVjulnyPFa0BCn6lFuH7s=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=w5KFK4Mq0YVRpp9b1xP7z/Z/fzXKaqzN9eaFAljUd7YI+fG21oL/qvHdPSRPKNF/m fhQPYkXkvRbJCQk0RqRwWsZ7POADwrdzJx+iGc6R6500+9oXH8ct1uXQtE/KDq2pZ9 c5bJ65SmWTLGrZ+AZFflg9PFMcodNubBKL34Tjzk= Received: by mail-wr1-f43.google.com with SMTP id d2-v6so11157131wro.7 for ; Thu, 11 Oct 2018 13:49:06 -0700 (PDT) X-Gm-Message-State: ABuFfog7KonjyuJM4Au4FqhG8i8EeWhrFW8dRRMOpDRHe06ZXKY0aiiA /XgZNJ9/krigY/FpDAeUVFyavgmbRaFHQDQtHSa0rQ== X-Received: by 2002:a5d:610c:: with SMTP id v12-v6mr2959117wrt.308.1539290945477; Thu, 11 Oct 2018 13:49:05 -0700 (PDT) MIME-Version: 1.0 References: <20181011185458.10186-1-kristen@linux.intel.com> In-Reply-To: <20181011185458.10186-1-kristen@linux.intel.com> From: Andy Lutomirski Date: Thu, 11 Oct 2018 13:48:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86: entry: flush the cache if syscall error To: Kristen Carlson Accardi Cc: Kernel Hardening , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , X86 ML , Andrew Lutomirski , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 11, 2018 at 11:55 AM Kristen Carlson Accardi wrote: > > This patch aims to make it harder to perform cache timing attacks on data > left behind by system calls. If we have an error returned from a syscall, > flush the L1 cache. > > It's important to note that this patch is not addressing any specific > exploit, nor is it intended to be a complete defense against anything. > It is intended to be a low cost way of eliminating some of side effects > of a failed system call. > > A performance test using sysbench on one hyperthread and a script which > attempts to repeatedly access files it does not have permission to access > on the other hyperthread found no significant performance impact. > > Suggested-by: Alan Cox > Signed-off-by: Kristen Carlson Accardi > --- > arch/x86/Kconfig | 9 +++++++++ > arch/x86/entry/common.c | 18 ++++++++++++++++++ > 2 files changed, 27 insertions(+) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 1a0be022f91d..bde978eb3b4e 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -445,6 +445,15 @@ config RETPOLINE > code are eliminated. Since this includes the syscall entry path, > it is not entirely pointless. > > +config SYSCALL_FLUSH > + bool "Clear L1 Cache on syscall errors" > + default n > + help > + Selecting 'y' allows the L1 cache to be cleared upon return of > + an error code from a syscall if the CPU supports "flush_l1d". > + This may reduce the likelyhood of speculative execution style > + attacks on syscalls. > + > config INTEL_RDT > bool "Intel Resource Director Technology support" > default n > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c > index 3b2490b81918..26de8ea71293 100644 > --- a/arch/x86/entry/common.c > +++ b/arch/x86/entry/common.c > @@ -268,6 +268,20 @@ __visible inline void syscall_return_slowpath(struct pt_regs *regs) > prepare_exit_to_usermode(regs); > } > > +__visible inline void l1_cache_flush(struct pt_regs *regs) > +{ > + if (IS_ENABLED(CONFIG_SYSCALL_FLUSH) && > + static_cpu_has(X86_FEATURE_FLUSH_L1D)) { > + if (regs->ax == 0 || regs->ax == -EAGAIN || > + regs->ax == -EEXIST || regs->ax == -ENOENT || > + regs->ax == -EXDEV || regs->ax == -ETIMEDOUT || > + regs->ax == -ENOTCONN || regs->ax == -EINPROGRESS) What about ax > 0? (Or more generally, any ax outside the range of -1 .. -4095 or whatever the error range is.) As it stands, it looks like you'll flush on successful read(), write(), recv(), etc, and that could seriously hurt performance on real workloads. > + return; > + > + wrmsrl(MSR_IA32_FLUSH_CMD, L1D_FLUSH); > + } > +} > + > #ifdef CONFIG_X86_64 > __visible void do_syscall_64(unsigned long nr, struct pt_regs *regs) > { > @@ -290,6 +304,8 @@ __visible void do_syscall_64(unsigned long nr, struct pt_regs *regs) > regs->ax = sys_call_table[nr](regs); > } > > + l1_cache_flush(regs); > + > syscall_return_slowpath(regs); > } > #endif > @@ -338,6 +354,8 @@ static __always_inline void do_syscall_32_irqs_on(struct pt_regs *regs) > #endif /* CONFIG_IA32_EMULATION */ > } > > + l1_cache_flush(regs); > + > syscall_return_slowpath(regs); > } > > -- > 2.14.4 >