linux-kernel - Re: [PATCH] clarify how insecure CPU is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 4 Mar 2018 15:27:36 +0100
From:   Borislav Petkov <bp@...e.de>
To:     Pavel Machek <pavel@....cz>
Cc:     Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
        r.marek@...embler.cz, ricardo.neri-calderon@...ux.intel.com,
        rkrcmar@...hat.com, Janakarajan.Natarajan@....com, x86@...nel.org,
        hpa@...or.com, mingo@...hat.com,
        Linus Torvalds <torvalds@...ux-foundation.org>
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)
--