On 6/4/24 9:04 PM, Jarkko Sakkinen wrote:
On Wed Jun 5, 2024 at 5:33 AM EEST, wrote:
On 6/4/24 5:22 PM, Jarkko Sakkinen wrote:
On Wed Jun 5, 2024 at 2:00 AM EEST, wrote:
On 6/4/24 3:36 PM, Jarkko Sakkinen wrote:
On Tue Jun 4, 2024 at 11:31 PM EEST, wrote:
On 6/4/24 11:21 AM, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
Introduce the Secure Launch Resource Table which forms the formal
interface between the pre and post launch code.
Signed-off-by: Ross Philipson <ross.philipson@xxxxxxxxxx>
If a uarch specific, I'd appreciate Intel SDM reference here so that I
can look it up and compare. Like in section granularity.
This table is meant to not be architecture specific though it can
contain architecture specific sub-entities. E.g. there is a TXT specific
table and in the future there will be an AMD and ARM one (and hopefully
some others). I hope that addresses what you are pointing out or maybe I
don't fully understand what you mean here...
At least Intel SDM has a definition of any possible architecture
specific data structure. It is handy to also have this available
in inline comment for any possible such structure pointing out the
section where it is defined.
The TXT specific structure is not defined in the SDM or the TXT dev
guide. Part of it is driven by requirements in the TXT dev guide but
that guide does not contain implementation details.
That said, if you would like links to relevant documents in the comments
before arch specific structures, I can add them.
Vol. 2D 7-40, in the description of GETSEC[WAKEUP] there is in fact a
description of MLE JOINT structure at least:
1. GDT limit (offset 0)
2. GDT base (offset 4)
3. Segment selector initializer (offset 8)
4. EIP (offset 12)
So is this only exercised in protect mode, and not in long mode? Just
wondering whether I should make a bug report on this for SDM or not.
I believe you can issue the SENTER instruction in long mode, compat mode
or protected mode. On the other side thought, you will pop out of the
TXT initialization in protected mode. The SDM outlines what registers
will hold what values and what is valid and not valid. The APs will also
vector through the join structure mentioned above to the location
specified in protected mode using the GDT information you provide.
Especially this puzzles me, given that x86s won't have protected
mode in the first place...
My guess is the simplified x86 architecture will not support TXT. It is
not supported on a number of CPUs/chipsets as it stands today. Just a
guess but we know only vPro systems support TXT today.
I'm wondering could this bootstrap itself inside TDX or SNP, and that
way provide path forward? AFAIK, TDX can be nested straight of the bat
and SNP from 2nd generation EPYC's, which contain the feature.
I do buy the idea of attesting the host, not just the guests, even in
the "confidential world". That said, I'm not sure does it make sense
to add all this infrastructure for a technology with such a short
expiration date?
I would not want to say this at v9, and it is not really your fault
either, but for me this would make a lot more sense if the core of
Trenchboot was redesigned around these newer technologies with a
long-term future.
So I did not mean to imply that DRTM support on various
platforms/architectures has a short expiration date. In fact we are
actively working on DRTM support through the TrenchBoot project on
several platforms/architectures. Just a quick rundown here:
Intel: Plenty of Intel platforms are vPro with TXT. It is really just
the lower end systems that don't have it available (like Core i3). And
my guess was wrong about x86s. You can find the spec on the page in the
following link. There is an entire subsection on SMX support on x86s and
the changes to the various GETSEC instruction leaves that were made to
make it work there (see 3.15).
https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
AMD: We are actively working on SKINIT DRTM support that will go into
TrenchBoot. There are changes coming soon to AMD SKINIT to make it more
robust and address some earlier issues. We hope to be able to start
sending AMD DRTM support up in the posts to LKML in the not too distant
future.
Arm: They have recently released their DRTM specification and at least
one Arm vendor is close to releasing firmware that will support DRTM.
Again we are actively working in this area on the TrenchBoot project.
https://developer.arm.com/documentation/den0113/latest/
One final thought I had. The technologies you mentioned above seem to be
to be complementary to DRTM as opposed to being a replacement for it, at
least to me but I am not an expert on them.
Perhaps Daniel Smith would like to expand on what I have said here.
Thanks
Ross
The idea itself is great!
BR, Jarkko
