On 8/26/19 9:57 AM, Igor Mammedov wrote:
I most likely don't understand how this is supposed to work but aren'tWe are aren't reading SMRAM at 0x30000 base directly,
we here successfully reading SMRAM from non-SMM context, something we
are not supposed to be able to do?
"RAM" marked log lines are non-SMM context reads using as base
and as you see, it isn't showing anything from SMRAM
For mgmt/demo purposes SMRAM (which is at 0x30000 in SMM address space)
is also aliased at
into non-SMM address space to allow us to initialize SMM entry point
(log entries are marked as "SMRAM").
OK, I then misunderstood the purpose of this demo. I thought you were
not supposed to be able to read it from either location in non-SMM mode.
Thanks for the explanation.
Aliased SMRAM also allows us to check that relocation worked
(i.e. smm_base was relocated from default "handle_smi cmd=0 smbase=0x00030000"
to a new one "smm_relocate: SMRAM cpu.i64.smm_base a0000").
It's similar to what we do with TSEG where QEMU steals RAM from
normal address space and puts MMIO region 'tseg_blackhole' over it
so non-SMM context reads 0xFF from TSEG window, while SMM context
accesses RAM hidden below tseg_blackhole.
These patches show that we can have normal usable RAM at 0x30000
which doesn't overlap with SMRAM at the same address and each can
be made accessible only from its own mode (no-SMM and SMM).
Preventing non-SMM mode from injecting attack on SMRAM via CPU
that hasn't been initialized yet once firmware locked down SMRAM.