Re: [PATCH] Remove HFS support

[Robbie Harwood <rharwood@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3759 bytes --]

"Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com> writes:

> Le ven. 26 août 2022, 15:47, Daniel Axtens <dja@axtens.net> a écrit :
>
>> Let me answer this out of order.
>>
>>> I understand the need to sometimes get rid of old code, but since
>>> the HFS module can be blacklisted as Vladimir explains, I don't
>>> really understand the reasoning in this particular case.
>>
>> I want _all_ grub code to reach a minimum standard of not crashing or
>> corrupting memory in the presence of malicious input. HFS does not
>> reach that standard.
>
> That is a very high standard. Products with a huge security team like
> Chrome don't reach this standard.

That's not accurate.  See
https://bughunters.google.com/about/rules/5745167867576320/chrome-vulnerability-reward-program-rules
(the important parts of which are that Google not only pays out for
fuzzing crashes but provides infrastructure to run your fuzzers on).

>> Whether or not the HFS module could be omitted from a signed binary
>> doesn't really bear on the fact that there are bugs in the code, the
>> presence of bugs has been publicly known for over 18 months (see commit
>> 1c15848838d9) and no-one has shown any intention of fixing the bugs.
>
> That is besides the point of using GRUB on PowerMac or any other
> platform with unsigned bootchain. And for signed bootchains it can be
> blacklisted in the code like it already is. Which problem do you try
> to solve?

Every time there's a CVE found in the project, it reflects poorly on the
project.  I think we both know that that's not really fair - CVEs just
mean the project is being looked at, and are not a measure of quality -
but we're talking about a public perception issue here.  If a project
knows that there are potential security problems in an area of its code,
and not only doesn't take steps to address them but instead actively
resists doing so, it will be assumed to be an unhealthy project - and
rightly so, I think.

>> (And as I said in another email, HFS has in fact been built in to a
>> signed binary recently. Module-based protection is great in theory
>> but this example demonstrates that it falls down in practice.)
>
> Then implement a better module-based security with security attributes
> stored in a special section of the binary how we do with the license
> to allow only EFISB-approved modules to load under lockdown

It is incumbent on those who want HFS support to, you know, work at
supporting HFS.  Telling other people to do it instead does not further
that goal - it just pushes them away.

> It's fine to commit patches that improve for other PPC without waiting for
> PowerMacs. In fact I have often seen benefits from such moves.

Sure, but it is bad practice to commit patches that are known to break a
platform (which is what we're talking about here) without some plan to
handle that going forward.  Specifically, I imagine Daniel Axtens and I
would be happy if the "powerpc-ieee1275: support larger core.elf images"
series landed as-is, but I doubt Adrian would be.

>> This not the first time we find ourselves in this situation either.  For
>> example, RH is carrying the 'powerpc-ieee1275: support larger core.elf
>> images' series out of tree because they need it to boot on modern Power
>> boxes. It broke on your machine in a way no-one else has reproduced, and
>> I last emailled you asking for more information to debug the failure in
>> May.
>
> This can happen with EFI as well. And indeed have. Several times. Should we
> drop EFI support?

That's not how this works, or has worked.  Those who care about EFI work
with maintainers and patch authors to keep their use case operational.

Be well,
--Robbie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]