Messages in this thread | | | Date | Sun, 4 Mar 2018 15:27:36 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH] clarify how insecure CPU is |
| |
On Sun, Mar 04, 2018 at 03:01:48PM +0100, Pavel Machek wrote: > > Not "might be needed" - "X86_BUG_AMD_APIC_C1E will be set if platform is > > affected". > > That's not what Thomas was explaining to me.
It is in the comment he pasted:
* Check whether the machine is affected by erratum 400. This is * used to select the proper idle routine and to enable the check * whether the machine is affected in arch_post_acpi_init(), which * sets the X86_BUG_AMD_APIC_C1E bug depending on the MSR check.
> So.. what's magical about it, why do we need two bits, and why is that > not explained in the header file?
Lemme enable line numbers so that you can find it:
arch/x86/include/asm/cpufeatures.h: 19 /* 20 * Note: If the comment begins with a quoted string, that string is used 21 * in /proc/cpuinfo instead of the macro name. If the string is "", 22 * this feature bit is not displayed in /proc/cpuinfo at all.
> Please go through the email thread,
No, you read Thomas' mail again.
> I'm trying to understand what is going on here,
Nothing's going on, it works as designed.
X86_BUG_AMD_E400 marks all CPUs which could be affected by erratum 400 and X86_BUG_AMD_APIC_C1E is the bit we set when we detect that the CPU is *actually* affected because we need to do the detection late, after ACPI has been initialized.
A CPU might be affected by the erratum - bit X86_BUG_AMD_E400 - but if the BIOS doesn't enter C1E, then the erratum doesn't come to manifest itself, i.e., we don't set X86_BUG_AMD_APIC_C1E.
If it is still not clear, read the erratum 400 description in the revision guide.
The code works perfectly fine.
Unless you're experiencing a problem with it. Then I'm all ears.
-- Regards/Gruss, Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
| |