On Mon 2015-01-26 14:15:27, Bryan O'Donoghue wrote:
> Intel's Quark X1000 SoC contains a set of registers called Isolated Memory
> Regions. IMRs are accessed over the IOSF mailbox interface. IMRs are areas
> carved out of memory that define read/write access rights to the various
> system agents within the Quark system. For a given agent in the system it is
> possible to specify if that agent may read or write an area of memory
> defined by an IMR with a granularity of 1 KiB.
>
> Quark_SecureBootPRM_330234_001.pdf section 4.5 details the concept of IMRs
> quark-x1000-datasheet.pdf section 12.7.4 details the implementation of IMRs
> in silicon.
>
> eSRAM flush, CPU Snoop write-only, CPU SMM Mode, CPU non-SMM mode, RMU and
> PCIe Virtual Channels (VC0 and VC1) can have individual read/write access
> masks applied to them for a given memory region in Quark X1000. This
> enables IMRs to treat each memory transaction type listed above on an
> individual basis and to filter appropriately based on the IMR access mask
> for the memory region. Quark supports eight IMRs.
>
> Since all of the DMA capable SoC components in the X1000 are mapped to VC0
> it is possible to define sections of memory as invalid for DMA write
> operations originating from Ethernet, USB, SD and any other DMA capable
> south-cluster component on VC0. Similarly it is possible to mark kernel
> memory as non-SMM mode read/write only or to mark BIOS runtime memory as SMM
> mode accessible only depending on the particular memory footprint on a given
> system.
>
> On an IMR violation Quark SoC X1000 systems are configured to reset the
> system, so ensuring that the IMR memory map is consistent with the EFI
> provided memory map is critical to ensure no IMR violations reset the
> system.
>
> The API for accessing IMRs is based on MTRR code but doesn't provide a /proc
> or /sys interface to manipulate IMRs. Defining the size and extent of IMRs
> is exclusively the domain of in-kernel code.
Do the applications normally need to manipulate IMRs? Would it be
possible to do all IMR manipulations in the bootloader?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 23/02/15 22:18, Pavel Machek wrote:
> On Mon 2015-01-26 14:15:27, Bryan O'Donoghue wrote:
>
> Do the applications normally need to manipulate IMRs?
Applications could in theory manipulate IMRs - you might want to place
an IMR around an EFI capsule in memory for example - before calling a
capsule update.
This code will place an IMR around the kernel .text - .rodata which
ensures that no unwarranted DMA access can rewrite write-only kernel
addresses - something the MMU would not fault on - on non-IMR enabled
processors.
> Would it be
> possible to do all IMR manipulations in the bootloader?
>
Possible yes - in practical terms for Galileo or the SMARC+Quark from
Kontron for example - you'd be forcing a bootloader change - which most
users will not pick up.
Considering IMRs can reset the system if they aren't sanitized, it's
good practice for the kernel to go and make sure that every unlocked IMR
is torn-down and reset.