Re: [PATCH] x86/intel/quark: Remove lock bit around kernel IMR

["Bryan O'Donoghue" <pure.logic@nexus-software.ie>]

On Thu, 2016-01-21 at 20:44 +0200, Andy Shevchenko wrote:
> On Thu, Jan 21, 2016 at 4:05 PM, Bryan O'Donoghue
> <pure.logic@nexus-software.ie> 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