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 < [email protected]> 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 <[email protected]> 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: [email protected] >> https://mail.coreboot.org/mailman/listinfo/coreboot >> >
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
