linux-kernel - Re: [PATCH 0/2] x86: Add IMR support to Quark/Galileo

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: <54ABE989.8060701@nexus-software.ie>
Date:	Tue, 06 Jan 2015 13:56:25 +0000
From:	Bryan O'Donoghue <pure.logic@...us-software.ie>
To:	Darren Hart <dvhart@...radead.org>
CC:	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	x86@...nel.org, platform-driver-x86@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] x86: Add IMR support to Quark/Galileo

On 06/01/15 06:00, Darren Hart wrote:
>> Galileo:
>> Intel's Arduino compatible Galileo boards boot to Linux with IMRs protecting
>> the compressed kernel image and boot params data structure. The memory that
>
> What is the motivation behind this?

The main motivation is to place an IMR around the kernel which if 
violated by a wayward DMA transaction would immediately cause an IMR 
violation. Secondary motivation is demonstration of usage of IMRs in a 
run-time context and validation of the IMR enabling code for setup not 
just tear-down.

An IMR around the run-time kernel .text area, is what the BSP does and 
so I thought it was worth maintaining.

To be clear though, the requirement is to sanitize boot time IMRs, the 
setup of an IMR around the run-time kernel is optional, the system will 
run just fine without it.

>> the compressed kernel and boot params data structure is in, is marked as
>> usable memory by the EFI memory map. As a result it is possible for memory
>
> Based on your response to the above, is marking this memory as usable a bad idea
> in general? Or just bad in certain situations?

The EFI memory map is 100% correct. The area of memory that grub places 
a compressed kernel image should be reusable by kernel.

>> A DMA to a region of memory by a system agent which is not allowed access
>> this memory result in a system reset. Without tearing down the IMRs placed
>> around the compressed kernel image and boot params data structure there is a
>> high risk of triggering an inadvertent system reset when performing DMA
>> actions with any of the peripherals that support DMA in Quark such as the
>> MMC, Ethernet or USB host/device.
>>
>> Therefore Galileo specific platform code is the second component of this
>> patchset. The platform code tears-down every unlocked IMR to ensure no
>
> The firmware sets these IMRs, but does not lock them then, correct?

Correct. Firmware locks the IMRs around ACPI runtime data data.

In the patch here, we cycle though every unlocked IMR and zap it - which 
will include tear-down of the IMRs placed around the compressed kernel 
image and boot params data structure. Firmware puts those IMRs in place 
to ensure no invalid DMA, SMM access to the compressed kernel image 
during boot can take place.

--
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/