From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 24 Oct 2019 17:35:53 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iNh1b-0005Sk-Qg for speck@linutronix.de; Thu, 24 Oct 2019 19:35:52 +0200 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D82D9AC37 for ; Thu, 24 Oct 2019 17:35:45 +0000 (UTC) Date: Thu, 24 Oct 2019 19:35:38 +0200 From: Borislav Petkov Subject: [MODERATED] Re: [PATCH 8/9] TAA 8 Message-ID: <20191024173538.GG14115@zn.tnic> References: <5b426d6ab55e7aa9efc33f0e3eefe84419a18c56.1571905227.git.bp@suse.de> <20191024160312.auyqdk5geednwmdt@treble> MIME-Version: 1.0 In-Reply-To: <20191024160312.auyqdk5geednwmdt@treble> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: speck@linutronix.de List-ID: On Thu, Oct 24, 2019 at 11:03:12AM -0500, speck for Josh Poimboeuf wrote: > On Wed, Oct 23, 2019 at 12:32:55PM +0200, speck for Pawan Gupta wrote: > > +Virtualization mitigation > > +^^^^^^^^^^^^^^^^^^^^^^^^^ > > + > > +Affected systems where the host has the TAA microcode and the TAA mitiga= tion is > > +ON (with TSX disabled) are not vulnerable regardless of the status of th= e VMs. >=20 > This is is confusing: "the TAA mitigation is ON (with TSX disabled)". >=20 > Which is it? Is the TAA mitigation on, or is TSX disabled? I think it wants to say: "Affected systems where the host has TAA microcode and TAA is mitigated by having disabled TSX, are not vulnerable..." > This is not universally true. "Disables TSX on systems which have the TSX-disable MSR." >=20 > > + on Enables TSX. >=20 > This probably needs the same "TSX is fundamentally insecure" caveat I > proposed for kernel-parameters.txt. I'm great at copy'n'paste: "Enables TSX. Although there are mitigations for all known security vulnerabilities, TSX has been known to be an accelerator for several previous speculation-related CVEs, and so there may be unknown security risks associated with leaving it enabled." >=20 > > + > > + auto Disables TSX on affected platform, otherwise enables TSX. >=20 > This is not universally true. >=20 > Also, it would be relevant to refer to that table Pawan posted which > shows exactly which CPUs are vulnerable to TAA but not MDS. This one? I don't know whether this one will get more models later or what the TAA_NO plan is... +----------------------------+------------------+------------+ | Name | Family / model | Stepping | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ | Whiskey Lake (ULT refresh) | 06_8E | 0xC | +----------------------------+------------------+------------+ | 2nd gen Cascade Lake | 06_55 | 6, 7 | +----------------------------+------------------+------------+ | Coffee Lake R | 06_9E | 0xD | +----------------------------+------------------+------------+ >=20 > > + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > + > > +Not specifying this option is equivalent to "tsx=3Doff". > > + > > +The following combinations of the "tsx_async_abort" and "tsx" are possib= le. For > > +affected platforms tsx=3Dauto is equivalent to tsx=3Doff and the result = will be: > > + > > + =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > + tsx=3Don tsx_async_abort=3Dfull The system will use VERW to clea= r CPU > > + buffers. >=20 > The system may still be vulnerable to SMT-based attacks. >=20 > > + tsx=3Don tsx_async_abort=3Doff The system is vulnerable. > > + tsx=3Doff tsx_async_abort=3Dfull TSX is disabled. System is not v= ulnerable. > > + tsx=3Doff tsx_async_abort=3Doff TSX is disabled. System is not v= ulnerable. > > + =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Combinations with tsx_async_abort=3Dfull,nosmt should also be described. =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D tsx=3Don tsx_async_abort=3Dfull The system will use VERW to clear CPU buffers. Cross-thread attacks still possi= ble on SMT machines. tsx=3Don tsx_async_abort=3Dfull,nosmt As above, cross-thread attacks on= SMT mitigated. tsx=3Don tsx_async_abort=3Doff The system is vulnerable. tsx=3Doff tsx_async_abort=3Dfull TSX is disabled. System is not vulner= able. tsx=3Doff tsx_async_abort=3Dfull,nosmt ditto tsx=3Doff tsx_async_abort=3Doff ditto =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > +For unaffected platforms "tsx=3Don" and "tsx_async_abort=3Dfull" does no= t clear CPU > > +buffers. For platforms without TSX control "tsx" command line argument = has no > > +effect. >=20 > Which platforms are those? The MDS_NO=3D0 ones. >=20 > > +For the affected platforms below table indicates the mitigation status f= or the > > +combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits M= DS_NO > > +and TSX_CTRL_MSR. > > + > > + =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > + MDS_NO MD_CLEAR TSX_CTRL_MSR Status > > + =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > + 0 0 0 Vulnerable (needs ucode) > > + 0 1 0 MDS and TAA mitigated via VERW > > + 1 1 0 MDS fixed, TAA vulnerable if TSX en= abled > > + because MD_CLEAR has no meaning and > > + VERW is not guaranteed to clear buf= fers >=20 > (needs ucode) ? Will there even be microcode for those to beef up VERW? > > +2. Untrusted userspace and guests > > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > + > > +If there are untrusted applications or guests on the system, enabling TSX > > +might allow a malicious actor to leak data from the host or from other > > +processes running on the same physical core. >=20 > Unless the mitigation is enabled (which is on by default, BTW...) >=20 > This makes it sounds like the only mitigation is to disable TSX. "If there are untrusted applications or guests on the system, enabling TSX and the inability to enable the TAA mitigation (missing microcode for a particular model, etc.) might allow a malicious actor to leak data from the host or from other processes running on the same physical core." > > +If the microcode is available and the TSX is disabled on the host, attac= ks > > +are prevented in a virtualized environment as well, even if the VMs do n= ot > > +explicitly enable the mitigation. >=20 > What's the effect on VM security if TSX is enabled and the host TAA > mitigation is also enabled? Same as in the !VM case, I'd assume. tsx_async_abort=3Dfull,nosmt should give you full mitigation. > > + This parameter controls the TAA mitigation. The > > + options are: > > + > > + full - Enable TAA mitigation on vulnerable CPUs >=20 > if TSX is disabled No, that's TAA_MITIGATION_VERW which does the buffer clearing. > > +Mitigation strategy > > +------------------- > > + > > +a) TSX disable - one of the mitigations is to disable TSX. A new MSR > > +IA32_TSX_CTRL will be available in future and current processors after >=20 > which processors? The MDS_NO=3D1 and future parts, I guess. >=20 > > +microcode update which can be used to disable TSX. In addition, it > > +controls the enumeration of the TSX feature bits (RTM and HLE) in CPUID. > > + > > +b) Clear CPU buffers - similar to MDS, clearing the CPU buffers mitigate= s this > > +vulnerability. More details on this approach can be found in > > +:ref:`Documentation/admin-guide/hw-vuln/mds.rst `. >=20 > It should be clarified the mitigation is a) OR b), not both. Yah, the default one is b). if (boot_cpu_has(X86_FEATURE_MD_CLEAR)) taa_mitigation =3D TAA_MITIGATION_VERW; else taa_mitigation =3D TAA_MITIGATION_UCODE_NEEDED; unless nothing has been specified on the cmdline and it depends on what CONFIG_X86_INTEL_TSX_MODE* has been enabled in .config. I know, it is a mouthful. > > +1. "tsx=3Doff" > > + > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > +MSR_IA32_ARCH_CAPABILITIES bits Result with cmdline tsx=3Doff > > +---------------------------------- ------------------------------------= ------------------------------------- > > +TAA_NO MDS_NO TSX_CTRL_MSR TSX state VERW can clear TAA mi= tigation TAA mitigation > > + after bootup CPU buffers tsx_as= ync_abort=3Doff tsx_async_abort=3Dfull > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > + 0 0 0 HW default Yes Sa= me as MDS Same as MDS >=20 > Does "HW default" mean "Enabled"? I'd assume coming out of reset, TSX is enabled. Question for Intel folks. --=20 Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imend=C3=B6rffer, HRB 36809, = AG N=C3=BCrnberg --=20