[coreboot] more smm questions

[Stefan Reinauer]

On 03-Jul-17 10:01, ron minnich wrote:
> 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?

Not sure what the issue you are seeing is, but you can assume that Qemu 
is getting that part of the hardware emulation wrong.

What chipset emulations are you trying? Q35? Or Ich9? Do they behave the 
same? The ICH9 (southbridge) should have very little to do with this 
particular piece of the code, because it's the southbridge, but the code 
is dependent on the CPU you emulate.

Last time I checked, Qemu could not emulate SMM properly.


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

This is the code that is used to move the initial SMM offset from 
0x38000 to some other place. The safe state is always located at a fixed 
offset from SMM_BASE.

>
> 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?

There is no giant contiguous memory involved. It's only a few hundred 
bytes for the state. The way we layed it out is to save maximum space 
when you have a lot of CPU cores. Read the documentation graphics in one 
of those files. The code (besides the trampoline) is also shared between 
all cores.


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

Traditionally you want to protect the SMM handler from being overwritten 
by the OS. That protection requires a defined (thus contiguous) piece of 
memory.

>
> 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 :-)

There really are no fixed address issues, except for the initial setup 
(and those will be hard to fix unless you change the silicon)

Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170703/3e5c0838/attachment.html>