Re: [PATCH] Remove HFS support

["Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>]

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

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. It's reasonable that you submit the
improvements. Also it's reasonable for you to blacklist code that gets in
the way of security. E.g. all compressors that are not used should be
blacklisted.

>
> 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?

>
> If you or someone else (someone from Gentoo, perhaps?) want make it fuzz
> clean, then that'd be great. If no-one is able to bring it up to what is
> *not* an especially high standard, then it should be considered
> abandoned by developers and therefore removed.
>
Show me the fuzzes that create problems and I'll improve the code

>
> (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

>
> >> Have you checked that you can't boot them with HFS+? Because HFS+
> >> came in 1998, which was (AFAICT) pretty early on in the G3 lifecycle. So
> >> I'd be really surprised if the firmware didn't support booting from
> >> HFS+. I'd be very keen to hear.
> >
> > I have not tested that due to lack of time. The problem is that some
> early
> > firmware versions might have issues with HFS+ that we haven't verified
> > yet.
>
> Any approach that says 'we must wait for test results for very old macs'
> puts the grub community in a bind. I'm not aware of anyone else stepping
> up to contribute test results on old macs, and I can't go across to an
> apple store and buy one.


Old PowerMacs are available in most countries for under $50 next day. Other
PowerPC machines often cost thousands and you need to wait weeks. So
PowerMacs are important for the entire PPC ecosystem as a whole as it's the
most available platform if you're not employed by someone with a stake in
PPC.
Maintenance is a collaborative effort and it's inevitable that some
platforms

> So in order to test this, the entire grub
> upstream stalls on (AFAICT) you personally.
>
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.

>
> 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?

>
> For me, this is not a desirable, sustainable, or acceptable
> situation. For the project to sustainably support 24 year old macs, we
> need more than the tests you do in your free time.
>
> Finally and in conclusion:
>
> > What's wrong with retrocomputing? Debian's popcon currently reports more
> > machines running the 32-bit big-endian Debian port than the 64-bit little
> > endian port, see [1].
>
> I have no complaint with running _old_ software on old hardware. That's
> a cool hobby and an important part of preserving the history of computing.
>
> My complaint about running _new_ grub on very old hardware is that the
> inaccessibility

The "inaccessible" part is just wrong. They were manufactured in hundreds
of millions and are still the cheapest and most available way to test
software on big-endian machine and for this having an entire stack with
modern software is extremely useful even though there are some limitations
like lack of some graphics APIs

> of said hardware and the lack of a well-resourced
> community or company to do the work are all getting in the way of people
> trying to make grub a modern bootloader, reaching modern security
> standards, for modern systems.
>
Nobody's preventing you from adding blockers from loading undesirable
modules. What is a problem is "I don't need this code, let's kill it"

>
> Kind regards,
> Daniel
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 7913 bytes --]