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 ; 05 Oct 2019 21:50:02 -0000 Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1iGrw8-0006M0-To for speck@linutronix.de; Sat, 05 Oct 2019 23:50:01 +0200 Received: by mail-pl1-x629.google.com with SMTP id e5so4864167pls.9 for ; Sat, 05 Oct 2019 14:50:00 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:3602:86ff:fef6:e86b? ([2601:646:c200:1ef2:3602:86ff:fef6:e86b]) by smtp.googlemail.com with ESMTPSA id d19sm9157738pjz.5.2019.10.05.14.49.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Oct 2019 14:49:52 -0700 (PDT) Subject: [MODERATED] Re: [PATCH v5 01/11] TAAv5 1 References: <5d9838f1.1c69fb81.f1bab.d886SMTPIN_ADDED_BROKEN@mx.google.com> From: Andy Lutomirski Message-ID: <9f870b70-5102-422a-d60b-2af3999f0962@amacapital.net> Date: Sat, 5 Oct 2019 14:49:51 -0700 MIME-Version: 1.0 In-Reply-To: <5d9838f1.1c69fb81.f1bab.d886SMTPIN_ADDED_BROKEN@mx.google.com> Content-Type: multipart/mixed; boundary="WiDiPptn34YUZkxpRUtHzmPcxt06evDJL" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --WiDiPptn34YUZkxpRUtHzmPcxt06evDJL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/4/19 11:26 PM, speck for Pawan Gupta wrote: > Transactional Synchronization Extensions (TSX) may be used on certain > processors as part of a speculative side channel attack. A microcode > update for existing processors that are vulnerable to this attack will > add a new MSR, IA32_TSX_CTRL to allow the system administrator the > option to disable TSX as one of the possible mitigations. [Note that > future processors that are not vulnerable will also support the > IA32_TSX_CTRL MSR]. Add defines for the new IA32_TSX_CTRL MSR and its > bits. >=20 > TSX has two sub-features: >=20 > 1. Restricted Transactional Memory (RTM) is an explicitly-used feature > where new instructions begin and end TSX transactions. > 2. Hardware Lock Elision (HLE) is implicitly used when certain kinds of= > "old" style locks are used by software. >=20 > Bit 7 of the IA32_ARCH_CAPABILITIES indicates the presence of the > IA32_TSX_CTRL MSR. >=20 > There are two control bits in IA32_TSX_CTRL MSR: >=20 > Bit 0: When set it disables the Restricted Transactional Memory (RTM)= > sub-feature of TSX (will force all transactions to abort on th= e > XBEGIN instruction). >=20 > Bit 1: When set it disables the enumeration of the RTM feature (i.e. > it will make CPUID(EAX=3D7).EBX{bit11} read as 0). >=20 > The other TSX sub-feature, Hardware Lock Elision (HLE), is unconditiona= lly > disabled but still enumerated as present by CPUID(EAX=3D7).EBX{bit4}. Does the kernel need to intercept CPUID to clear the HLE bit to avoid potential performance loss? I can imagine some programs using alternate code paths that are better in the non-HLE case. --WiDiPptn34YUZkxpRUtHzmPcxt06evDJL--