Received: by 10.223.176.46 with SMTP id f43csp886018wra; Fri, 26 Jan 2018 08:24:30 -0800 (PST) X-Google-Smtp-Source: AH8x226DMttT+f8Zfen1N3+1kcAPyHfY8ITNsOrfoatK0DQ3wtpdqktkHbl1sL8pVVFeAW661azI X-Received: by 2002:a17:902:ab85:: with SMTP id f5-v6mr14990575plr.199.1516983870368; Fri, 26 Jan 2018 08:24:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516983870; cv=none; d=google.com; s=arc-20160816; b=kl0IYiWlX07COcbNgSh0XjbFCOtTXTA6R79PjE1OGEvyx5nmAB1wktynEUhF/IFDfB /FX5k1B9/NPNYWkb55lJvy8bWdX3csZ93RYwNAcroY5PyGCeGg0xxLK//cRb0IAKKPCS vgRLA5YoFcHFiL79YtljTebHrZZJpPdCZa8bTEjg+Ml4+VruuDVjQOb2sneoSgxyU996 jICPgJ4dSJhMuUslf+dEJfMSwPe/yv2FZ8CDV5jfzrYEE+tyhbPlYCmQf11/Hc/rvP5F vnGxZ2j8JgYTLlNpbCiCLFRVahd+tw7z6MLB/GE99/4HPQzgtHCURxCWvmXXqX4YWtCq Ty1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=BWrMGzT2RKmOYZQHsc/Ef4QHU5repEuMvPwzW0LEKK8=; b=RZ2VSxhPg+EkPA6dSg2l6nmfioawfDo4YKIC22guLupVg7uSsUb7edC44Qj/WNwOMs o7bRSGoa8kRsRnijmnyiynlRHCVTc01c5g04/4U2zdpv19fwaBCTtDdi70VYpbtjap2x K10PGa7YfqBKVGK+qRw3O+pdWgbCpA+DDMkgFlnDsgPQ5Nl66AZSlO5ZL7bTjw9DGa9L U4VYPEjsPh/Tl/NX1Yeglf/7HZpDVZir/GTmzMAYEWk42W66yqvOtDXt1Nnoe+NjBEwt gTU9fkN0LuFyxfNO6A2CWYOCyiz3o+InvTeLoz/qovMO1W9Bs6SpS8zlx9mohkz6iDoX kNzA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 94-v6si3881063ple.726.2018.01.26.08.24.15; Fri, 26 Jan 2018 08:24:30 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753900AbeAZQXl (ORCPT + 99 others); Fri, 26 Jan 2018 11:23:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35452 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751630AbeAZQXk (ORCPT ); Fri, 26 Jan 2018 11:23:40 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 802335BEB6; Fri, 26 Jan 2018 16:23:40 +0000 (UTC) Received: from mail.random (ovpn-116-59.ams2.redhat.com [10.36.116.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 141EA609D9; Fri, 26 Jan 2018 16:23:33 +0000 (UTC) Date: Fri, 26 Jan 2018 17:23:31 +0100 From: Andrea Arcangeli To: Thomas Gleixner Cc: LKML , Linus Torvalds , Greg Kroah-Hartman , Ingo Molnar , Peter Zijlstra , Borislav Petkov , David Woodhouse , Dave Hansen , Will Deacon , Josh Poimboeuf , Waiman Long Subject: Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder Message-ID: <20180126162331.GB5230@redhat.com> References: <20180107214759.387300853@linutronix.de> <20180107214913.096657732@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180107214913.096657732@linutronix.de> User-Agent: Mutt/1.9.2 (2017-12-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 26 Jan 2018 16:23:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote: > +static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL); > +static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL); > +static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL); This sysfs feature implemented as above is weakening kernel security, it should be 0400 above. It doesn't make sense to expose to luser when a software fix (or even only a software mitigation) has been disabled at build time to gain all performance back (see CONFIG_RETPOLINE=n config option). $ cat /boot/kernel-`uname -r` cat: /boot/kernel-4.15.0-rc9+: Permission denied $ cat /lib/modules/`uname -r`/kernel/arch/x86/kvm/kvm.ko cat: /lib/modules/4.15.0-rc9+/kernel/arch/x86/kvm/kvm.ko: Permission denied $ dmesg dmesg: read kernel buffer failed: Operation not permitted Noticing when cr3 is flipped in kernel/exit is easy, but noticing when the syscall table or the whole kernel has been built with retpolines is not trivial to detect. Same for variant#1. Exploiting spectre variant#2 for an attacker is not without risk of being detected while the setup is being mounted, as the CPU load would spike for hours. I may notice if a random background network daemon suddenly starts running at 100% CPU load for hours (especially on mobile devices that would be physically noticeable). Containers shouldn't have sysfs and you can workaround the above if you run all network daemons behind mount namespaces, but in general leaving this directory readable by luser is weaking security because it exposes when mounting a variant#2 attack can succeed. It even tells when it is worth to focus on the syscall_table indirect call or if the attack needs to dig deeper because asm retpolines were used, but the kernel was built with a gcc without retpolines. The only case where the above isn't weakening security is when the full fix is on for all the variants is enabled (and variant#1 for now just shows vulnerable..). For the same reasons the whole directory, not just the files, should be 0500, especially if this would be used for any other equivalent issue in the future and it won't stick to these 3 files, I didn't implement that yet, because it's less urgent if nobody adds any more files soon. From 578b411c8dcb1435dd1f94a6cd062f4eedb70fb5 Mon Sep 17 00:00:00 2001 From: Andrea Arcangeli Date: Wed, 24 Jan 2018 19:19:36 +0100 Subject: [PATCH 1/1] x86/spectre/meltdown: avoid the vulnerability directory to weaken kernel security If any of the fixes is disabled to gain some performance back at runtime or build time, should not be exposed to unprivileged userland. Signed-off-by: Andrea Arcangeli --- drivers/base/cpu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index d99038487a0d..a3a8e008f957 100644 --- a/drivers/base/cpu.c +++ b/drivers/base/cpu.c @@ -531,9 +531,9 @@ ssize_t __weak cpu_show_spectre_v2(struct device *dev, return sprintf(buf, "Not affected\n"); } -static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL); -static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL); -static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL); +static DEVICE_ATTR(meltdown, 0400, cpu_show_meltdown, NULL); +static DEVICE_ATTR(spectre_v1, 0400, cpu_show_spectre_v1, NULL); +static DEVICE_ATTR(spectre_v2, 0400, cpu_show_spectre_v2, NULL); static struct attribute *cpu_root_vulnerabilities_attrs[] = { &dev_attr_meltdown.attr,