<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 03-Jul-17 10:01, ron minnich wrote:<br>
</div>
<blockquote
cite="mid:CAP6exY+xE7=rX1hE1_3dAHYsjmQaybXLCpDbn_mMR5w70wGjGA@mail.gmail.com"
type="cite">
<div dir="ltr">I've got a question right at this code:
<div><a moz-do-not-send="true"
href="https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b94acb67e97/src/cpu/x86/smm/smmrelocate.S#L101">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"> </span>/* Check revision
to see if AMD64 style SMM_BASE</div>
<div><span style="white-space:pre"> </span> * Intel Core
Solo/Duo: 0x30007</div>
<div><span style="white-space:pre"> </span> * Intel Core2
Solo/Duo: 0x30100</div>
<div><span style="white-space:pre"> </span> * Intel
SandyBridge: 0x30101</div>
<div><span style="white-space:pre"> </span> * AMD64:
0x3XX64</div>
<div><span style="white-space:pre"> </span> * This check does
not make much sense, unless someone ports</div>
<div><span style="white-space:pre"> </span> * SMI handling to
AMD64 CPUs.</div>
<div><span style="white-space:pre"> </span> */</div>
<div><br>
</div>
<div><span style="white-space:pre"> </span>mov $0x38000 +
0x7efc, %ebx</div>
<div><span style="white-space:pre"> </span>addr32 mov (%ebx),
%al</div>
<div><span style="white-space:pre"> </span>cmp $0x64, %al</div>
<div><span style="white-space:pre"> </span>je 1f</div>
<div><br>
</div>
<div><span style="white-space:pre"> </span>mov $0x38000 +
0x7ef8, %ebx</div>
<div><span style="white-space:pre"> </span>jmp smm_relocate</div>
<div>1:</div>
<div><span style="white-space:pre"> </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>
</blockquote>
<br>
Not sure what the issue you are seeing is, but you can assume that
Qemu is getting that part of the hardware emulation wrong.<br>
<br>
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.<br>
<br>
Last time I checked, Qemu could not emulate SMM properly.<br>
<br>
<br>
<blockquote
cite="mid:CAP6exY+xE7=rX1hE1_3dAHYsjmQaybXLCpDbn_mMR5w70wGjGA@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAP6exY+xE7=rX1hE1_3dAHYsjmQaybXLCpDbn_mMR5w70wGjGA@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAP6exY+xE7=rX1hE1_3dAHYsjmQaybXLCpDbn_mMR5w70wGjGA@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
<br>
Traditionally you want to protect the SMM handler from being
overwritten by the OS. That protection requires a defined (thus
contiguous) piece of memory.<br>
<br>
<blockquote
cite="mid:CAP6exY+xE7=rX1hE1_3dAHYsjmQaybXLCpDbn_mMR5w70wGjGA@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</div>
</blockquote>
<br>
There really are no fixed address issues, except for the initial
setup (and those will be hard to fix unless you change the silicon)<br>
<br>
Stefan<br>
</body>
</html>