<div dir="ltr">well more later but I now seem to be fighting a bug in qemu. man I hate it when that happens.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 3, 2017 at 2:10 PM Zoran Stojsavljevic <<a href="mailto:zoran.stojsavljevic@gmail.com">zoran.stojsavljevic@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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).<div><br></div><div>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... ;-)</div><div>[1] SMM (as my best understanding is) always runs in real (16 bit) mode;</div><div>[2] For HSEG to be visible (ONLY to SMM mode), the <em style="box-sizing:border-box;margin:0px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;line-height:inherit;font-family:Montserrat,sans-serif;font-size:14px;vertical-align:baseline;color:rgb(71,71,71)">system management RAM control register</em><span style="color:rgb(71,71,71);font-family:Montserrat,sans-serif;font-size:14px"> must be programmed in BIOS (register belongs to PCH); as such the memory around </span><span style="color:rgb(71,71,71);font-family:"Courier New";font-size:12px">FEEA_0000h-FEEB_FFFFh</span> will be hardcoded to;</div><div>[3] For TSEG, the same <em style="box-sizing:border-box;margin:0px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;line-height:inherit;font-family:Montserrat,sans-serif;font-size:14px;vertical-align:baseline;color:rgb(71,71,71)">system management RAM control register </em>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);</div><div>[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...</div><div> [A] HSEG will be remapped to A0000 - BFFFF by HW;</div><div> [B] Parts of TSEG will be remapped beneath A0000 by HW (where real mode memory resides);</div><div><br></div><div>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!?</div><div><br></div><div>More or less, this is the theory. This is how I understood it, people.</div><div><br></div><div>Floor all yours. Please, continue discussion.</div></div><div dir="ltr"><div><br></div><div>Zoran</div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 3, 2017 at 7:01 PM, ron minnich <span dir="ltr"><<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've got a question right at this code:<div><a href="https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b94acb67e97/src/cpu/x86/smm/smmrelocate.S#L101" target="_blank">https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b94acb67e97/src/cpu/x86/smm/smmrelocate.S#L101</a><br></div><div><br></div><div><div><span style="white-space:pre-wrap"> </span>/* Check revision to see if AMD64 style SMM_BASE</div><div><span style="white-space:pre-wrap"> </span> * Intel Core Solo/Duo: 0x30007</div><div><span style="white-space:pre-wrap"> </span> * Intel Core2 Solo/Duo: 0x30100</div><div><span style="white-space:pre-wrap"> </span> * Intel SandyBridge: 0x30101</div><div><span style="white-space:pre-wrap"> </span> * AMD64: 0x3XX64</div><div><span style="white-space:pre-wrap"> </span> * This check does not make much sense, unless someone ports</div><div><span style="white-space:pre-wrap"> </span> * SMI handling to AMD64 CPUs.</div><div><span style="white-space:pre-wrap"> </span> */</div><div><br></div><div><span style="white-space:pre-wrap"> </span>mov $0x38000 + 0x7efc, %ebx</div><div><span style="white-space:pre-wrap"> </span>addr32 mov (%ebx), %al</div><div><span style="white-space:pre-wrap"> </span>cmp $0x64, %al</div><div><span style="white-space:pre-wrap"> </span>je 1f</div><div><br></div><div><span style="white-space:pre-wrap"> </span>mov $0x38000 + 0x7ef8, %ebx</div><div><span style="white-space:pre-wrap"> </span>jmp smm_relocate</div><div>1:</div><div><span style="white-space:pre-wrap"> </span>mov $0x38000 + 0x7f00, %ebx</div></div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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 :-)</div><span class="m_-9086183879438019263HOEnZb"><font color="#888888"><div><br></div><div>ron</div><div><br></div><div><br></div></font></span></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mailman/listinfo/coreboot</a><br></blockquote></div></div></blockquote></div>