[MODERATED] Re: [PATCH v5 01/11] TAAv5 1

[Andy Lutomirski <luto@amacapital.net>]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

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.
> 
> TSX has two sub-features:
> 
> 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.
> 
> Bit 7 of the IA32_ARCH_CAPABILITIES indicates the presence of the
> IA32_TSX_CTRL MSR.
> 
> There are two control bits in IA32_TSX_CTRL MSR:
> 
>   Bit 0: When set it disables the Restricted Transactional Memory (RTM)
>          sub-feature of TSX (will force all transactions to abort on the
> 	 XBEGIN instruction).
> 
>   Bit 1: When set it disables the enumeration of the RTM feature (i.e.
>          it will make CPUID(EAX=7).EBX{bit11} read as 0).
> 
> The other TSX sub-feature, Hardware Lock Elision (HLE), is unconditionally
> disabled but still enumerated as present by CPUID(EAX=7).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.