Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752486AbeADStK (ORCPT <rfc822;ralf@linux-mips.org> + 1 other);
        Thu, 4 Jan 2018 13:49:10 -0500
Received: from www.llwyncelyn.cymru ([82.70.14.225]:46600 "EHLO fuzix.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751294AbeADStJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 4 Jan 2018 13:49:09 -0500
Date: Thu, 4 Jan 2018 18:48:45 +0000
From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        Dave Hansen <dave.hansen@intel.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Andi Kleen <ak@linux.intel.com>,
        Arjan Van De Ven <arjan.van.de.ven@intel.com>,
        linux-kernel@vger.kernel.org, David Woodhouse <dwmw@amazon.co.uk>
Subject: Re: [PATCH 5/7] x86: Use IBRS for firmware update path
Message-ID: <20180104184845.7a40525a@alans-desktop>
In-Reply-To: <8d3710432534b27d224283557c4629cd1aa5b0ea.1515086770.git.tim.c.chen@linux.intel.com>
References: <cover.1515086770.git.tim.c.chen@linux.intel.com>
        <8d3710432534b27d224283557c4629cd1aa5b0ea.1515086770.git.tim.c.chen@linux.intel.com>
Organization: Intel Corporation
X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>

On Thu,  4 Jan 2018 09:56:46 -0800
Tim Chen <tim.c.chen@linux.intel.com> wrote:

> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> We are impervious to the indirect branch prediction attack with retpoline
> but firmware won't be, so we still need to set IBRS to protect
> firmware code execution when calling into firmware at runtime.

If you are going to care about APM then you also need to care about
BIOS32 interfaces (arch/x86/pc/pcibios.c) and PNPBIOS
(drivers/pnp/pnpbios/bioscalls.c)

Alan