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 >> -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#46436): https://edk2.groups.io/g/devel/message/46436 Mute This Topic: https://groups.io/mt/32899784/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
