In case it wasn't obvious:
Opinions expressed are solely my own and do not express the views or opinions
of my employer
On Fri, Oct 04, 2024 at 11:53:16AM +0300, Sergii Dmytruk wrote:
> Hi,
>
> On Fri, Oct 04, 2024 at 06:09:19AM +, David Hendricks via coreboot wrote
odwill. I would suggest to let it
> cool down and give some space to all parties so they could resolve
> this situation properly without many heated and unnecessary arguments
> arose.
> Peace.
> Sheng
>
>
> On 4. Oct 2024, at 10:54, Sergii Dmytruk wrote:
>
> Hi,
&g
Hi,
On Fri, Oct 04, 2024 at 06:09:19AM +, David Hendricks via coreboot wrote:
> * This particular issue was not brought to the attention of coreboot
> leadership by anybody at Google or Intel. Someone in coreboot's
> small business ecosystem asked us to look into CB:84356
> (https://re
Hi
I second that. First Nico was banned from flashrom, now from coreboot.
I saw no real basis for the previous decision and see none for this one.
I even thought of him being overly nice in our recent interactions.
In general, he seems to care much more about the projects than many
others and ac
On Fri, Sep 13, 2024 at 02:07:54PM +0200, Nico Huber wrote:
> On 13.09.24 13:51, Nico Huber via coreboot wrote:
> > On 13.09.24 13:07, Nico Huber via coreboot wrote:
> >> So, what I'm suggesting is to just look for an update in a pre-
> >> defined path on the boot medium.
> >
> > Looks like this is
Hi Werner,
On Fri, Sep 06, 2024 at 01:10:54PM +, Zeh, Werner wrote:
> From the implementation point of view it looks a bit tricky to me:
> We do weave two independent projects (coreboot and Tianocore) quite a lot
> together in order to accomplish this task. Though there might be
> justificatio
Hi Krystian, Nico,
On Wed, Aug 14, 2024 at 05:22:54PM +0200, Krystian Hebel wrote:
> > Is fwupd still Linux only? [...]
>
> [...] Yes, AFAICT fwupd is Linux only.
Even the oldest release on GitHub (Feb 3, 2020) has
fwupd-1.3.7-setup-x86_64.exe:
https://github.com/fwupd/fwupd/releases/tag/1.3
Issue #420 has been updated by Sergii Dmytruk.
2 out of 6 subtasks are closed, but really all of them are done by now,
including this one.
Feature #420: Use standard format of TPM event log
https://ticket.coreboot.org/issues/420#change-1888
* Author
Issue #433 has been updated by Sergii Dmytruk.
https://review.coreboot.org/c/coreboot/+/69162 was merged today, so I think
this can be closed.
Feature #433: Unify TPM drivers in coreboot
https://ticket.coreboot.org/issues/433#change-1806
* Author
Issue #421 has been updated by Sergii Dmytruk.
Julius Werner wrote in #note-10:
> I still feel strongly that we shouldn't overcomplicate APIs
It would actually simplify the API by making parameter lists shorter and input
data better grouped.
> increase maintenance burden by i
Issue #421 has been updated by Sergii Dmytruk.
Julius Werner wrote in #note-8:
> are you planning to make a bunch of Kconfigs to select this
vboot2 supports 4 matching hashes, so 4 corresponding options.
> Basically, I understand that the log format *allows* multiple algorithms, and
&g
Issue #421 has been updated by Sergii Dmytruk.
Sergii Dmytruk wrote in #note-5:
> `tpm_extend_pcr()` would be updated for consistency here, but it's not
> strictly necessary.
Correction: `tpm_extend_pcr()` can invoke `tcpa_log_add_table_entry()` in its
body, so it should hav
Issue #421 has been updated by Sergii Dmytruk.
> Can you explain what use case you have that requires you to use multiple
> algorithms?
I'll let Krystian and Michał correct me, but I'm not sure if we have an actual
need for multiple algorithms right away. The API ch
Issue #421 has been updated by Sergii Dmytruk.
If there are no objections, I'll use an API like this instead:
```
struct tpm_digest {
const uint8_t *hash;
size_t len;
enum vb2_hash_algorithm hash_type;
};
/**
* Ask vboot for a digest and extend a TPM PCR wi
14 matches
Mail list logo
