linux-kernel - Re: [patch 01/10] x86/fpu/signal: Clarify exception handling in restore_fpregs_from

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: <YS8rbA239gXOT6R6@zn.tnic>
Date:   Wed, 1 Sep 2021 09:27:40 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Dan Williams <dan.j.williams@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>
Subject: Re: [patch 01/10] x86/fpu/signal: Clarify exception handling in
 restore_fpregs_from_user()

On Tue, Aug 31, 2021 at 11:39:21AM -0700, Luck, Tony wrote:
> You can imagine all you want. And if your imagination is based
> on experiences with very old systems like Haswell (launched in 2015)
> then you'd be right to be skeptical of firmware capabilities.

I wish it were only Haswell boxes. Do you remember how many times I've
talked to you in the past about boxes with broken einj? I don't think
they were all Haswell but I haven't kept track.

> Turn off eMCA in BIOS to avoid this.

I'll try. That is, provided there even is such an option.

> The injection controls in the memory controller can only be accessed
> in SMM mode. Some paranoia there that some ring0 attack could inject
> errors at random intervals causing major costs to diagnose and replace
> "failing" DIMMs. So documentation wouldn't help Linux because it just
> can't twiddle the necessary bits in the h/w.

Yah, that's why this thing needs a BIOS switch which controls injection.
And probably they do that already.

> Downsides of ACPI/EINJ today:
> 1) Availability on production machines. It is always disabled by default
> in BIOS.

That's ok.

> OEMs may not provide a setup option to turn it on (or may have deleted
> the code to support it completely).

Yeah, that's practically the same thing I'm complaining about - einj is
just as useless as before in that case.

> Intel's pre-production servers always have the code, and the setup
> option to enable.

Except that only you and a couple of partners have access to such
boxes. I guess tglx has too and if so that at least answers his initial
complaint about not having an injection method to test kernel code.

> 2) Doesn't inject to 3D-Xpoint (that has its own injection method, but
> it is annoying to have to juggle two methods).

I guess that doesn't matter for our use case of wanting to test the MCE
code, provided one can at least inject somewhere.

> 3) Hard/impossible to inject into SGX memory (because BIOS is untrusted
> and isn't allowed to do a store to push the poison data to DDR).

Oh well.

So, I really wanna believe you that injection capability has improved
but until I see it with my own eyes, I will remain very much sceptical.
And considering how firmware and OEMs are at play here, sceptical is
just the right stance.

-- 
Regards/Gruss,
    Boris.

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