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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190906151617.GE19008@zn.tnic>
Date:   Fri, 6 Sep 2019 17:16:17 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Johannes Erdfelt <johannes@...felt.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Mihai Carabas <mihai.carabas@...cle.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Jon Grimm <Jon.Grimm@....com>, kanth.ghatraju@...cle.com,
        konrad.wilk@...cle.com, patrick.colp@...cle.com,
        Tom Lendacky <thomas.lendacky@....com>,
        x86-ml <x86@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/microcode: Add an option to reload microcode even if
 revision is unchanged

On Fri, Sep 06, 2019 at 07:40:39AM -0700, Johannes Erdfelt wrote:
> You say that switching of CPU feature bits is problematic, but adding
> new features should result only in a warning ("x86/CPU: CPU features
> have changed after loading microcode, but might not take effect.").

That's the only sane thing we can do ATM - warn the user to reboot.

> Removing a CPU feature bit could be problematic. Other than HLE being
> removed on Haswell (which the kernel shouldn't use anyway), have there
> been any other cases?

I hope there aren't. There are cases, however, where late loading cannot
fix an issue, like paging on some old Atoms. And then you *must* do
early loading or stick it in the BIOS. But we all know how the latter
works in practice.

> I ask because we have successfully used late microcode loading on tens
> of thousands of hosts.

How do you deal with all the mitigations microcode loaded late?

> I'm a bit worried to see that there is a push to remove a feature that
> we currently rely on.

I'd love to remove it. And the fact that people rely on it more instead
of fixing their infrastructure to reboot machines and do early microcode
updates is making it worse. Microcode update should be batched with
kernel updates and that's it. They happen normally once-twice per year -
except the last two years but the last two years are not normal anyway
- and done. No need to do some crazy CPUID features reloading dances in
the kernel and making sure cores will see the updated paths and so on.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ