From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965243AbcKXLVA (ORCPT ); Thu, 24 Nov 2016 06:21:00 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:58553 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964851AbcKXLU6 (ORCPT ); Thu, 24 Nov 2016 06:20:58 -0500 X-ME-Sender: X-Sasl-enc: R6S5elHNKOeN4BNbROes/qNLysCpe0v1eVW4xLa+BZu+ 1479986457 Date: Thu, 24 Nov 2016 09:20:54 -0200 From: Henrique de Moraes Holschuh To: Tony Luck Cc: Borislav Petkov , "Luck, Tony" , Andi Kleen , Ashok Raj , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] x86/mce: Include the PPIN in machine check records when it is available Message-ID: <20161124112054.GA16600@khazad-dum.debian.net> 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> <4BEAD8B5-4901-4FC4-974E-F2C2D1FBA5C0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BEAD8B5-4901-4FC4-974E-F2C2D1FBA5C0@gmail.com> X-GPG-Fingerprint1: 4096R/0x0BD9E81139CB4807: C467 A717 507B BAFE D3C1 6092 0BD9 E811 39CB 4807 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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