[coreboot] more smm questions

[ron minnich]

well more later but I now seem to be fighting a bug in qemu. man I hate it
when that happens.

On Mon, Jul 3, 2017 at 2:10 PM Zoran Stojsavljevic <
zoran.stojsavljevic at gmail.com> wrote:

> Let me also enter this discussion, to clear somehow my ignorance in this
> area, which is significant. Last few days I was refreshing my mind about
> what I know about SMM and SMI, and the following went out of this research
> (in lieu of the Original Post).
>
> So this is what I understood about SMM, in general, and HSEG, also TSEG.
> Let me put some assumption, after I read what I read... ;-)
> [1] SMM (as my best understanding is) always runs in real (16 bit) mode;
> [2] For HSEG to be visible (ONLY to SMM mode), the *system management RAM
> control register* must be programmed in BIOS (register belongs to PCH);
> as such the memory around FEEA_0000h-FEEB_FFFFh will be hardcoded to;
> [3] For TSEG, the same *system management RAM control register *is
> programmed, with some to 8MB of memory, beneath PCIe devices DRAM mapping,
> and this memory is NOT visible to OS (as well as HSEG);
> [4] Once SMI is entered, there are very complex mechanisms of HW shadowing
> executed in background, not visible to SW guys; in nutshell, the following
> will happen...
>     [A] HSEG will be remapped to A0000 - BFFFF by HW;
>     [B] Parts of TSEG will be remapped beneath A0000 by HW (where real
> mode memory resides);
>
> Now, the following is to happen: the SMI handler will save the current
> core context in SMRAM/TSEG, using SMBASE value. Then, all cores except one
> (have no idea how this core is delegated - probably BSP core) will enter
> sleep state. The lowest core 0 will have SMBASE: 3000(0)h + constant 8000,
> where the current core 0 context will be saved (actually by
> remapping/shadowing to TSEG), and core 1 will have probably the same SMBASE
> + constant, but with the index 1, so its context will be saved in other
> region of TSEG... etc! It is some HW magic not completely clear to me!?
>
> More or less, this is the theory. This is how I understood it, people.
>
> Floor all yours. Please, continue discussion.
>
> Zoran
> On Mon, Jul 3, 2017 at 7:01 PM, ron minnich <rminnich at gmail.com> 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?
>>
>> 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
>>
>>
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170703/08409089/attachment.html>