On Thu, Jan 24, 2019 at 6:24 PM Julius Werner wrote:
> > What does that practically look like? Every time we have to re-walk we
> have to reverify the integrity of the metadata.
>
> I mean, that is exactly what we're doing right now anyway (unless
> something significantly changed in CBFS code
> What does that practically look like? Every time we have to re-walk we have
> to reverify the integrity of the metadata.
I mean, that is exactly what we're doing right now anyway (unless
something significantly changed in CBFS code since the last time I
checked). For every single CBFS file
; > -Ursprüngliche Nachricht-
> > Von: Julius Werner [mailto:jwer...@chromium.org]
> > Gesendet: Donnerstag, 24. Januar 2019 00:01
> > An: Aaron Durbin
> > Cc: Julius Werner; Arthur Heymans; Coreboot
> > Betreff: [coreboot] Re: Fallback mechanisms on x86 with
>
On Wed, Jan 23, 2019 at 4:00 PM Julius Werner wrote:
> > For 1, this is attempting to protect physical attack. Obviously this
> particular problem can't be solved in isolation, but it's something to
> think about.
>
> But isn't this something that per-file hashing would probably make
> easier to
4. Januar 2019 00:01
> An: Aaron Durbin
> Cc: Julius Werner; Arthur Heymans; Coreboot
> Betreff: [coreboot] Re: Fallback mechanisms on x86 with
> C_ENVIRONMENT_BOOTBLOCK
>
> > For 1, this is attempting to protect physical attack. Obviously this
> > particular problem ca
> For 1, this is attempting to protect physical attack. Obviously this
> particular problem can't be solved in isolation, but it's something to think
> about.
But isn't this something that per-file hashing would probably make
easier to protect against, not harder? I mean, right now we just hash
On Tue, Jan 22, 2019 at 6:21 PM Julius Werner wrote:
> > FWIW, it's my opinion I think we'll need to start splitting cbfs into
> smaller ones. This isn't specific to this situation, but splitting slots
> into multiple cbfses (rw-a-1, rw-a-2, etc) allows one to chain/group
> resources as they
> There's a trycount that I think defaults to 10. After 10 failing tries it
> should switch slots. There's also a 'set good firmware' notion which signals
> to the firmware one was able to boot. This is picked up on the next reboot
> and the information is passed through vboot non volatile
On Tue, Jan 22, 2019 at 6:45 AM Arthur Heymans wrote:
> Hi
>
> As more and more x86 platforms are moving to C_ENVIRONMENT_BOOTBLOCK
> and therefore don't use a romcc compiled bootblock anymore a certain
> question arises. With the romcc bootblock there was a normal/fallback
> mechanism.
>
> It
9 matches
Mail list logo
