linux-kernel - Re: [PATCH v2] x86/mce: Include the PPIN in machine check records when it is available

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:   Thu, 24 Nov 2016 09:20:54 -0200
From:   Henrique de Moraes Holschuh <hmh@....eng.br>
To:     Tony Luck <tony.luck@...il.com>
Cc:     Borislav Petkov <bp@...e.de>, "Luck, Tony" <tony.luck@...el.com>,
        Andi Kleen <andi@...stfloor.org>,
        Ashok Raj <ashok.raj@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] x86/mce: Include the PPIN in machine check records
 when it is available

On Wed, 23 Nov 2016, Tony Luck wrote:
> IMHO people who really care should find the BIOS option and disable it
> there. 

That can also be said about *enabling* it, I think (see below).

> Having Linux take responsibility seems a little weird. If we do go

Not really.  The currently proposed patch *enables* PPIN if it is found
to be disabled but unlocked.  That pretty much means Linux _would_ take
the responsibility, the blame, and the outrage of privacy advocates (if
any).

If we enable it, it is our fault, plain and simple.

> I also wonder about the level of outrage this time around. The feature
> has been sitting there for three full generations: Ivybridge (tick),
> Haswell (tock) and another tick for Broadwell. Do privacy folks not
> read each new SDM from cover to cover?

I very much doubt so :-)

And it would take a very through and careful read of the SDM changes to
find it, if you are not searching for it by name.

But even if the privacy advocates did read the SDM changelogs very
carefully and took notice of it, the PPIN feature clearly looks like it
was designed to protect the privacy of anyone that did not especifically
want it enabled.

1. PPIN is disabled on hard reset (as far as I can tell).

2. BIOS/UEFI ships it disabled by default, as recommended by SDM
   ("opt-in" feature).  Although it should have recommended that it
   be *locked* disabled by default, thus *ensuring* opt-in.

3. Opt-in bias is enforced in hardware (the firmware cannot lock the
   feature in an enabled state).

4. Access violations (read when disabled, unlock, etc) will raise
   a #GP, thus getting the operating system/firmware crash handler
   involved immediately.

The expected usecase is, as described in the IA32 SDM: a trusted asset
agent will enable, read the PPIN, and lock it disabled afterwards.  That
"lock it disabled" would get in the way of general abuse of the feature
by random ISVs.

I think the architecture / hardware / microcode people @intel covered
their angle really well on this.  Anyone that raise a ruckus on the fact
that PPIN exists (as described in the SDM) is not going to look very
reasonable.

I recommend that the Linux kernel should take the same instance as the
intel hardware/microcode team did: don't enable it by default, don't
make it easy for any ISVs to abuse it without positive opt-in action
from the local system admin.

This is why I also recommend that the kernel should always lock it
disabled -- whether we read the PPIN for kernel use (when PPIN was
enabled by the BIOS[1]) or not.  It indeed *is* the kernel taking
responsibility for side-stepping the whole "rdmsr is for ring 0"
architectural security model due to unfiltered /dev/cpu/msr.

[1] I personally have nothing against an override, e.g. a kernel
command-line parameter, that allows the kernel to enable PPIN when the
BIOS left it unlocked, as long as it is not done by default.

-- 
  Henrique Holschuh