[coreboot] more smm questions

ron minnich rminnich at gmail.com
Mon Jul 3 19:01:12 CEST 2017


I've got a question right at this code:
https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b94acb67e97/src/cpu/x86/smm/smmrelocate.S#L101

/* Check revision to see if AMD64 style SMM_BASE
*   Intel Core Solo/Duo:  0x30007
*   Intel Core2 Solo/Duo: 0x30100
*   Intel SandyBridge:    0x30101
*   AMD64:                0x3XX64
* This check does not make much sense, unless someone ports
* SMI handling to AMD64 CPUs.
*/

mov $0x38000 + 0x7efc, %ebx
addr32 mov (%ebx), %al
cmp $0x64, %al
je 1f

mov $0x38000 + 0x7ef8, %ebx
jmp smm_relocate
1:
mov $0x38000 + 0x7f00, %ebx

As I read it, it tests for %al being 0x64 and, if so, it assumes the offset
is at 7f00. As I read the intel x86 docs, this is wrong, or qemu is wrong.
As I read the docs and Xeno's writeups, the offset is at 0x7ef8 on 64-bit
processors. But the ich9 version at least in qemu is 0x20064, and that
would mean coreboot thinks the register is at 7f00, which it does not
appear to be.

So: am I missing something? does this work on amd64 today? where is the
offset on modern em64t CPUs? And why does it work on coreboot with q35,
qemu, and multiple cores if this offset is wrong?

Also, a different question. The offset at 7ef8 is a 32-bit number on 64-bit
systems. It seems to me this implies that the the save state can be located
anywhere in the low 4G memory on a per-core basis. I'm a bit lost on the
need for the large contiguous SMM save state area.

So, for example, it seems to me we could leave a very small SMM stub at
0xa0000, and as long as it had a simple way to set its offset at 7ef8 it
could put its save state at any convenient location. Why do we need the
giant contiguous memory area for save state if this is the case?

The main motivation for the TSEG seems to be the requirement of the large
contiguous save state area for SMM, but I don't see anything that says it
has to be physically contiguous, given the existence of the 32-bit offset.

Current status btw is that linux is able to set up the relocation area and
I'm able to run SMIs from the command line and the code Linux sets up gets
run.

It seems to me we ought to be able to break a lot of these fixed address
issues and as a result reduce attack surface, but we'll see. I'm got lots
of ignorance, little knowledge, and this can be good or bad :-)

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170703/07989efb/attachment.html>


More information about the coreboot mailing list