From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753198AbcAVLJX (ORCPT ); Fri, 22 Jan 2016 06:09:23 -0500 Received: from mail-wm0-f48.google.com ([74.125.82.48]:34072 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752913AbcAVLIk (ORCPT ); Fri, 22 Jan 2016 06:08:40 -0500 Message-ID: <1453460916.15129.70.camel@nexus-software.ie> Subject: Re: [PATCH] x86/intel/quark: Remove lock bit around kernel IMR From: "Bryan O'Donoghue" To: Andy Shevchenko Cc: "x86@kernel.org" , "linux-kernel@vger.kernel.org" , stable@vger.kernel.org Date: Fri, 22 Jan 2016 11:08:36 +0000 In-Reply-To: References: <1453385113-23034-1-git-send-email-pure.logic@nexus-software.ie> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5-1ubuntu3.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-01-21 at 20:44 +0200, Andy Shevchenko wrote: > On Thu, Jan 21, 2016 at 4:05 PM, Bryan O'Donoghue > wrote: > > Currently when setting up an IMR around the kernel .text area we > > lock that > > IMR, preventing further modification. While superficially this > > appears to > > be the right thing to do, in fact this doesn't account for a > > legitimate > > change in the memory map such as when running through kexec. In > > such a > > scenario a second kernel can have a different size and location to > > it's > > predecessor and can view some of the memory occupied by its > > predecessor as > > legitimately usable RAM. This RAM can then be allocated to DMA > > agents > > within the system and trigger an IMR violation. > > > > The solution to this situation is to keep the kernel .text section > > IMR lock > > bit false. This means that a subsequent kernel will boot and can > > tear-down > > an existing IMR, while still setting up an IMR around its own .text > > section. > > > > Like I said you privately it would be nice to have a knob how to > behave. Ok - that can work. The default ought to be !locked and we can parametrize a different behaviour. > My idea is to provide kernel command line imr= and supply imr=lock > when user wants to boot kernel locked. Agreed. > > Optionally: add a warning if imr=lock and kernel build with kexec > that > might bring issues This makes sense. > Optionally: add a kernel config option to boot always in locked mode > (should depend on !KEXEC) Meh. You can still force the state you want with the parameter though. I reckon we should skip this change for now. --- bod