From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224oXaH59tPu4/4HUSkMJzkh9VFjNVgHXRQoRh37+bc3EtsWNBbSF7T7VXwVF0dhO14lMJFt ARC-Seal: i=1; a=rsa-sha256; t=1516983821; cv=none; d=google.com; s=arc-20160816; b=L2LYPwzgpPMhs48IYnjEvarTfNgD7+KcIQAIvR4Kvb6V13+/XZ9dLjX7U2ZgSVW9jU nD41l1LJ+NCGJtcpim9yuoPA7Ys13UidvEC490Q74gChCrVV4PCTnzvpXKjHP1OqB/bH hlZ9zKALLByBHZXIb7dtdr/5EwkHEFOGNvBxJ6lChOeierZTsIeGEcpHkJGtblCd4Ty8 AzipBJKbY0TAlWO+Qx2nhrTWijdHnxRTON0p0wMY8Kp8Fcw1MK42Judcr1Lgk5GhTPXo Gav7kKxrQEEG0Kn7YGExiqBxXCUGAJpxsYYipe45uovqvgV/Lwep1rhw0uir+pwLXUMN kJkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=BWrMGzT2RKmOYZQHsc/Ef4QHU5repEuMvPwzW0LEKK8=; b=Bdc30Q5WBZk03+BXhqQWrIwtFmAyn1L82ZWlOwlab2/pCK+MjVQ4Hps09y5iudYcv+ wthYnQRGWRhnY7doRr90jsPXJtoFpsKKZiZs0d0BJ3pf5xxFKE3regqEh9s4jVw6aayi XepIiqaMUgtorMXPU+lLL8dKq3g0nWP0P93yWCjmV4OHZG1gi3d9NL9zaPHsGAX2p0po B/+tdyxbVRItmV0YHKYgCW2R9X8sXa5WNw2fyE5HIqYxDwng5IMaULZdmHvC4cCTp3YH 5LTrC/GcWXMFRswkFcH3uZBjwV7i5iPc4BDlUPIzS7cUNCfathP8Ejx0z1jD0KlepspZ y8Cw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of aarcange@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=aarcange@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of aarcange@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=aarcange@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com 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-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1588969353158471989?= X-GMAIL-MSGID: =?utf-8?q?1590672827029363934?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 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,