linux-kernel - Re: [PATCH v2] x86/mm: warn on W+x mappings

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]

Date:	Mon, 12 Oct 2015 15:49:28 +0100
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Borislav Petkov <bp@...en8.de>,
	Stephen Smalley <sds@...ho.nsa.gov>, x86@...nel.org,
	linux-kernel@...r.kernel.org, keescook@...omium.org,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andy Lutomirski <luto@...nel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Brian Gerst <brgerst@...il.com>, linux-efi@...r.kernel.org,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Subject: Re: [PATCH v2] x86/mm: warn on W+x mappings

On Mon, 12 Oct, at 04:17:54PM, Ingo Molnar wrote:
> 
> * Matt Fleming <matt@...eblueprint.co.uk> wrote:
> 
> > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote:
> > > 
> > > 
> > > So why not unmap them after bootup? Is there any reason to call into EFI code 
> > > while the system is up and running?
> > 
> > That's where the runtime services code lives. So if you want things like EFI 
> > variables (used by the distro installer, among other things) you need to map the 
> > runtime regions.
> 
> So EFI variables could be queried during bootup and saved on the Linux side.

Right, we could do that, but then we wouldn't be able to support
creation/updating variables at runtime, such as when you install a
distribution for the first time, or want to boot a new kernel filename
directly from the firmware without a boot loader (and need to modify
the BootXXXX variables).

And it's not just EFI variables that need runtime support either, for
some platforms the only way to reboot/poweroff is with EFI, such as on
the ASUS T100TA (Intel Baytrail-T).

That's not to say your suggestion doesn't make sense for some cases, I
can definitely see how turning off runtime support but providing a
cache of EFI variables would be useful for some scenarios. But I don't
think it's ever going to be workable as a default option.

> Calling into firmware after the kernel has booted up is fragile in general - 
> beyond W+X the security considerations.

It isn't intended to be fragile, and effort has gone into defining the
context under which the EFI runtime services can operate (though there
are obviously gaps in that specification).

The entire point of the EFI runtime services is that they can be
invoked from the OS, and because hardware/firmware developers rely on
that when designing platforms, it's going to be something that Linux
is going to have to be able to do. Of course, that doesn't we
shouldn't be able to turn it off if the user is happy to sacrifice
some platform functionality.

Additionally, if we've got suggestions for the firmware developers on
what we want the runtime context to look like, let's propose it to
them. They're pretty receptive in my experience.

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/