Received: by 10.223.176.5 with SMTP id f5csp552216wra; Sat, 27 Jan 2018 05:19:25 -0800 (PST) X-Google-Smtp-Source: AH8x224s9qDYGCWL0fKeUy6gOOOlC7Mt9AIceVJsRk9ny8FXgdHQzLSAFiOuOpeuy4X1AIGTkI8C X-Received: by 10.98.60.132 with SMTP id b4mr22077611pfk.120.1517059165126; Sat, 27 Jan 2018 05:19:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517059165; cv=none; d=google.com; s=arc-20160816; b=Fl8NvjGJK4Bwn1PFIkFDXJUqKCIlCSImXq+qB7ulXe/8YBj+mWj34Ch1WFZq/QZiH6 QH2GSFDMxJZMU5UXKVdOGzFdkRSMGIXSE9MbmI2tdA3/tW8eceBOU8y62ErvqwQQFZB7 hHRIiroe9HsJAv/qabc/NUC5zpSqRLL1HzQ/H97F0SIoz8JI/fk6OcUgwYiwb15sa94d xUS0Ie66gWwjffqLqZWcY6xkbGOWOm4H+wbTvOPeX9vZMdCA6QrK8jhxTu1wWv7MDMBs azQQeq/ohYyMAIA3OS7HJoDf1W7rZ9znXhTr5pWrAlSzKBlz2A7yyVzUS/buPqOy26Pn UrlA== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=mnWwjsZxv9Tll50fijhBOl0C9lRwoXyfzTimd3KD7cA=; b=XbMj/vdbDFcz2atKS/PPeqbnxtJmOKpzsRLJMiMTc5Tr40sD6jhQMLHM6MAPxTDJQ1 INFHlgzkY6DvPKatEEBY4SV1etK7JFCIIJrqLJ/c65XimXXLkXefbVtRHIWmxBNQXW1X xXIfTzKooNcseXjbD2WUQEW1RN2lAPgPFfhpN+aJXrQQ33fVtbQHeNhXe5hTyQcHeTbw SztTJ3I14qT72tnoaV/o+Df/toFBWc8Xo2pqkfkie4/id8UTWpYFl9RdLWHwIATbof7m 0/QcZoSDgShi39nU8hmxVqDoSsYI74si5JrR9qQRl/CVPIMzARu1LMBI9/x259LzAgju ntZg== 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 66-v6si5407064pla.131.2018.01.27.05.19.10; Sat, 27 Jan 2018 05:19:25 -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 S1752758AbeA0NSo (ORCPT + 99 others); Sat, 27 Jan 2018 08:18:44 -0500 Received: from mail.skyhub.de ([5.9.137.197]:49086 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751882AbeA0NSn (ORCPT ); Sat, 27 Jan 2018 08:18:43 -0500 X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (blast.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WuiBDPQc74yu; Sat, 27 Jan 2018 14:18:41 +0100 (CET) Received: from pd.tnic (p200300EC2BE03F0018898899508E3FC1.dip0.t-ipconnect.de [IPv6:2003:ec:2be0:3f00:1889:8899:508e:3fc1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 96AAF1EC0361; Sat, 27 Jan 2018 14:18:41 +0100 (CET) Date: Sat, 27 Jan 2018 14:18:29 +0100 From: Borislav Petkov To: David Woodhouse Cc: Tom Lendacky , x86-ml , linux-tip-commits@vger.kernel.org, hpa@zytor.com, gregkh@linuxfoundation.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, mingo@kernel.org Subject: Re: [PATCH] x86/cpufeatures: Cleanup AMD speculation feature bits Message-ID: <20180127131829.4kbi5mbqiqbbhbdw@pd.tnic> References: <1516992318.30244.271.camel@infradead.org> <20180126184915.ioqewp56orj2qhrt@pd.tnic> <7094ed9b-40f7-ba2b-55a6-cc5ab0b06bb9@amd.com> <20180126215209.vqdxh5p672tcdst6@pd.tnic> <1517003984.30244.299.camel@infradead.org> <20180126221026.hc2hk23zsqbqhkif@pd.tnic> <2cea933f-7e06-26d5-95cf-41df8308a0f8@amd.com> <1517045268.30244.305.camel@infradead.org> <20180127093722.t6dn4sgocihjjq37@pd.tnic> <1517049146.6624.5.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1517049146.6624.5.camel@infradead.org> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 27, 2018 at 10:32:26AM +0000, David Woodhouse wrote: > No because cpuinfo should be information about the CPU. That argument doesn't work in this case because we're already lying there. Otherwise we would've never had the synthetic features in the first place. If you *really* wanna know what the CPU has, you use CPUID. Which is also more or less a lie on virt, but that's a whole another story. > For details of what mitigations are *actually* in use on this kernel, > you want /sys/…/cpu/vulnerabilities, which might not even be > readable by a non- root user. > > That's why I've used the names that we want to see in cpuinfo, for the > basic CPU functionality. So the sysfs nodes are perhaps an exception in this already exceptional case due to the need to properly communicate mitigations. Which kinda is the reason for why I'm advocating for common names in /proc/cpuinfo and not having the hardware feature names which only confuse people. And we do synthetic bits anyway. X86_BUG_ included. > Does it exist, vs. whether the kernel is *using* it. You can use the sysfs node for the latter. Also, is it really using it doesn't always work: late microcode loading which enables a CPUID bit but alternatves don't run late. Which is the reason we said we won't do IBRS with late loading. > The latter being a little bit of a hack because alternatives > *only* let us do this stuff based on "CPU features", which is why > X86_FEATURE_PTI exists. > > That one probably shouldn't be user-visible in /proc/cpuinfo *either*, > should it? Why not? We have a lot of synthetic flags. > I think I covered this, but for clarity: No, because the *hardware* > feature is the one we want to be called just "ibpb" in /proc/cpuinfo. I still see it the opposite way here: I'd much prefer to have unified view in /proc/cpuinfo so that our communication outwards is absolutely clear and simple: three feature flags. Regardless of box. /sys/…/cpu/vulnerabilities being the additional thing for this exceptional situation. I don't really care about the actual feature bits. *Especially* since not everything supports CPUID faulting so we can't even hide CPUID from people on baremetal and they can find out what's really set there anyway. Btw, for example, ARM took "nopti" to be their chicken bit to disable the ARM PTI mitigation too. It is much simpler for users if you have the same names everywhere - so much so, that it even let's you get away with a small lie. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.