On Mon Aug 19, 2024 at 9:24 PM EEST, Matthew Garrett wrote:
> On Mon, Aug 19, 2024 at 09:05:47PM +0300, Jarkko Sakkinen wrote:
> > On Fri Aug 16, 2024 at 9:41 PM EEST, Matthew Garrett wrote:
> > > On Fri, Aug 16, 2024 at 02:22:04PM +0300, Jarkko Sakkinen wrote:
> > >
&
On Fri Aug 16, 2024 at 9:41 PM EEST, Matthew Garrett wrote:
> On Fri, Aug 16, 2024 at 02:22:04PM +0300, Jarkko Sakkinen wrote:
>
> > For (any) non-legacy features we can choose, which choices we choose to
> > support, and which we do not. This is not an oppositive view just sa
On Fri Aug 16, 2024 at 2:01 PM EEST, Andrew Cooper wrote:
> On 15/08/2024 8:10 pm, Thomas Gleixner wrote:
> > On Thu, Aug 15 2024 at 13:38, Daniel P. Smith wrote:
> >> On 5/31/24 09:54, Eric W. Biederman wrote:
> >>> Eric Biggers writes:
> That paragraph is also phrased as a hypothetical, "Ev
On Thu Aug 15, 2024 at 10:10 PM EEST, Thomas Gleixner wrote:
> On Thu, Aug 15 2024 at 13:38, Daniel P. Smith wrote:
> > On 5/31/24 09:54, Eric W. Biederman wrote:
> >> Eric Biggers writes:
> >>> That paragraph is also phrased as a hypothetical, "Even if we'd prefer to
> >>> use
> >>> SHA-256-only
On Mon Aug 12, 2024 at 10:02 PM EEST, wrote:
> On 6/4/24 3: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 b
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 5
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 rundow
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
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 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:
> >>
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.
&g
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 b
> > 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-25
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
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 Mon, Aug 09, 2021 at 12:38:42PM -0400, Ross Philipson wrote:
> The focus of Trechboot project (https://github.com/TrenchBoot) is to
> enhance the boot security and integrity. This requires the linux kernel
~
On Mon, Aug 09, 2021 at 12:38:56PM -0400, Ross Philipson wrote:
> The Secure Launch MLE environment uses PCRs that are only accessible from
> the DRTM locality 2. By default the TPM drivers always initialize the
> locality to 0. When a Secure Launch is in progress, initialize the
> locality to 2.
>
On Mon, Aug 09, 2021 at 12:38:44PM -0400, Ross Philipson wrote:
> One of the two functions in ioremap.c that handles setup_data was
> missing the correct handling of setup_indirect structures.
What is "correct handling", and how was it broken?
What is 'setup_indirect'?
> Functionality missing fr
On Wed, Sep 30, 2020 at 06:19:57AM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 29, 2020 at 07:47:52PM -0400, Daniel P. Smith wrote:
> > TrenchBoot's AMD Secure Loader (LZ). The former is not well supported
> > and the latter will be getting maintenance under TB. While this is n
On Tue, Sep 29, 2020 at 07:47:52PM -0400, Daniel P. Smith wrote:
> TrenchBoot's AMD Secure Loader (LZ). The former is not well supported
> and the latter will be getting maintenance under TB. While this is not
> preferred, we had to weigh this versus trying to convince you and the
> other TPM drive
On Fri, Sep 25, 2020 at 05:32:50PM -0400, Daniel P. Smith wrote:
> The work for this is split across different teams with different
> resourcing levels resulting in one organization working Intel and
> another working AMD. This then raised the concern over submitting a
> single patch set developed
On Thu, Sep 24, 2020 at 10:58:33AM -0400, Ross Philipson wrote:
> From: "Daniel P. Smith"
>
> This commit introduces an abstraction for TPM1.2 and TPM2.0 devices
> above the TPM hardware interface.
>
> Signed-off-by: Daniel P. Smith
> Signed-off-by: Ross Philipson
This is way, way too PoC. I
On Thu, Sep 24, 2020 at 10:58:28AM -0400, Ross Philipson wrote:
> The Trenchboot project focus on boot security has led to the enabling of
> the Linux kernel to be directly invocable by the x86 Dynamic Launch
> instruction(s) for establishing a Dynamic Root of Trust for Measurement
> (DRTM). The dy
On Sun, Sep 06, 2020 at 11:38:08PM -0400, Ronan Jouchet wrote:
> Hi. This is a follow-up of [BUG]
> https://bugzilla.kernel.org/show_bug.cgi?id=197029 ,
> where Jarkko Sakkinen asks in comment 31 to move discussion here.
>
> [1.] One line summary of the problem:
>
> intel_i
37 matches
Mail list logo
