[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/3] x86/amd: Use newer SSBD mechanisms if they exist

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Tue, 24 Aug 2021 14:39:28 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QXLmZKSBjQzLtyoYnt9Oi1eIVRSdWKKbCacrreWnqqA=; b=Vrde5BAcO8RhgMWInuXa9zP63p+qSf3bEFpswg52IPQ0bBQWmRvhg0BMTzwRH65HKFsrBKH4Jivl1EaMLTH+szpooLkMaSJ6V5gfhRBrosPSKEZTC+UMja4YvBnS2XIEjdrdZ33BDkrQL4zLPRRf68BAgeKtRKZwUNVpMBZSLvY8n4pfhKJu+XXd/V0fbJ1gANOp1F0pwDg3GUHDP2Wrg7M1Z4UJk8uQieKkttR7BqSqawq2qlpfTOJSmVk9PiT2dckmBruxA9eyLvY4EhMrCINjYPKXiUUgQ4RldM3tdKULSki+c5466Gu+AQCNLaPrj+wM9B7bsi/x7wOnSPkq2A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OW8CCvSV1gMSwvkWS2yT+DA/YC1R88iaudbOh8kGGvP/0WpOu4NOh33JaVFgXF4sxLDtJ2CzjGYChVoQFkTx3vgj0YJT9/cJEcKVIm1KWorw9LH+LmwV0awQDC0p7LfATIgtcofbkJR80zxJ/DW/2Sq8aYvG/wNq0E90R/j2TDXaBZ+lbkeiAMJV5to+qHLqqmYlc9psZ8QI5/hdX6MVQJ7cN6yKNOrDJF8AUO8Nh75wDYDh01aBkyW/JUhF7bk2Iqi47MJ9ewK7Uz62hcxihHNnMO2x2SkiZzWhTj1Yzp2B1ETBR72JMwycM5iDfaNmvcMDGZt9BN9ymh+OH+K/Vw==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Wei Liu <wei.liu2@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 24 Aug 2021 13:39:43 +0000
  • Ironport-hdrordr: A9a23:0SDa962WO3DZ1MgvtI3VbAqjBLwkLtp133Aq2lEZdPU1SKClfq WV98jzuiWatN98Yh8dcLK7WJVoMEm8yXcd2+B4V9qftWLdyQiVxe9ZnO7f6gylNyri9vNMkY dMGpIObOEY1GIK7/rH3A==
  • Ironport-sdr: ajIP/2OeHlGhY7ipKSbfIncXOOfZT0jslPReZ3YML8T0mbopXb7JEIm2ZW49zEhEceOtlS6V7j 04eSggSjfs1fQnDB1wOpiXjwFH/NrnIoOtBwzj9fM+AQP6o5DI6VnGq6KX1rviE1l+IK6yr4zk wx9kxvdeVWCY3cEucLQ/jPGf3PQVqwNkJzQmiq8vLBhqUefg5lADSE4Npu3ZR0evKYUAL99mzs dNa2f+JD0N+eSY6rttKSaEWCS4Fi8dhAua5NB2+TKQ/YvOeg+B3g1RVGrtnmruq2JWM/X3aFqs WoP/BXvP7X//B/Ecj/0Xhls3
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19/08/2021 15:59, Jan Beulich wrote:
> On 17.08.2021 16:30, Andrew Cooper wrote:
>> The opencoded legacy Memory Disambiguation logic in init_amd() neglected
>> Fam19h for the Zen3 microarchitecture.
>> In practice, all Zen2 based system (AMD Fam17h Model >= 0x30 and Hygon Fam18h
>> Model >= 0x4) have the architectural MSR_SPEC_CTRL and the SSBD bit within 
>> it.
>> Implement the algorithm given in AMD's SSBD whitepaper, and leave a
>> printk_once() behind in the case that no controls can be found.
>> This now means that a user choosing `spec-ctrl=no-ssb` will actually turn off
>> Memory Disambiguation on Fam19h/Zen3 systems.
> Aiui you mean `spec-ctrl=no-ssbd` here? And the effect would then be
> to turn _on_ Memory Disambiguation, unless the original comment was
> the wrong way round? I'm also concerned by this behavioral change:
> I think opt_ssbd would want to become a tristate, such that not
> specifying the option at all will not also result in turning the bit
> off even if it was on for some reason (firmware?). Similarly
> "spec-ctrl=no" and "spec-ctrl=no-xen" imo shouldn't have this effect.

I messed that bit of the description up.  I means `spec-ctrl=ssb`, i.e.
the non-default value.

We do not disable Memory Disambiguation (the speculative feature which
causes the Speculative Store Bypass vulnerability) by default (due to
the perf hit), but if the user explicitly asks for it using the
available command line option, nothing currently happens on Fam19h.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.