Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp246035ybl; Thu, 15 Aug 2019 16:34:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqyxPS0N0dQpyKURAG4sfzrbjwgkFPomAAIY8LZBKIvRzAS7SPSRgN8kEMDRqHCnt7tKLPRK X-Received: by 2002:a05:6a00:46:: with SMTP id i6mr8012910pfk.196.1565912097883; Thu, 15 Aug 2019 16:34:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565912097; cv=none; d=google.com; s=arc-20160816; b=bUuuRllFdzY8kTHBTPWJ70INI9ijzzJ9z3GVKDdnVwWLqbWP3Lov2fnqndzJm6s501 sComPYG6vLs4m4+j90KGg4ujPf47f4HWa/vQFiK+4zCG68I8i+J2qIdsFye3CkMW3L9L 4HCOIzqY8AfDlBVmSUqXUFZpBEawYX/OycT13clmY64eZxBYg9HnFcYPN5w+K+rQdES1 LB9j8nq7pgE2kCvRIukWeF/5CA22bbNWmNo42uTfkvXq274v9Wg3L85WvK9Fh2qDjU2L JFpjlcjY8A8fIFCv4V3DOpknI6klIJY9j7FpJVj/wiOP7azGh7wNi66YI2U5Hj397jH5 fWXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=ygYxAHopwLOSCPdD3GYy2RIOmkS0AOfuT9cQ/dEh75s=; b=TwaXAWm+b9Yf+98PhG0u4b0RiYEWBrZhyZOAtEmTSayhSqMusBI6yUHvG3KR61buRa M8c1FDoG7qps0X6UITeQ35KTgbjv/0W+VpAyOCJMPGamO2je7Ov5Vy5dWB/YRkb+YB0w uUyOlF7seqP9aiRV5QzxhyAXiErGaDh2v597IKdE8gMWpk9lZ2fDmIkOlwLpcveE5RIs 6gJFSotRLW51CzJtcvQxjDnPaHv2KRD2SBhXtbCV1KJcbihp7LoDmDA9hoKuVHrpBl9o JG2o6hwgKQkabsaesWlfOreV67+L7XFpbqUgTQiz7kcgbA06dNHwZV0TBeHT0TsKo/nt 6kjw== 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 y19si2815324pll.326.2019.08.15.16.34.42; Thu, 15 Aug 2019 16:34:57 -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; 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 S1731511AbfHOVER (ORCPT + 99 others); Thu, 15 Aug 2019 17:04:17 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:40858 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726008AbfHOVER (ORCPT ); Thu, 15 Aug 2019 17:04:17 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hyMup-000685-8z; Thu, 15 Aug 2019 23:04:11 +0200 Date: Thu, 15 Aug 2019 23:04:10 +0200 (CEST) From: Thomas Gleixner To: Andrew Cooper cc: "Lendacky, Thomas" , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-pm@vger.kernel.org" , "x86@kernel.org" , Ingo Molnar , Borislav Petkov , "Rafael J . Wysocki" , Pavel Machek , Chen Yu , Jonathan Corbet Subject: Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h In-Reply-To: Message-ID: References: <776cb5c2d33e7fd0d2893904724c0e52b394f24a.1565817448.git.thomas.lendacky@amd.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1612320073-1565903051=:1908" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1612320073-1565903051=:1908 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Thu, 15 Aug 2019, Andrew Cooper wrote: > On 14/08/2019 22:17, Lendacky, Thomas wrote: > > +static void init_hide_rdrand(struct cpuinfo_x86 *c) > > +{ > > + /* > > + * The nordrand option can clear X86_FEATURE_RDRAND, so check for > > + * RDRAND support using the CPUID function directly. > > + */ > > + if (!(cpuid_ecx(1) & BIT(30)) || rdrand_force) > > + return; > > + > > + msr_clear_bit(MSR_AMD64_CPUID_FN_00000001, 62); > > + clear_cpu_cap(c, X86_FEATURE_RDRAND); > > + pr_info_once("hiding RDRAND via CPUID\n"); > > If you're virtualised, the write to MSR_AMD64_CPUID_FN_1 almost > certainly won't take effect, which means userspace will still be able to > see the bit. > > Best to leave everything untouched if you can't actually clear the bit.  > All you can do is trust that your hypervisor knows what it is doing. Well, we can read the CPUID entry again after writing that MSR bit. If it still says RDRAND is available then we know that the hypervisor did not allow the write and print something to that effect. Thanks, tglx --8323329-1612320073-1565903051=:1908--