On Fri, Aug 12, 2022 at 12:52:58PM +0930, Brendan Trotter wrote:
> Hi,
>
> On Fri, Aug 12, 2022 at 3:55 AM Matthew Garrett wrote:
> > On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote:
> > > On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett
> > > wrote:
> > > > The kernel has no
Hi,
On Fri, Aug 12, 2022 at 3:55 AM Matthew Garrett wrote:
> On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote:
> > On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett wrote:
> > > The kernel has no way to know this - *any* code you've run before
> > > performing a measurement could
On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote:
> Hi,
>
> On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett wrote:
> > The kernel has no way to know this - *any* code you've run before
> > performing a measurement could tamper with the kernel such that it
> > believes it's fine.
On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote:
> Hi,
>
> On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett wrote:
> > On Wed, Aug 10, 2022 at 06:37:18PM +0930, Brendan Trotter wrote:
> >
> > > [1] doesn't provide any useful information. How does a kernel know
> > > that the
Hi,
On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett wrote:
> On Wed, Aug 10, 2022 at 06:37:18PM +0930, Brendan Trotter wrote:
>
> > [1] doesn't provide any useful information. How does a kernel know
> > that the callback provided by boot loader actually measures what it's
> > supposed to
On Wed, Aug 10, 2022 at 06:37:18PM +0930, Brendan Trotter wrote:
> [1] doesn't provide any useful information. How does a kernel know
> that the callback provided by boot loader actually measures what it's
> supposed to measure, or even does anything at all?
The kernel has no way to know this -
Hi,
On Tue, Aug 9, 2022 at 8:25 PM Daniel P. Smith
wrote:
> On 7/23/22 01:15, Brendan Trotter wrote:
> > On Sat, Jul 23, 2022 at 2:53 AM Daniel P. Smith
> > wrote:
> >> On 7/7/22 23:36, Brendan Trotter wrote:
> >>> On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith
> >>> wrote:
> On 7/5/22
On 7/23/22 01:15, Brendan Trotter wrote:
Hi,
Greetings,
On Sat, Jul 23, 2022 at 2:53 AM Daniel P. Smith
wrote:
On 7/7/22 23:36, Brendan Trotter wrote:
On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith
wrote:
On 7/5/22 20:03, Brendan Trotter wrote:
On Wed, Jul 6, 2022 at 4:52 AM Daniel P.
On Tue, 5 Jul 2022 at 21:22, Daniel P. Smith
wrote:
>
> On 6/10/22 12:40, Ard Biesheuvel wrote:
...
> > The EFI stub to core kernel handover ABI is private to Linux,
> > architecture specific, and subject to change. This is basically the
> > point I made before: if you want to boot Linux in EFI
Hi,
On Sat, Jul 23, 2022 at 2:53 AM Daniel P. Smith
wrote:
> On 7/7/22 23:36, Brendan Trotter wrote:
> > On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith
> > wrote:
> >> On 7/5/22 20:03, Brendan Trotter wrote:
> >>> On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith
> >>> wrote:
> On 6/10/22
On 7/7/22 23:36, Brendan Trotter wrote:
> Hi,
>
> On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith
> wrote:
>> On 7/5/22 20:03, Brendan Trotter wrote:
>> Greetings!
>>
>> Not sure why I got dropped from distro, but no worries.
>>
>>> On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith
>>> wrote:
On Fri, Jul 08, 2022 at 01:06:19PM +0930, Brendan Trotter wrote:
> This leaves me wondering what your true motivation is. Are you trying
> to benefit GRUB/Trenchboot (at the expense of security, end-user
> convenience, distro installer hassle, etc); or trying to manufacture
> scope for future
Hi,
On Thu, Jul 7, 2022 at 7:18 PM Daniel P. Smith
wrote:
> On 7/5/22 20:03, Brendan Trotter wrote:
> Greetings!
>
> Not sure why I got dropped from distro, but no worries.
>
> > On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith
> > wrote:
> >> On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19
On 7/5/22 20:03, Brendan Trotter wrote:
Hi,
Greetings!
Not sure why I got dropped from distro, but no worries.
On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith
wrote:
On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59,
To help provide clarity, consider the following flows
On Wed, Jul 06, 2022 at 09:33:23AM +0930, Brendan Trotter wrote:
> The only correct approach is "efi-stub -> head_64.S -> kernel's own
> secure init"; where (on UEFI systems) neither GRUB nor Trenchboot has
> a valid reason to exist and should never be installed.
Surely the entire point of DRTM
Hi,
On Wed, Jul 6, 2022 at 4:52 AM Daniel P. Smith
wrote:
> On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59,
> To help provide clarity, consider the following flows for comparison,
>
> Normal/existing efi-stub:
> EFI -> efi-stub -> head_64.S
>
> Proposed secure launch:
>
On 6/10/22 12:40, Ard Biesheuvel wrote:> On Thu, 19 May 2022 at 22:59,
Daniel P. Smith
> wrote:
>>
>>
>> Greetings,
>>
>> While Matthew's original proposal was around having a location in the
>> efi-stub for the callback to be registered, it is felt that it would be
>> better suited as part of
On Thu, 19 May 2022 at 22:59, Daniel P. Smith
wrote:
>
>
> Greetings,
>
> Based on the discussions that occurred in this thread, there seems to be
> two issues at hand that should be decoupled, as their solutions can and
> should be implemented independently. These are:
> - the handling of the
Hey Ard,
Apologies for the lag in response, I wanted to have this to you sooner,
but between a variety of events and working on building consensus on how
to address your comments made it drag out a little. Before reading this
message, I would recommend reading the proposal posted to the top of
Greetings,
Based on the discussions that occurred in this thread, there seems to be
two issues at hand that should be decoupled, as their solutions can and
should be implemented independently. These are:
- the handling of the Dynamic Launch preamble
- providing the complete kernel configuration
On 3/31/22 09:13, Ard Biesheuvel wrote:
On Thu, 31 Mar 2022 at 02:36, Daniel P. Smith
wrote:
Greetings Matthew,
First thank you to you and James for taking time out of your busy
schedules to sit down with us and work through all of this.
Hey Ard,
On 3/30/22 03:02, Ard Biesheuvel wrote:>>
On Thu, 31 Mar 2022 at 02:36, Daniel P. Smith
wrote:
>
> Greetings Matthew,
>
> First thank you to you and James for taking time out of your busy
> schedules to sit down with us and work through all of this.
>
> Hey Ard,
>
> On 3/30/22 03:02, Ard Biesheuvel wrote:>> 1) From an EFI maintainer
>
Greetings Matthew,
First thank you to you and James for taking time out of your busy
schedules to sit down with us and work through all of this.
Hey Ard,
On 3/30/22 03:02, Ard Biesheuvel wrote:>> 1) From an EFI maintainer
perspective, is making the contract between
>> the boot stub and the
On Wed, 2022-03-30 at 09:39 +0200, Ard Biesheuvel wrote:
> On Wed, 30 Mar 2022 at 09:27, Matthew Garrett
> wrote:
> > On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote:
> > > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett <
> > > mj...@srcf.ucam.org> wrote:
> > > > From a conceptual
On Wed, 30 Mar 2022 at 09:27, Matthew Garrett wrote:
>
> On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote:
> > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett wrote:
> > > From a conceptual perspective we've thought of the EFI stub as being
> > > logically part of the bootloader
On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote:
> On Wed, 30 Mar 2022 at 09:19, Matthew Garrett wrote:
> > From a conceptual perspective we've thought of the EFI stub as being
> > logically part of the bootloader rather than the early kernel, and the
> > bootloader is a point
On Wed, 30 Mar 2022 at 09:19, Matthew Garrett wrote:
>
> On Wed, Mar 30, 2022 at 09:12:19AM +0200, Ard Biesheuvel wrote:
> > On Wed, 30 Mar 2022 at 09:11, Matthew Garrett wrote:
> > > The EFI stub carries out a bunch of actions that have meaningful
> > > security impact, and that's material that
On Wed, Mar 30, 2022 at 09:12:19AM +0200, Ard Biesheuvel wrote:
> On Wed, 30 Mar 2022 at 09:11, Matthew Garrett wrote:
> > The EFI stub carries out a bunch of actions that have meaningful
> > security impact, and that's material that should be measured. Having the
> > secure launch kernel execute
On Wed, 30 Mar 2022 at 09:11, Matthew Garrett wrote:
>
> On Wed, Mar 30, 2022 at 09:02:18AM +0200, Ard Biesheuvel wrote:
>
> > Wouldn't it be better for the secure launch kernel to boot the EFI
> > entrypoint directly? As it happens, I just completed a PoC last week
> > for a minimal
On Wed, Mar 30, 2022 at 09:02:18AM +0200, Ard Biesheuvel wrote:
> Wouldn't it be better for the secure launch kernel to boot the EFI
> entrypoint directly? As it happens, I just completed a PoC last week
> for a minimal implementation of EFI (in Rust) that only carries the
> pieces that the EFI
Hi Matt,
On Tue, 29 Mar 2022 at 19:41, Matthew Garrett wrote:
>
> We're still trying to come to a conclusion about the most maintainable
> approach to getting DRTM implementations like Intel TXT working on UEFI
> platforms under Linux. I'm going to try to summarise the situation here
> - I'm not
We're still trying to come to a conclusion about the most maintainable
approach to getting DRTM implementations like Intel TXT working on UEFI
platforms under Linux. I'm going to try to summarise the situation here
- I'm not an expert, so details may be inaccurate, but I think this is
the
32 matches
Mail list logo
