All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
To: Daniel Axtens <dja@axtens.net>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] Remove HFS support
Date: Fri, 26 Aug 2022 17:27:24 +0200	[thread overview]
Message-ID: <b71718cc-0e5d-5c1c-789b-4fd2b42172a9@physik.fu-berlin.de> (raw)
In-Reply-To: <871qt3uo53.fsf@dja-thinkpad.axtens.net>

On 8/26/22 15:31, Daniel Axtens wrote:
> 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.

I surely understand that although it sounds a little academic to me.

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

Well, I wasn't fully aware of the situation. I am not doing GRUB work
professionally, it's just one of the many projects I sometimes touch.

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

Sometimes code just works as-is that's why people don't complain.

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

Isn't it up to the distributions what they support and what not?

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

Well, I have tested the things you asked me to test. And besides that it didn't
work, I don't that we agreed on something else.

I am not the only one using it on old Macs, it's just me who is on this mailing
list. It's not like everyone using any software in the Linux world is subscribed
to any project's mailing list. I don't understand why some people assume that.

People will just at some point complain that it no longer works when they upgrade
their software running their distributions.

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

Well, GRUB is supposed to be a universal bootloader, isn't it?

> 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 of said hardware and the lack of a well-resourced

I don't think PowerMacs are really that inaccessible, are they? They are
usually easy to buy off eBay and other used hardware platforms.

The problem with removing hardware support is that you are continuously
making it harder to run software on these machines which would otherwise
run fine up to a point where it breaks rendering all the work that people
have poured into keeping these ports working useless.

POWER hardware is usually rather expensive, so PowerMacs are usually the
only kind of PowerPC hardware that most people can afford.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



  parent reply	other threads:[~2022-08-26 15:28 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19 13:38 [PATCH] Remove HFS support Daniel Axtens
2022-08-19 13:57 ` Daniel Kiper
2022-08-19 14:03   ` John Paul Adrian Glaubitz
2022-08-19 17:57     ` Vladimir 'phcoder' Serbinenko
2022-08-20 14:23       ` Daniel Axtens
2022-08-19 18:09     ` Steve McIntyre
2022-08-19 18:38       ` John Paul Adrian Glaubitz
2022-08-19 19:04         ` Dimitri John Ledkov
2022-08-19 19:45           ` Vladimir 'phcoder' Serbinenko
2022-08-20 14:05             ` Daniel Axtens
2022-08-24  7:17             ` John Paul Adrian Glaubitz
2022-08-24  7:16           ` John Paul Adrian Glaubitz
2022-08-20 14:13         ` Daniel Axtens
2022-08-19 19:01       ` Vladimir 'phcoder' Serbinenko
2022-08-26 15:46         ` John Paul Adrian Glaubitz
2022-08-26 17:02           ` Vladimir 'phcoder' Serbinenko
2022-08-20 13:53     ` Daniel Axtens
2022-08-24  7:21       ` John Paul Adrian Glaubitz
2022-08-26 13:31         ` Daniel Axtens
2022-08-26 15:17           ` Vladimir 'phcoder' Serbinenko
2022-08-30 18:28             ` Robbie Harwood
2022-09-01 14:01             ` Daniel Axtens
2022-08-26 15:27           ` John Paul Adrian Glaubitz [this message]
2022-08-30 16:37           ` Robbie Harwood
2022-08-30 17:21             ` John Paul Adrian Glaubitz
2022-08-30 18:43               ` Robbie Harwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b71718cc-0e5d-5c1c-789b-4fd2b42172a9@physik.fu-berlin.de \
    --to=glaubitz@physik.fu-berlin.de \
    --cc=dja@axtens.net \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.