Re: [POC Seabios PATCH] seabios: use isolated SMM address space for relocation

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 8/26/19 9:57 AM, Igor Mammedov wrote:
>
>> I most likely don't understand how this is supposed to work but aren't
>> we here successfully reading SMRAM from non-SMM context, something we
>> are not supposed to be able to do?
> We are aren't reading SMRAM at 0x30000 base directly,
> "RAM" marked log lines are non-SMM context reads using as base
>   BUILD_SMM_INIT_ADDR       0x30000
> 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
>   BUILD_SMM_ADDR            0xa0000
> 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.

-boris

>
> 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.
>
>
>>
>> -boris
>>