Re: [PATCH] clarify how insecure CPU is

[Borislav Petkov <bp@suse.de>]

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)
--