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
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 Sec
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, Ro
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
On 6/4/24 3:50 PM, Jarkko Sakkinen wrote:
On Wed Jun 5, 2024 at 1:14 AM EEST, wrote:
On 6/4/24 1:27 PM, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
Curently the locality is hard coded to 0 but for DRTM support, access
is needed to localities 1 through 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 laun
On Wed Jun 5, 2024 at 1:14 AM EEST, wrote:
> On 6/4/24 1:27 PM, Jarkko Sakkinen wrote:
> > On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> >> Curently the locality is hard coded to 0 but for DRTM support, access
> >> is needed to localities 1 through 4.
> >>
> >> Signed-off-by: Ross P
On Wed Jun 5, 2024 at 12:47 AM EEST, wrote:
> > static inline bool slaunch_is_txt_launch(void)
> > {
> > u32 mask = SL_FLAG_ACTIVE | SL_FLAG_ARCH_TXT;
> >
> > return slaunch_get_flags() & mask == mask;
> > }
>
> Actually I think I can take your suggested change and move this function
>
On Wed Jun 5, 2024 at 12:16 AM EEST, wrote:
> On 6/4/24 12:58 PM, Jarkko Sakkinen wrote:
> > On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> >> The routine slaunch_setup is called out of the x86 specific setup_arch()
> >> routine during early kernel boot. After determining what platfo
> > s/tpm20/tpm2/
>
> Reasonable. We can change it.
For the sake of consistency. Anywhere else where we have code using TPM,
either "tpm_" or "tpm2_" is used.
BR, Jarkko
On Wed Jun 5, 2024 at 12:02 AM EEST, wrote:
> On 6/4/24 11:52 AM, Jarkko Sakkinen wrote:
> > On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> >> From: "Daniel P. Smith"
> >>
> >> For better or worse, Secure Launch needs SHA-1 and SHA-256. The
> >> choice of hashes used lie with the pl
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-b
On 6/4/24 1:27 PM, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
Curently the locality is hard coded to 0 but for DRTM support, access
is needed to localities 1 through 4.
Signed-off-by: Ross Philipson
---
drivers/char/tpm/tpm-chip.c | 24
On 6/4/24 1:05 PM, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
On Intel, the APs are left in a well documented state after TXT performs
the late launch. Specifically they cannot have #INIT asserted on them so
a standard startup via INIT/SIPI/SIPI cannot be p
On 6/4/24 12:59 PM, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
The routine slaunch_setup is called out of the x86 specific setup_arch()
routine during early kernel boot. After determining what platform is
present, various operations specific to that platfor
On 6/4/24 12:58 PM, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
The routine slaunch_setup is called out of the x86 specific setup_arch()
routine during early kernel boot. After determining what platform is
present, various operations specific to that platfor
On 6/4/24 1:54 PM, Ard Biesheuvel wrote:
On Tue, 4 Jun 2024 at 19:34, wrote:
On 6/4/24 10:27 AM, Ard Biesheuvel wrote:
On Tue, 4 Jun 2024 at 19:24, wrote:
On 5/31/24 6:33 AM, Ard Biesheuvel wrote:
On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
Hello Ross,
On Fri, 31 May 2024 at 0
On 6/4/24 12:56 PM, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
The Secure Launch (SL) stub provides the entry point for Intel TXT (and
later AMD SKINIT) to vector to during the late launch. The symbol
sl_stub_entry is that entry point and its offset into th
On 6/4/24 11:52 AM, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
From: "Daniel P. Smith"
For better or worse, Secure Launch needs SHA-1 and SHA-256. The
choice of hashes used lie with the platform firmware, not with
software, and is often outside of the use
On Tue, 4 Jun 2024 at 19:34, wrote:
>
> On 6/4/24 10:27 AM, Ard Biesheuvel wrote:
> > On Tue, 4 Jun 2024 at 19:24, wrote:
> >>
> >> On 5/31/24 6:33 AM, Ard Biesheuvel wrote:
> >>> On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
>
> Hello Ross,
>
> On Fri, 31 May 2024 at 0
On 6/4/24 11:24 AM, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
Introduce the main Secure Launch header file used in the early SL stub
and the early setup code.
Signed-off-by: Ross Philipson
Right and anything AMD specific should also have legit referenc
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
If a uarch specific, I'd appreciate Intel SDM
On 6/4/24 11:18 AM, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
From: Arvind Sankar
There are use cases for storing the offset of a symbol in kernel_info.
For example, the trenchboot series [0] needs to store the offset of the
Measured Launch Environment h
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> Expose a sysfs interface to allow user mode to set and query the preferred
> locality for the TPM chip.
>
> Signed-off-by: Ross Philipson
> ---
> drivers/char/tpm/tpm-sysfs.c | 30 ++
> 1 file changed, 30 ins
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> Curently the locality is hard coded to 0 but for DRTM support, access
> is needed to localities 1 through 4.
>
> Signed-off-by: Ross Philipson
> ---
> drivers/char/tpm/tpm-chip.c | 24 +++-
> drivers/char/tpm/tp
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> When tis core initializes, it assumes all localities are closed. There
s/tis_core/tpm_tis_core/
> are cases when this may not be the case. This commit addresses this by
> ensuring all localities are closed b
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> Commit 933bfc5ad213 introduced the use of a locality counter to control when a
> locality request is allowed to be sent to the TPM. In the commit, the counter
> is indiscriminately decremented. Thus creating a
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> On Intel, the APs are left in a well documented state after TXT performs
> the late launch. Specifically they cannot have #INIT asserted on them so
> a standard startup via INIT/SIPI/SIPI cannot be performed. Instead the
> early SL stub c
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> The routine slaunch_setup is called out of the x86 specific setup_arch()
> routine during early kernel boot. After determining what platform is
> present, various operations specific to that platform occur. This
> includes finalizing sett
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> The routine slaunch_setup is called out of the x86 specific setup_arch()
> routine during early kernel boot. After determining what platform is
> present, various operations specific to that platform occur. This
> includes finalizing sett
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> The Secure Launch (SL) stub provides the entry point for Intel TXT (and
> later AMD SKINIT) to vector to during the late launch. The symbol
> sl_stub_entry is that entry point and its offset into the kernel is
> conveyed to the launching
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> For better or worse, Secure Launch needs SHA-1 and SHA-256. The
> choice of hashes used lie with the platform firmware, not with
> software, and is often outside of the users control.
>
> Even if we'd prefer t
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> Introduce the main Secure Launch header file used in the early SL stub
> and the early setup code.
>
> Signed-off-by: Ross Philipson
Right and anything AMD specific should also have legit references. I
actually always compare to the spe
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
If a uarch specific, I'd appreciate Intel SDM reference here so that I
can look it up
On Fri May 31, 2024 at 4:03 AM EEST, Ross Philipson wrote:
> From: Arvind Sankar
>
> There are use cases for storing the offset of a symbol in kernel_info.
> For example, the trenchboot series [0] needs to store the offset of the
> Measured Launch Environment header in kernel_info.
So either ther
On 6/4/24 10:27 AM, Ard Biesheuvel wrote:
On Tue, 4 Jun 2024 at 19:24, wrote:
On 5/31/24 6:33 AM, Ard Biesheuvel wrote:
On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
Hello Ross,
On Fri, 31 May 2024 at 03:32, Ross Philipson wrote:
The Secure Launch (SL) stub provides the entry poi
On 5/31/24 7:04 AM, Ard Biesheuvel wrote:
On Fri, 31 May 2024 at 15:33, Ard Biesheuvel wrote:
On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
Hello Ross,
On Fri, 31 May 2024 at 03:32, Ross Philipson wrote:
The Secure Launch (SL) stub provides the entry point for Intel TXT (and
later
On Tue, 4 Jun 2024 at 19:24, wrote:
>
> On 5/31/24 6:33 AM, Ard Biesheuvel wrote:
> > On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
> >>
> >> Hello Ross,
> >>
> >> On Fri, 31 May 2024 at 03:32, Ross Philipson
> >> wrote:
> >>>
> >>> The Secure Launch (SL) stub provides the entry point for
On 5/31/24 6:33 AM, Ard Biesheuvel wrote:
On Fri, 31 May 2024 at 13:00, Ard Biesheuvel wrote:
Hello Ross,
On Fri, 31 May 2024 at 03:32, Ross Philipson wrote:
The Secure Launch (SL) stub provides the entry point for Intel TXT (and
later AMD SKINIT) to vector to during the late launch. The s
On 5/31/24 4:09 AM, Ard Biesheuvel wrote:
On Fri, 31 May 2024 at 03:32, Ross Philipson wrote:
This support allows the DRTM launch to be initiated after an EFI stub
launch of the Linux kernel is done. This is accomplished by providing
a handler to jump to when a Secure Launch is in progress. Th
On 5/31/24 4:00 AM, Ard Biesheuvel wrote:
Hello Ross,
Hi Ard,
On Fri, 31 May 2024 at 03:32, Ross Philipson wrote:
The Secure Launch (SL) stub provides the entry point for Intel TXT (and
later AMD SKINIT) to vector to during the late launch. The symbol
sl_stub_entry is that entry point and
41 matches
Mail list logo
