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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161123132951.GA9373@khazad-dum.debian.net>
Date:   Wed, 23 Nov 2016 11:29:51 -0200
From:   Henrique de Moraes Holschuh <hmh@....eng.br>
To:     Borislav Petkov <bp@...e.de>
Cc:     "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, Borislav Petkov wrote:
> +		/* if PPIN is disabled, but not locked, try to enable: */
> +		if (!(val & 3ul)) {
> +			wrmsrl_safe(MSR_PPIN_CTL,  val | 2ul);
> +			rdmsrl_safe(MSR_PPIN_CTL, &val);
> +		}

Actually, since this thing is supposed to be opt-in [through UEFI
config] for a good reason (privacy), IMHO it would make more sense to:

1. Assuming we can do it, always lock it when it is found to be unlocked
   at kernel boot.

2. Not attempt to change its state from disabled to enabled *unless*
   given a command line parameter authorizing it.  A kconfig-based
   solution for default+command line override would also work well IMHO,
   if it makes more sense.

This would keep the feature opt-in as it is supposed to be, while making
it "safer" on firmware that leaves it unlocked after boot, and would
still allow owners of systems that leave it unlocked to change its
state at boot.  Everyone ends up happy...

-- 
  Henrique Holschuh