On Wed, Jun 5, 2019 at 6:25 PM Heinrich Schuchardt wrote:
> On 6/5/19 3:55 PM, Francois Ozog wrote:
> > II - Desired DT for EBBR policy
> >
> > 1) "upstream" DT
> >
> > 1.1) who provides DT
> > Board vendor make a that describes every hardware piece,
> > firmware provides a DT to OS, OS may be ab
I introduced the discussion topic to LEDGE Steering Committee today.
Linaro will focus on the use case where the DT is provided by the firmware.
Other use cases may be considered at a later stage.
On Thu, 6 Jun 2019 at 11:10, Tom Rini wrote:
> On Thu, Jun 06, 2019 at 09:08:25AM +0200, Ard Bie
[ Snipping again ]
On Thu, Jun 06, 2019 at 11:10:07AM -0400, Tom Rini wrote:
>On Thu, Jun 06, 2019 at 09:08:25AM +0200, Ard Biesheuvel wrote:
>> On Wed, 5 Jun 2019 at 21:28, Tom Rini wrote:
>> >
>> > Where does this description that's coming with the board come from?
>> > That _matters_ if you wa
+Bill
Le jeu. 6 juin 2019 à 03:08, Ard Biesheuvel a
écrit :
> On Wed, 5 Jun 2019 at 21:28, Tom Rini wrote:
> >
> > On Wed, Jun 05, 2019 at 08:30:12PM +0200, Ard Biesheuvel wrote:
> > > On Wed, 5 Jun 2019 at 19:30, Tom Rini wrote:
> > > >
> > > > On Wed, Jun 05, 2019 at 06:14:08PM +0100, Mark B
On Wed, 5 Jun 2019 at 21:28, Tom Rini wrote:
>
> On Wed, Jun 05, 2019 at 08:30:12PM +0200, Ard Biesheuvel wrote:
> > On Wed, 5 Jun 2019 at 19:30, Tom Rini wrote:
> > >
> > > On Wed, Jun 05, 2019 at 06:14:08PM +0100, Mark Brown wrote:
> > > > On Wed, Jun 05, 2019 at 02:16:11PM +0200, Ard Biesheuve
On Wed, 5 Jun 2019 at 19:30, Tom Rini wrote:
>
> On Wed, Jun 05, 2019 at 06:14:08PM +0100, Mark Brown wrote:
> > On Wed, Jun 05, 2019 at 02:16:11PM +0200, Ard Biesheuvel wrote:
> >
> > > The idea of EBBR is to move away from a vertically integrated model,
> > > and permit systems or appliances to
On 6/5/19 3:55 PM, Francois Ozog wrote:
So trying to summarize the DT side track discussion in a different thread:
(
Shall we organize a virtual design sprint before the end of the month?
I'd like to create a section from the discussion in Boot Flows documen
)
I - Current situation is:
- DT pro
is.o...@linaro.org]
> *Sent:* Wednesday, June 5, 2019 9:55 AM
> *To:* Tom Rini
> *Cc:* Ard Biesheuvel; Grant Likely; Heinrich Schuchardt; Ilias
> Apalodimas; boot-architecture@lists.linaro.org; nd; Loic Pallardy; Mills,
> William; Peter Robinson
> *Subject:* DT and EBBR, was: S
[mailto:francois.o...@linaro.org]
Sent: Wednesday, June 5, 2019 9:55 AM
To: Tom Rini
Cc: Ard Biesheuvel; Grant Likely; Heinrich Schuchardt; Ilias Apalodimas;
boot-architecture@lists.linaro.org; nd; Loic Pallardy; Mills, William; Peter
Robinson
Subject: DT and EBBR, was: Securing the boot flow in U
So trying to summarize the DT side track discussion in a different thread:
(
Shall we organize a virtual design sprint before the end of the month?
I'd like to create a section from the discussion in Boot Flows documen
)
I - Current situation is:
- DT provided by Linux kernel because it was “easi
On Wed, 5 Jun 2019 at 14:59, Tom Rini wrote:
>
> On Wed, Jun 05, 2019 at 09:17:04AM +0100, Graeme Gregory wrote:
> > On Wed, 5 Jun 2019 at 07:36, Ard Biesheuvel
> > wrote:
> >
> > > On Wed, 5 Jun 2019 at 00:41, Tom Rini wrote:
> > > >
> > > ...
> > >
> > > > It depends on what you mean by "OS pr
On Wed, 5 Jun 2019 at 13:14, Mark Brown wrote:
>
> On Wed, Jun 05, 2019 at 11:18:44AM +0100, Steve McIntyre wrote:
>
> > Nod. We're *way* past the time where this should have stopped. How on
> > earth do we get to common DT useful for all bootloaders, OSes (etc.)
> > if people still consider the b
On Wed, Jun 05, 2019 at 08:36:25AM +0200, Ard Biesheuvel wrote:
>On Wed, 5 Jun 2019 at 00:41, Tom Rini wrote:
>>
>...
>
>> It depends on what you mean by "OS provided". The DTS files come from
>> the Linux Kernel sources, full stop.
>
>That is the mistake we should try to fix.
>
>We have DT bindi
On Wed, 5 Jun 2019 at 07:36, Ard Biesheuvel
wrote:
> On Wed, 5 Jun 2019 at 00:41, Tom Rini wrote:
> >
> ...
>
> > It depends on what you mean by "OS provided". The DTS files come from
> > the Linux Kernel sources, full stop.
>
> That is the mistake we should try to fix.
>
> We have DT bindings,
On Wed, 5 Jun 2019 at 00:41, Tom Rini wrote:
>
...
> It depends on what you mean by "OS provided". The DTS files come from
> the Linux Kernel sources, full stop.
That is the mistake we should try to fix.
We have DT bindings, which define the contract between the OS on one
side, and the platfor
On Wed, 5 Jun 2019 at 00:34, Tom Rini wrote:
>
> On Tue, Jun 04, 2019 at 06:14:16PM -0400, Francois Ozog wrote:
> > Le mar. 4 juin 2019 à 17:31, Tom Rini a écrit :
> >
...
> > I think it may be good to validate but not provide. There is no Linux
> > provided ACPI table right ? So I get the point
Le mar. 4 juin 2019 à 17:31, Tom Rini a écrit :
> On Tue, Jun 04, 2019 at 10:25:23AM -0400, Francois Ozog wrote:
> > On Tue, 4 Jun 2019 at 10:17, Heinrich Schuchardt
> wrote:
> >
> > >
> > >
> > > On 6/4/19 3:55 PM, Francois Ozog wrote:
> > > > On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel <
> ard
Le mar. 4 juin 2019 à 17:27, Tom Rini a écrit :
> On Tue, Jun 04, 2019 at 10:21:54AM -0400, Francois Ozog wrote:
> > On Tue, 4 Jun 2019 at 10:00, Ard Biesheuvel
> > wrote:
> >
> > >
> > >
> > > On Tue, 4 Jun 2019 at 15:55, Francois Ozog
> > > wrote:
> > >
> > >>
> > >>
> > >> On Tue, 4 Jun 2019
On Tue, 4 Jun 2019 at 18:38, Francois Ozog wrote:
>
>
> On Tue, 4 Jun 2019 at 10:57, Ard Biesheuvel
> wrote:
>
>>
>> Yes, that makes sense. But the problem is that UEFI secure boot does not
>> support this model. An image is considered valid if it authenticates
>> against any of the keys in db.
On Tue, 4 Jun 2019 at 10:57, Ard Biesheuvel
wrote:
>
>
> On Tue, 4 Jun 2019 at 16:52, Francois Ozog
> wrote:
>
>>
>>
>> On Tue, 4 Jun 2019 at 10:37, Ard Biesheuvel
>> wrote:
>>
>>> On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt
>>> wrote:
>>> >
>>> >
>>> >
>>> > On 6/4/19 4:20 PM, Ard Bieshe
[ Trimming some quoting! ]
On Tue, Jun 04, 2019 at 11:17:09AM -0400, Francois Ozog wrote:
>On Tue, 4 Jun 2019 at 10:57, Ard Biesheuvel
>>>
>> Yes, that makes sense. But the problem is that UEFI secure boot does not
>> support this model. An image is considered valid if it authenticates
>> against
On Tue, 4 Jun 2019 at 10:57, Ard Biesheuvel
wrote:
>
>
> On Tue, 4 Jun 2019 at 16:52, Francois Ozog
> wrote:
>
>>
>>
>> On Tue, 4 Jun 2019 at 10:37, Ard Biesheuvel
>> wrote:
>>
>>> On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt
>>> wrote:
>>> >
>>> >
>>> >
>>> > On 6/4/19 4:20 PM, Ard Bieshe
On Tue, 4 Jun 2019 at 16:52, Francois Ozog wrote:
>
>
> On Tue, 4 Jun 2019 at 10:37, Ard Biesheuvel
> wrote:
>
>> On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt
>> wrote:
>> >
>> >
>> >
>> > On 6/4/19 4:20 PM, Ard Biesheuvel wrote:
>> > > On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt
>> w
On Tue, 4 Jun 2019 at 10:37, Ard Biesheuvel
wrote:
> On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt
> wrote:
> >
> >
> >
> > On 6/4/19 4:20 PM, Ard Biesheuvel wrote:
> > > On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt
> wrote:
> > >>
> > >>
> > >>
> > >> On 6/4/19 3:55 PM, Francois Ozog wr
On 6/4/19 4:37 PM, Ard Biesheuvel wrote:
> On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt wrote:
>>
>>
>>
>> On 6/4/19 4:20 PM, Ard Biesheuvel wrote:
>>> On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt wrote:
On 6/4/19 3:55 PM, Francois Ozog wrote:
> On Tue, 4 Jun 201
On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt wrote:
>
>
>
> On 6/4/19 4:20 PM, Ard Biesheuvel wrote:
> > On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt wrote:
> >>
> >>
> >>
> >> On 6/4/19 3:55 PM, Francois Ozog wrote:
> >>> On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel
> >>> wrote:
> >>>
>
On 6/4/19 4:20 PM, Ard Biesheuvel wrote:
> On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt wrote:
>>
>>
>>
>> On 6/4/19 3:55 PM, Francois Ozog wrote:
>>> On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel
>>> wrote:
>>>
On Tue, 4 Jun 2019 at 15:44, Francois Ozog
wrote:
>
On Tue, 4 Jun 2019 at 10:17, Heinrich Schuchardt wrote:
>
>
> On 6/4/19 3:55 PM, Francois Ozog wrote:
> > On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel
> > wrote:
> >
> >>
> >>
> >> On Tue, 4 Jun 2019 at 15:44, Francois Ozog
> >> wrote:
> >>
> >>> Hi Ard,
> >>>
> >>> On Fri, 31 May 2019 at 13:35,
On Tue, 4 Jun 2019 at 10:00, Ard Biesheuvel
wrote:
>
>
> On Tue, 4 Jun 2019 at 15:55, Francois Ozog
> wrote:
>
>>
>>
>> On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel
>> wrote:
>>
>>>
>>>
>>> On Tue, 4 Jun 2019 at 15:44, Francois Ozog
>>> wrote:
>>>
Hi Ard,
On Fri, 31 May 2019 at 1
On Tue, 4 Jun 2019 at 16:17, Heinrich Schuchardt wrote:
>
>
>
> On 6/4/19 3:55 PM, Francois Ozog wrote:
> > On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel
> > wrote:
> >
> >>
> >>
> >> On Tue, 4 Jun 2019 at 15:44, Francois Ozog
> >> wrote:
> >>
> >>> Hi Ard,
> >>>
> >>> On Fri, 31 May 2019 at 13:35
On 6/4/19 3:55 PM, Francois Ozog wrote:
> On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel
> wrote:
>
>>
>>
>> On Tue, 4 Jun 2019 at 15:44, Francois Ozog
>> wrote:
>>
>>> Hi Ard,
>>>
>>> On Fri, 31 May 2019 at 13:35, Ard Biesheuvel
>>> wrote:
>>>
On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
On Tue, 4 Jun 2019 at 15:55, Francois Ozog wrote:
>
>
> On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel
> wrote:
>
>>
>>
>> On Tue, 4 Jun 2019 at 15:44, Francois Ozog
>> wrote:
>>
>>> Hi Ard,
>>>
>>> On Fri, 31 May 2019 at 13:35, Ard Biesheuvel
>>> wrote:
>>>
On Fri, 31 May 2019 at 19:25, Ili
On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel
wrote:
>
>
> On Tue, 4 Jun 2019 at 15:44, Francois Ozog
> wrote:
>
>> Hi Ard,
>>
>> On Fri, 31 May 2019 at 13:35, Ard Biesheuvel
>> wrote:
>>
>>> On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
>>> wrote:
>>> >
>>> > Hi Grant,
>>> > > I see two ways t
On Tue, 4 Jun 2019 at 15:44, Francois Ozog wrote:
> Hi Ard,
>
> On Fri, 31 May 2019 at 13:35, Ard Biesheuvel
> wrote:
>
>> On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
>> wrote:
>> >
>> > Hi Grant,
>> > > I see two ways to handle this that fits with the Secure Boot
>> > > authentication path:
Hi Ard,
On Fri, 31 May 2019 at 13:35, Ard Biesheuvel
wrote:
> On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
> wrote:
> >
> > Hi Grant,
> > > I see two ways to handle this that fits with the Secure Boot
> > > authentication path:
> > >
> > > Option 1: Leave it to the OS loader
> > > We could si
On Fri, 31 May 2019 at 19:25, Ilias Apalodimas
wrote:
>
> Hi Grant,
> > I see two ways to handle this that fits with the Secure Boot
> > authentication path:
> >
> > Option 1: Leave it to the OS loader
> > We could simply say that if the OS wants to replace the DTB, then it
> > should take care of
On 5/31/19 7:16 PM, Ilias Apalodimas wrote:
Hi Grant,
I see two ways to handle this that fits with the Secure Boot
authentication path:
Option 1: Leave it to the OS loader
We could simply say that if the OS wants to replace the DTB, then it
should take care of authentication itself within the O
Hi Grant,
> I see two ways to handle this that fits with the Secure Boot
> authentication path:
>
> Option 1: Leave it to the OS loader
> We could simply say that if the OS wants to replace the DTB, then it
> should take care of authentication itself within the OS loader (possibly
> the in-kern
On 5/31/19 5:33 PM, Alexander Graf wrote:
>
>
>> Am 31.05.2019 um 17:18 schrieb Ilias Apalodimas
>> :
>>
>> Hi Tom,
>>> On Fri, May 31, 2019 at 11:05:20AM -0400, Tom Rini wrote:
On Fri, May 31, 2019 at 02:40:32PM +0100, Steve McIntyre wrote:
On Tue, May 28, 2019 at 02:04:23PM +0300, Ilia
On 5/31/19 4:47 PM, Ilias Apalodimas wrote:
> Hi Grant,
>> On 24/05/2019 16:28, Ilias Apalodimas wrote:
>>> Hello all,
>>>
>>> Continuing the discussions we had on securing the boot flow and OS as much
>>> as
>>> possible, we came up with the following idea.
>>>
>>> We are currently sorting out wh
> Am 31.05.2019 um 17:18 schrieb Ilias Apalodimas :
>
> Hi Tom,
>> On Fri, May 31, 2019 at 11:05:20AM -0400, Tom Rini wrote:
>>> On Fri, May 31, 2019 at 02:40:32PM +0100, Steve McIntyre wrote:
>>> On Tue, May 28, 2019 at 02:04:23PM +0300, Ilias Apalodimas wrote:
>>
>> The tl;dr purpose
Hi Tom,
On Fri, May 31, 2019 at 11:05:20AM -0400, Tom Rini wrote:
> On Fri, May 31, 2019 at 02:40:32PM +0100, Steve McIntyre wrote:
> > On Tue, May 28, 2019 at 02:04:23PM +0300, Ilias Apalodimas wrote:
> > >> >
> > >> > The tl;dr purpose of my e-mail was 'Is implementing UEFI Secure Boot
> > >>
Hi Grant,
> On 24/05/2019 16:28, Ilias Apalodimas wrote:
> > Hello all,
> >
> > Continuing the discussions we had on securing the boot flow and OS as much
> > as
> > possible, we came up with the following idea.
> >
> > We are currently sorting out what's needed to add UEFI Secure Boot in
> > U
On Tue, May 28, 2019 at 02:04:23PM +0300, Ilias Apalodimas wrote:
>> >
>> > The tl;dr purpose of my e-mail was 'Is implementing UEFI Secure Boot for
>> > the
>> > EFI playloads
>>
>> I think that you'd better explain why you stick to *UEFI* secure boot.
>
>The main reason is distro support. Sin
On 5/31/19 2:12 PM, Francois Ozog wrote:
> Can we just register the OS loader as a UEFI protocol (say LoadGrubImage,
> LoadLinuxImage, LoadAndroidImage), which would do everything needed to
> check the broader environment?
> This becomes usable with both EDKII and U-Boot?
>
> LoadImage is used by
On 31/05/2019 13:12, Francois Ozog wrote:
> Can we just register the OS loader as a UEFI protocol (say
> LoadGrubImage, LoadLinuxImage, LoadAndroidImage), which would do
> everything needed to check the broader environment?
> This becomes usable with both EDKII and U-Boot?
If the protocol (or an
>>>> From: Ilias Apalodimas
>>>>> Sent: Friday, May 24, 2019 9:57 PM
>>>>> To: Udit Kumar
>>>>> Cc: boot-architecture@lists.linaro.org; Varun Sethi
>>>>> Subject: Re: [EXT] Securing the boot flow in U-Boot
>>>>>
, May 24, 2019 9:57 PM
> >>> To: Udit Kumar
> >>> Cc: boot-architecture@lists.linaro.org; Varun Sethi
> >>> Subject: Re: [EXT] Securing the boot flow in U-Boot
> >>>
> >>> Caution: EXT Email
> >>>
> >>> Hi Udit,
> >
gt; Sent: Friday, May 24, 2019 9:57 PM
> >>> To: Udit Kumar
> >>> Cc: boot-architecture@lists.linaro.org; Varun Sethi
> >>> Subject: Re: [EXT] Securing the boot flow in U-Boot
> >>>
> >>> Caution: EXT Email
> >>>
> >>&g
Can we just register the OS loader as a UEFI protocol (say LoadGrubImage,
LoadLinuxImage, LoadAndroidImage), which would do everything needed to
check the broader environment?
This becomes usable with both EDKII and U-Boot?
LoadImage is used by to securely load shim.efi
LoadGrubImage is used by s
On 27/05/2019 10:05, Ilias Apalodimas wrote:
> Hi Udit,
>> Hi Ilias
>>
>>> -Original Message-
>>> From: Ilias Apalodimas
>>> Sent: Friday, May 24, 2019 9:57 PM
>>> To: Udit Kumar
>>> Cc: boot-architecture@lists.linaro.org; V
On 24/05/2019 16:28, Ilias Apalodimas wrote:
> Hello all,
>
> Continuing the discussions we had on securing the boot flow and OS as much as
> possible, we came up with the following idea.
>
> We are currently sorting out what's needed to add UEFI Secure Boot in U-Boot.
> This will cover the nex
> >
> > The tl;dr purpose of my e-mail was 'Is implementing UEFI Secure Boot for
> > the
> > EFI playloads
>
> I think that you'd better explain why you stick to *UEFI* secure boot.
The main reason is distro support. Since distros use a number of different ways
of booting up on arm boards, usi
Ilias,
On Mon, May 27, 2019 at 12:09:26PM +0300, Ilias Apalodimas wrote:
> Hi Tom,
> > >
> > > > > Continuing the discussions we had on securing the boot flow and OS as
> > > > > much as
> > > > > possible, we came up with the following idea.
> > > > >
> > > > > We are currently sorting out wha
Hi Tom,
> >
> > > > Continuing the discussions we had on securing the boot flow and OS as
> > > > much as
> > > > possible, we came up with the following idea.
> > > >
> > > > We are currently sorting out what's needed to add UEFI Secure Boot in
> > > > U-Boot.
> > > > This will cover the next
Hi Udit,
> Hi Ilias
>
> > -Original Message-
> > From: Ilias Apalodimas
> > Sent: Friday, May 24, 2019 9:57 PM
> > To: Udit Kumar
> > Cc: boot-architecture@lists.linaro.org; Varun Sethi
> > Subject: Re: [EXT] Securing the boot flow in U-Bo
Hi Ilias
> -Original Message-
> From: Ilias Apalodimas
> Sent: Friday, May 24, 2019 9:57 PM
> To: Udit Kumar
> Cc: boot-architecture@lists.linaro.org; Varun Sethi
> Subject: Re: [EXT] Securing the boot flow in U-Boot
>
> Caution: EXT Email
>
> Hi Udit,
Hi Tom,
> > Continuing the discussions we had on securing the boot flow and OS as much
> > as
> > possible, we came up with the following idea.
> >
> > We are currently sorting out what's needed to add UEFI Secure Boot in
> > U-Boot.
> > This will cover the next payload (shim/grub2/shim depend
Hi Udit,
> >
> > Continuing the discussions we had on securing the boot flow and OS as much
> > as
> > possible, we came up with the following idea.
> >
> > We are currently sorting out what's needed to add UEFI Secure Boot in
> > U-Boot.
>
> I believe you are planning to support as UEFI spec
Hi Ilias
> -Original Message-
> From: boot-architecture On
> Behalf Of Ilias Apalodimas
> Sent: Friday, May 24, 2019 8:59 PM
> To: boot-architecture@lists.linaro.org
> Subject: [EXT] Securing the boot flow in U-Boot
>
> Caution: EXT Email
>
> Hello all,
&
Hello all,
Continuing the discussions we had on securing the boot flow and OS as much as
possible, we came up with the following idea.
We are currently sorting out what's needed to add UEFI Secure Boot in U-Boot.
This will cover the next payload (shim/grub2/shim depending on board needs).
In or
61 matches
Mail list logo
