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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1453460916.15129.70.camel@nexus-software.ie>
Date:	Fri, 22 Jan 2016 11:08:36 +0000
From:	Bryan O'Donoghue <pure.logic@...us-software.ie>
To:	Andy Shevchenko <andy.shevchenko@...il.com>
Cc:	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	stable@...r.kernel.org
Subject: Re: [PATCH] x86/intel/quark: Remove lock bit around kernel IMR

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@...us-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