diff mbox series

[v9,04/19] x86: Secure Launch Resource Table header file

Message ID 20240531010331.134441-5-ross.philipson@oracle.com (mailing list archive)
State New
Headers show
Series x86: Trenchboot secure dynamic launch Linux kernel support | expand

Commit Message

Ross Philipson May 31, 2024, 1:03 a.m. UTC
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@oracle.com>
---
 include/linux/slr_table.h | 271 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 271 insertions(+)
 create mode 100644 include/linux/slr_table.h

Comments

Jarkko Sakkinen June 4, 2024, 6:21 p.m. UTC | #1
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@oracle.com>

If a uarch specific, I'd appreciate Intel SDM reference here so that I
can look it up and compare. Like in section granularity.

BR, Jarkko
Ross Philipson June 4, 2024, 8:31 p.m. UTC | #2
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@oracle.com>
> 
> 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...

Thanks
Ross

> 
> BR, Jarkko
Jarkko Sakkinen June 4, 2024, 10:36 p.m. UTC | #3
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@oracle.com>
> > 
> > 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.

BR, Jarkko
Ross Philipson June 4, 2024, 11 p.m. UTC | #4
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@oracle.com>
>>>
>>> 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.

Ross

> 
> BR, Jarkko
Jarkko Sakkinen June 5, 2024, 12:22 a.m. UTC | #5
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@oracle.com>
> >>>
> >>> 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.

Especially this puzzles me, given that x86s won't have protected
mode in the first place...

BR, Jarkko
Jarkko Sakkinen June 5, 2024, 12:27 a.m. UTC | #6
On Wed Jun 5, 2024 at 3:22 AM EEST, 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@oracle.com>
> > >>>
> > >>> 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.
>
> Especially this puzzles me, given that x86s won't have protected
> mode in the first place...

That raises a relevant question: will this ever work in x86s? SDM does
not really support that it would but it could be also just outdated
information.

I'm neither sure how or will AMD align with x86s.

Just point out a glitch...

BR, Jarkko
Ross Philipson June 5, 2024, 2:33 a.m. UTC | #7
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@oracle.com>
>>>>>
>>>>> 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.

Thanks
Ross

> 
> BR, Jarkko
>
Jarkko Sakkinen June 5, 2024, 4:04 a.m. UTC | #8
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@oracle.com>
> >>>>>
> >>>>> 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.

The idea itself is great!

BR, Jarkko
Ross Philipson June 5, 2024, 7:03 p.m. UTC | #9
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@oracle.com>
>>>>>>>
>>>>>>> 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
>
Jarkko Sakkinen June 6, 2024, 6:02 a.m. UTC | #10
On Wed Jun 5, 2024 at 10:03 PM EEST,  wrote:
> 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

Happend to bump into same PDF specification and exactly the seeked
information is "3.15 SMX Changes". So just write this down to some
patch that starts adding SMX things.

Link: https://cdrdv2.intel.com/v1/dl/getContent/776648

So link and document, and other stuff above is not relevant from
upstream context, only potential maintenance burden :-)

For any architectures dig a similar fact:

1. Is not dead.
2. Will be there also in future.

Make any architecture existentially relevant for and not too much
coloring in the text that is easy to check.

It is nearing 5k lines so you should be really good with measured
facts too (not just launch) :-)

BR, Jarkko
Ross Philipson June 6, 2024, 4:49 p.m. UTC | #11
On 6/5/24 11:02 PM, Jarkko Sakkinen wrote:
> On Wed Jun 5, 2024 at 10:03 PM EEST,  wrote:
>> 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://urldefense.com/v3/__https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html__;!!ACWV5N9M2RV99hQ!Lt-srkRLHstA9PPCB-NWogvHP-9mfh2bHjkml-lARY79BhYlWJjhrHb6RyCN_WdGstcABq1FdqPUKn5dCdw$
> 
> Happend to bump into same PDF specification and exactly the seeked
> information is "3.15 SMX Changes". So just write this down to some
> patch that starts adding SMX things.
> 
> Link: https://urldefense.com/v3/__https://cdrdv2.intel.com/v1/dl/getContent/776648__;!!ACWV5N9M2RV99hQ!Lt-srkRLHstA9PPCB-NWogvHP-9mfh2bHjkml-lARY79BhYlWJjhrHb6RyCN_WdGstcABq1FdqPUuZy8Sfk$
> 
> So link and document, and other stuff above is not relevant from
> upstream context, only potential maintenance burden :-)

I am not 100% sure what you mean exactly here...

> 
> For any architectures dig a similar fact:
> 
> 1. Is not dead.
> 2. Will be there also in future.
> 
> Make any architecture existentially relevant for and not too much
> coloring in the text that is easy to check.
> 
> It is nearing 5k lines so you should be really good with measured
> facts too (not just launch) :-)

... but overall I get your meaning. We will spend time on this sort of 
documentation for the v10 release.

Thanks for the feedback,
Ross

> 
> BR, Jarkko
>
Jarkko Sakkinen June 20, 2024, 12:18 a.m. UTC | #12
On Thu Jun 6, 2024 at 7:49 PM EEST,  wrote:
> > For any architectures dig a similar fact:
> > 
> > 1. Is not dead.
> > 2. Will be there also in future.
> > 
> > Make any architecture existentially relevant for and not too much
> > coloring in the text that is easy to check.
> > 
> > It is nearing 5k lines so you should be really good with measured
> > facts too (not just launch) :-)
>
> ... but overall I get your meaning. We will spend time on this sort of 
> documentation for the v10 release.

Yeah, I mean we live in the universe of 3 letter acronyms so
it is better to summarize the existential part, especially
in a ~5 KSLOC patch set ;-)

BR, Jarkko
Ross Philipson June 20, 2024, 4:55 p.m. UTC | #13
On 6/19/24 5:18 PM, Jarkko Sakkinen wrote:
> On Thu Jun 6, 2024 at 7:49 PM EEST,  wrote:
>>> For any architectures dig a similar fact:
>>>
>>> 1. Is not dead.
>>> 2. Will be there also in future.
>>>
>>> Make any architecture existentially relevant for and not too much
>>> coloring in the text that is easy to check.
>>>
>>> It is nearing 5k lines so you should be really good with measured
>>> facts too (not just launch) :-)
>>
>> ... but overall I get your meaning. We will spend time on this sort of
>> documentation for the v10 release.
> 
> Yeah, I mean we live in the universe of 3 letter acronyms so
> it is better to summarize the existential part, especially
> in a ~5 KSLOC patch set ;-)

Indeed, thanks.

Ross

> 
> BR, Jarkko
>
diff mbox series

Patch

diff --git a/include/linux/slr_table.h b/include/linux/slr_table.h
new file mode 100644
index 000000000000..213d8ac16f0f
--- /dev/null
+++ b/include/linux/slr_table.h
@@ -0,0 +1,271 @@ 
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Secure Launch Resource Table
+ *
+ * Copyright (c) 2024, Oracle and/or its affiliates.
+ */
+
+#ifndef _LINUX_SLR_TABLE_H
+#define _LINUX_SLR_TABLE_H
+
+/* Put this in efi.h if it becomes a standard */
+#define SLR_TABLE_GUID				EFI_GUID(0x877a9b2a, 0x0385, 0x45d1, 0xa0, 0x34, 0x9d, 0xac, 0x9c, 0x9e, 0x56, 0x5f)
+
+/* SLR table header values */
+#define SLR_TABLE_MAGIC		0x4452544d
+#define SLR_TABLE_REVISION	1
+
+/* Current revisions for the policy and UEFI config */
+#define SLR_POLICY_REVISION		1
+#define SLR_UEFI_CONFIG_REVISION	1
+
+/* SLR defined architectures */
+#define SLR_INTEL_TXT		1
+#define SLR_AMD_SKINIT		2
+
+/* SLR defined bootloaders */
+#define SLR_BOOTLOADER_INVALID	0
+#define SLR_BOOTLOADER_GRUB	1
+
+/* Log formats */
+#define SLR_DRTM_TPM12_LOG	1
+#define SLR_DRTM_TPM20_LOG	2
+
+/* DRTM Policy Entry Flags */
+#define SLR_POLICY_FLAG_MEASURED	0x1
+#define SLR_POLICY_IMPLICIT_SIZE	0x2
+
+/* Array Lengths */
+#define TPM_EVENT_INFO_LENGTH		32
+#define TXT_VARIABLE_MTRRS_LENGTH	32
+
+/* Tags */
+#define SLR_ENTRY_INVALID	0x0000
+#define SLR_ENTRY_DL_INFO	0x0001
+#define SLR_ENTRY_LOG_INFO	0x0002
+#define SLR_ENTRY_ENTRY_POLICY	0x0003
+#define SLR_ENTRY_INTEL_INFO	0x0004
+#define SLR_ENTRY_AMD_INFO	0x0005
+#define SLR_ENTRY_ARM_INFO	0x0006
+#define SLR_ENTRY_UEFI_INFO	0x0007
+#define SLR_ENTRY_UEFI_CONFIG	0x0008
+#define SLR_ENTRY_END		0xffff
+
+/* Entity Types */
+#define SLR_ET_UNSPECIFIED	0x0000
+#define SLR_ET_SLRT		0x0001
+#define SLR_ET_BOOT_PARAMS	0x0002
+#define SLR_ET_SETUP_DATA	0x0003
+#define SLR_ET_CMDLINE		0x0004
+#define SLR_ET_UEFI_MEMMAP	0x0005
+#define SLR_ET_RAMDISK		0x0006
+#define SLR_ET_TXT_OS2MLE	0x0010
+#define SLR_ET_UNUSED		0xffff
+
+#ifndef __ASSEMBLY__
+
+/*
+ * Primary Secure Launch Resource Table Header
+ */
+struct slr_table {
+	u32 magic;
+	u16 revision;
+	u16 architecture;
+	u32 size;
+	u32 max_size;
+	/* table entries */
+} __packed;
+
+/*
+ * Common SLRT Table Header
+ */
+struct slr_entry_hdr {
+	u16 tag;
+	u16 size;
+} __packed;
+
+/*
+ * Boot loader context
+ */
+struct slr_bl_context {
+	u16 bootloader;
+	u16 reserved[3];
+	u64 context;
+} __packed;
+
+/*
+ * Dynamic Launch Callback Function type
+ */
+typedef void (*dl_handler_func)(struct slr_bl_context *bl_context);
+
+/*
+ * DRTM Dynamic Launch Configuration
+ */
+struct slr_entry_dl_info {
+	struct slr_entry_hdr hdr;
+	u32 dce_size;
+	u64 dce_base;
+	u64 dlme_size;
+	u64 dlme_base;
+	u64 dlme_entry;
+	struct slr_bl_context bl_context;
+	u64 dl_handler;
+} __packed;
+
+/*
+ * TPM Log Information
+ */
+struct slr_entry_log_info {
+	struct slr_entry_hdr hdr;
+	u16 format;
+	u16 reserved[3];
+	u32 size;
+	u64 addr;
+} __packed;
+
+/*
+ * DRTM Measurement Entry
+ */
+struct slr_policy_entry {
+	u16 pcr;
+	u16 entity_type;
+	u16 flags;
+	u16 reserved;
+	u64 size;
+	u64 entity;
+	char evt_info[TPM_EVENT_INFO_LENGTH];
+} __packed;
+
+/*
+ * DRTM Measurement Policy
+ */
+struct slr_entry_policy {
+	struct slr_entry_hdr hdr;
+	u16 revision;
+	u16 nr_entries;
+	struct slr_policy_entry policy_entries[];
+} __packed;
+
+/*
+ * Secure Launch defined MTRR saving structures
+ */
+struct slr_txt_mtrr_pair {
+	u64 mtrr_physbase;
+	u64 mtrr_physmask;
+} __packed;
+
+struct slr_txt_mtrr_state {
+	u64 default_mem_type;
+	u64 mtrr_vcnt;
+	struct slr_txt_mtrr_pair mtrr_pair[TXT_VARIABLE_MTRRS_LENGTH];
+} __packed;
+
+/*
+ * Intel TXT Info table
+ */
+struct slr_entry_intel_info {
+	struct slr_entry_hdr hdr;
+	u16 reserved[2];
+	u64 txt_heap;
+	u64 saved_misc_enable_msr;
+	struct slr_txt_mtrr_state saved_bsp_mtrrs;
+} __packed;
+
+/*
+ * UEFI config measurement entry
+ */
+struct slr_uefi_cfg_entry {
+	u16 pcr;
+	u16 reserved;
+	u32 size;
+	u64 cfg; /* address or value */
+	char evt_info[TPM_EVENT_INFO_LENGTH];
+} __packed;
+
+/*
+ * UEFI config measurements
+ */
+struct slr_entry_uefi_config {
+	struct slr_entry_hdr hdr;
+	u16 revision;
+	u16 nr_entries;
+	struct slr_uefi_cfg_entry uefi_cfg_entries[];
+} __packed;
+
+static inline void *slr_end_of_entries(struct slr_table *table)
+{
+	return (void *)table + table->size;
+}
+
+static inline void *
+slr_next_entry(struct slr_table *table,
+	       struct slr_entry_hdr *curr)
+{
+	struct slr_entry_hdr *next = (struct slr_entry_hdr *)
+				((u8 *)curr + curr->size);
+
+	if ((void *)next >= slr_end_of_entries(table))
+		return NULL;
+	if (next->tag == SLR_ENTRY_END)
+		return NULL;
+
+	return next;
+}
+
+static inline void *
+slr_next_entry_by_tag(struct slr_table *table,
+		      struct slr_entry_hdr *entry,
+		      u16 tag)
+{
+	if (!entry) /* Start from the beginning */
+		entry = (struct slr_entry_hdr *)(((u8 *)table) + sizeof(*table));
+
+	for ( ; ; ) {
+		if (entry->tag == tag)
+			return entry;
+
+		entry = slr_next_entry(table, entry);
+		if (!entry)
+			return NULL;
+	}
+
+	return NULL;
+}
+
+static inline int
+slr_add_entry(struct slr_table *table,
+	      struct slr_entry_hdr *entry)
+{
+	struct slr_entry_hdr *end;
+
+	if ((table->size + entry->size) > table->max_size)
+		return -1;
+
+	memcpy((u8 *)table + table->size - sizeof(*end), entry, entry->size);
+	table->size += entry->size;
+
+	end  = (struct slr_entry_hdr *)((u8 *)table + table->size - sizeof(*end));
+	end->tag = SLR_ENTRY_END;
+	end->size = sizeof(*end);
+
+	return 0;
+}
+
+static inline void
+slr_init_table(struct slr_table *slrt, u16 architecture, u32 max_size)
+{
+	struct slr_entry_hdr *end;
+
+	slrt->magic = SLR_TABLE_MAGIC;
+	slrt->revision = SLR_TABLE_REVISION;
+	slrt->architecture = architecture;
+	slrt->size = sizeof(*slrt) + sizeof(*end);
+	slrt->max_size = max_size;
+	end = (struct slr_entry_hdr *)((u8 *)slrt + sizeof(*slrt));
+	end->tag = SLR_ENTRY_END;
+	end->size = sizeof(*end);
+}
+
+#endif /* !__ASSEMBLY */
+
+#endif /* _LINUX_SLR_TABLE_H */