Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v2] x86/mce: Include the PPIN in machine check records when it is available
From: Tony Luck <tony.luck@gmail.com>
In-Reply-To: <20161123172916.GA19621@khazad-dum.debian.net>
Date: Wed, 23 Nov 2016 12:56:18 -0800
Cc: Borislav Petkov <bp@suse.de>, "Luck, Tony" <tony.luck@intel.com>,
        Andi Kleen <andi@firstfloor.org>, Ashok Raj <ashok.raj@intel.com>,
        linux-kernel@vger.kernel.org
Message-Id: <4BEAD8B5-4901-4FC4-974E-F2C2D1FBA5C0@gmail.com>
References: <878tsg67r3.fsf@tassilo.jf.intel.com> <1479491316-11716-1-git-send-email-tony.luck@intel.com> <20161123114855.njguoaygp3qnbkia@pd.tnic> <20161123132951.GA9373@khazad-dum.debian.net> <20161123133723.vyi7bv46h3pulldc@pd.tnic> <20161123172916.GA19621@khazad-dum.debian.net>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 1896
Lines: 42

IMHO people who really care should find the BIOS option and disable it there. 

Having Linux take responsibility seems a little weird. If we do go that route it should be early in setup_arch() before any callbacks to other subsystems to avoid and endless games of whack-a-mole.

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?

Sent from my iPhone

> On Nov 23, 2016, at 09:29, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> 
>> On Wed, 23 Nov 2016, Borislav Petkov wrote:
>>> On Wed, Nov 23, 2016 at 11:29:51AM -0200, Henrique de Moraes Holschuh wrote:
>>> 1. Assuming we can do it, always lock it when it is found to be unlocked
>>>   at kernel boot.
>> 
>> Because...?
> 
> Privacy, and the fact that /dev/cpu/msr exists and is enabled on
> almost all general-use distros.
> 
>>> 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.
>> 
>> You can't reenable it:
> 
> Yeah, I just found the description for that thing in the IA32 manual. 
> 
> It can be disabled + unlocked, disabled + locked, or enabled + unlocked.
> Once locked, it will stay disabled until the next reboot.
> 
> However, the manual makes it clear we are _not_ supposed to leave it
> enabled + unlocked.  Apparently, we're supposed to do our business and
> disable+lock it (i.e.  enable, read and store/process, disable+lock).
> 
> Looks like it is supposed to be used in a way that protects privacy by
> making it very hard for general use software to depend on it existing
> and being enabled.
> 
> -- 
>  Henrique Holschuh