lkml.org 
[lkml]   [2015]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.




\
 
 \ /
  Last update: 2015-01-06 15:01    [W:0.210 / U:22.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site