Re: [PATCH] Remove HFS support
On Fri, Aug 19, 2022 at 11:38:26PM +1000, Daniel Axtens wrote:
> HFS is so so very old now. According to Wikipedia, HFS was
> introduced in 1985 and the successor HFS+ came out in January
> 1998. Mac OS dropped support for writing HFS in 2009 and dropped
> support for reading HFS in 2019 with macOS 10.15.
>
> Grub's support for it doesn't survive contact with a fuzzer, and
> the issues involve some horrible mess of mutual recursion that
> would be time-consuming to sort out.
>
> HFS has been disabled under lockdown since commit 1c15848838d9
> ("fs/hfs: Disable under lockdown") which was part of an earlier
> spin of security fixes.
>
> I think it's time to consign HFS to the dustbin of history. It's
> firmly in the category of retrocomputing at this stage.
>
> This should not affect HFS+.
>
> There's a little bit of mess remaining: the macbless runtime
> command and HFS+ need the HFS headers for embedded volume support.
> I don't think that's really deployed any more, as it would have
> been part of the HFS->HFS+ transition, but I'm not really game to
> mess with either, in particular as macbless writes(!) to disk live.
> (I'm fairly sure the grub-macbless tool invokes code from the
> macbless module as well.)
>
> Signed-off-by: Daniel Axtens
Reviewed-by: Daniel Kiper
Daniel, thank you for preparing this patch!
If I do not hear any major objections in the following weeks I will
merge this patch or a variant of it in the second half of September.
> ---
>
> `make check` is unchanged except for not running the hfs test any more.
> However,
> I don't have any macs set up to boot linux with HFS+, so I can't say much
> more for
> certain. If anyone can check grub-macbless in particular that would be
> wonderful.
Yeah, that would be prefect. Any volunteers?
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
> On Aug 19, 2022, at 3:59 PM, Daniel Kiper wrote:
>
> On Fri, Aug 19, 2022 at 11:38:26PM +1000, Daniel Axtens wrote:
>> HFS is so so very old now. According to Wikipedia, HFS was
>> introduced in 1985 and the successor HFS+ came out in January
>> 1998. Mac OS dropped support for writing HFS in 2009 and dropped
>> support for reading HFS in 2019 with macOS 10.15.
>>
>> Grub's support for it doesn't survive contact with a fuzzer, and
>> the issues involve some horrible mess of mutual recursion that
>> would be time-consuming to sort out.
>>
>> HFS has been disabled under lockdown since commit 1c15848838d9
>> ("fs/hfs: Disable under lockdown") which was part of an earlier
>> spin of security fixes.
>>
>> I think it's time to consign HFS to the dustbin of history. It's
>> firmly in the category of retrocomputing at this stage.
>>
>> This should not affect HFS+.
>>
>> There's a little bit of mess remaining: the macbless runtime
>> command and HFS+ need the HFS headers for embedded volume support.
>> I don't think that's really deployed any more, as it would have
>> been part of the HFS->HFS+ transition, but I'm not really game to
>> mess with either, in particular as macbless writes(!) to disk live.
>> (I'm fairly sure the grub-macbless tool invokes code from the
>> macbless module as well.)
>>
>> Signed-off-by: Daniel Axtens
>
> Reviewed-by: Daniel Kiper
>
> Daniel, thank you for preparing this patch!
>
> If I do not hear any major objections in the following weeks I will
> merge this patch or a variant of it in the second half of September.
We’re still formatting our /boot partitions for Debian PowerPC for PowerMacs
using HFS, so this change would be a breaking change for us.
So, that would be a no from Debian’s side.
Adrian
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
No go from me either. Older macs may not be able to read HFS+ /boot. Also
HFS+ presents couple of problems the biggest one is that in case of sudden
reboot HFS+ often needs to be mounted by OSX or cleaning dirty flag
manually before it becomes writeable.
Le ven. 19 août 2022, 16:05, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> a écrit :
>
>
> > On Aug 19, 2022, at 3:59 PM, Daniel Kiper wrote:
> >
> > On Fri, Aug 19, 2022 at 11:38:26PM +1000, Daniel Axtens wrote:
> >> HFS is so so very old now. According to Wikipedia, HFS was
> >> introduced in 1985 and the successor HFS+ came out in January
> >> 1998. Mac OS dropped support for writing HFS in 2009 and dropped
> >> support for reading HFS in 2019 with macOS 10.15.
> >>
> >> Grub's support for it doesn't survive contact with a fuzzer, and
> >> the issues involve some horrible mess of mutual recursion that
> >> would be time-consuming to sort out.
> >>
> >> HFS has been disabled under lockdown since commit 1c15848838d9
> >> ("fs/hfs: Disable under lockdown") which was part of an earlier
> >> spin of security fixes.
> >>
> >> I think it's time to consign HFS to the dustbin of history. It's
> >> firmly in the category of retrocomputing at this stage.
> >>
> >> This should not affect HFS+.
> >>
> >> There's a little bit of mess remaining: the macbless runtime
> >> command and HFS+ need the HFS headers for embedded volume support.
> >> I don't think that's really deployed any more, as it would have
> >> been part of the HFS->HFS+ transition, but I'm not really game to
> >> mess with either, in particular as macbless writes(!) to disk live.
> >> (I'm fairly sure the grub-macbless tool invokes code from the
> >> macbless module as well.)
> >>
> >> Signed-off-by: Daniel Axtens
> >
> > Reviewed-by: Daniel Kiper
> >
> > Daniel, thank you for preparing this patch!
> >
> > If I do not hear any major objections in the following weeks I will
> > merge this patch or a variant of it in the second half of September.
>
> We’re still formatting our /boot partitions for Debian PowerPC for
> PowerMacs using HFS, so this change would be a breaking change for us.
>
> So, that would be a no from Debian’s side.
>
> Adrian
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz wrote: >> On Aug 19, 2022, at 3:59 PM, Daniel Kiper wrote: >> >> If I do not hear any major objections in the following weeks I will >> merge this patch or a variant of it in the second half of September. > >We’re still formatting our /boot partitions for Debian PowerPC for >PowerMacs using HFS, so this change would be a breaking change for >us. > >So, that would be a no from Debian’s side. Not so fast please, Adrian. At the risk of sounding harsh, non-release old ports like powerpc *really* don't get to dictate things in Debian terms. As Daniel Axtens has been finding out, the HFS code is terrible in terms of security. If you still need it for old/semi-dead machines, maybe you should fork an older grub release and stay with that? -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
On 8/19/22 20:09, Steve McIntyre wrote: On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz wrote: On Aug 19, 2022, at 3:59 PM, Daniel Kiper wrote: If I do not hear any major objections in the following weeks I will merge this patch or a variant of it in the second half of September. We’re still formatting our /boot partitions for Debian PowerPC for PowerMacs using HFS, so this change would be a breaking change for us. So, that would be a no from Debian’s side. Not so fast please, Adrian. At the risk of sounding harsh, non-release old ports like powerpc *really* don't get to dictate things in Debian terms. Add "Ports" to this. As Daniel Axtens has been finding out, the HFS code is terrible in terms of security. If you still need it for old/semi-dead machines, maybe you should fork an older grub release and stay with that? I don't know what should be the deal with the security of a boot loader to be honest. If someone has access to your hardware so they can control your bootloader, you have much worse problems anyway. Forking is also a terrible idea as every forked package means having to track it manually. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
Le ven. 19 août 2022, 20:11, Steve McIntyre a écrit : > On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz wrote: > >> On Aug 19, 2022, at 3:59 PM, Daniel Kiper wrote: > >> > >> If I do not hear any major objections in the following weeks I will > >> merge this patch or a variant of it in the second half of September. > > > >We’re still formatting our /boot partitions for Debian PowerPC for > >PowerMacs using HFS, so this change would be a breaking change for > >us. > > > >So, that would be a no from Debian’s side. > > Not so fast please, Adrian. At the risk of sounding harsh, non-release > old ports like powerpc *really* don't get to dictate things in Debian > terms. > But booting old machines is still desirable for GRUB. Is there a reason why HFS is actively bad for modern machines? Especially if it's disabled in case of lockdown. Can I have more details about your security concerns? I may consider rewriting parts of HFS code to improve it. > > As Daniel Axtens has been finding out, the HFS code is terrible in > terms of security. If you still need it for old/semi-dead machines, > maybe you should fork an older grub release and stay with that? > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > Getting a SCSI chain working is perfectly simple if you remember that > there > must be exactly three terminations: one on one end of the cable, one on > the > far end, and the goat, terminated over the SCSI chain with a > silver-handled > knife whilst burning *black* candles. --- Anthony DeBoer > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
There is no need for that code on any signed grubs or upstream. Ports that want to support this patch can have it conditionally compiled / enabled only on that arch, but not other. For example, in Ubuntu we already use separate builds for signed & unsigned bootloaders. Or one may keep grub-2.06 as separate source package. It's not like those old platforms need any new features in the bootloader ever again. The issue of insecure code is for signed bootloaders. Because there is a separate level of protection that prevents replacing arbitrary bootloaders (whilst potentially allow downgrade/upgrade attacks). Thus a responsible upstream should drop this code. On Fri, 19 Aug 2022, 20:39 John Paul Adrian Glaubitz, < glaub...@physik.fu-berlin.de> wrote: > On 8/19/22 20:09, Steve McIntyre wrote: > > On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz > wrote: > >>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper wrote: > >>> > >>> If I do not hear any major objections in the following weeks I will > >>> merge this patch or a variant of it in the second half of September. > >> > >> We’re still formatting our /boot partitions for Debian PowerPC for > >> PowerMacs using HFS, so this change would be a breaking change for > >> us. > >> > >> So, that would be a no from Debian’s side. > > > > Not so fast please, Adrian. At the risk of sounding harsh, non-release > > old ports like powerpc *really* don't get to dictate things in Debian > > terms. > > Add "Ports" to this. > > > As Daniel Axtens has been finding out, the HFS code is terrible in > > terms of security. If you still need it for old/semi-dead machines, > > maybe you should fork an older grub release and stay with that? > > I don't know what should be the deal with the security of a boot loader > to be honest. If someone has access to your hardware so they can control > your bootloader, you have much worse problems anyway. > > Forking is also a terrible idea as every forked package means having to > track it manually. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist >`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
Le ven. 19 août 2022, 21:05, Dimitri John Ledkov < dimitri.led...@canonical.com> a écrit : > There is no need for that code on any signed grubs or upstream. Ports that > want to support this patch can have it conditionally compiled / enabled > only on that arch, but not other. > > For example, in Ubuntu we already use separate builds for signed & > unsigned bootloaders. Or one may keep grub-2.06 as separate source package. > It's not like those old platforms need any new features in the bootloader > ever again. > > The issue of insecure code is for signed bootloaders. Because there is a > separate level of protection that prevents replacing arbitrary bootloaders > (whilst potentially allow downgrade/upgrade attacks). Thus a responsible > upstream should drop this code. > This kind of consideration was taken into account when designing security system and even when GRUB2 itself was designed. The solution is modules whitelist. There are many modules that can be dropped from signed build not just filesystems but also commands or loaders. There is no need to cut old systems from new grub if existing infrastructure can handle it. > On Fri, 19 Aug 2022, 20:39 John Paul Adrian Glaubitz, < > glaub...@physik.fu-berlin.de> wrote: > >> On 8/19/22 20:09, Steve McIntyre wrote: >> > On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz >> wrote: >> >>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper >> wrote: >> >>> >> >>> If I do not hear any major objections in the following weeks I will >> >>> merge this patch or a variant of it in the second half of September. >> >> >> >> We’re still formatting our /boot partitions for Debian PowerPC for >> >> PowerMacs using HFS, so this change would be a breaking change for >> >> us. >> >> >> >> So, that would be a no from Debian’s side. >> > >> > Not so fast please, Adrian. At the risk of sounding harsh, non-release >> > old ports like powerpc *really* don't get to dictate things in Debian >> > terms. >> >> Add "Ports" to this. >> >> > As Daniel Axtens has been finding out, the HFS code is terrible in >> > terms of security. If you still need it for old/semi-dead machines, >> > maybe you should fork an older grub release and stay with that? >> >> I don't know what should be the deal with the security of a boot loader >> to be honest. If someone has access to your hardware so they can control >> your bootloader, you have much worse problems anyway. >> >> Forking is also a terrible idea as every forked package means having to >> track it manually. >> >> Adrian >> >> -- >> .''`. John Paul Adrian Glaubitz >> : :' : Debian Developer >> `. `' Physicist >>`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >> >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
John Paul Adrian Glaubitz writes:
>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper wrote:
>>
>> On Fri, Aug 19, 2022 at 11:38:26PM +1000, Daniel Axtens wrote:
>>> HFS is so so very old now. According to Wikipedia, HFS was
>>> introduced in 1985 and the successor HFS+ came out in January
>>> 1998. Mac OS dropped support for writing HFS in 2009 and dropped
>>> support for reading HFS in 2019 with macOS 10.15.
>>>
>>> Grub's support for it doesn't survive contact with a fuzzer, and
>>> the issues involve some horrible mess of mutual recursion that
>>> would be time-consuming to sort out.
>>>
>>> HFS has been disabled under lockdown since commit 1c15848838d9
>>> ("fs/hfs: Disable under lockdown") which was part of an earlier
>>> spin of security fixes.
>>>
>>> I think it's time to consign HFS to the dustbin of history. It's
>>> firmly in the category of retrocomputing at this stage.
>>>
>>> This should not affect HFS+.
>>>
>>> There's a little bit of mess remaining: the macbless runtime
>>> command and HFS+ need the HFS headers for embedded volume support.
>>> I don't think that's really deployed any more, as it would have
>>> been part of the HFS->HFS+ transition, but I'm not really game to
>>> mess with either, in particular as macbless writes(!) to disk live.
>>> (I'm fairly sure the grub-macbless tool invokes code from the
>>> macbless module as well.)
>>>
>>> Signed-off-by: Daniel Axtens
>>
>> Reviewed-by: Daniel Kiper
>>
>> Daniel, thank you for preparing this patch!
>>
>> If I do not hear any major objections in the following weeks I will
>> merge this patch or a variant of it in the second half of September.
>
> We’re still formatting our /boot partitions for Debian PowerPC for PowerMacs
> using HFS, so this change would be a breaking change for us.
>
Really, plain HFS, not HFS+? Wowsers!
Just to be clear, by PowerMacs you mean Macs with PowerPC chips, so
machines last produced around 2006?
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.
Anyway, if I've understood correctly, the _most recent_ PowerMacs date
from around 16 years ago, and potentially the machines broken by this
would be even older. I still think that's in the domain of
retrocomputing and I don't understand the use case for running modern
software on something where the performance per watt is worse than a
recent raspberry pi.
Kind regards,
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
"Vladimir 'phcoder' Serbinenko" writes: > Le ven. 19 août 2022, 21:05, Dimitri John Ledkov < > dimitri.led...@canonical.com> a écrit : > >> There is no need for that code on any signed grubs or upstream. Ports that >> want to support this patch can have it conditionally compiled / enabled >> only on that arch, but not other. >> >> For example, in Ubuntu we already use separate builds for signed & >> unsigned bootloaders. Or one may keep grub-2.06 as separate source package. >> It's not like those old platforms need any new features in the bootloader >> ever again. >> >> The issue of insecure code is for signed bootloaders. Because there is a >> separate level of protection that prevents replacing arbitrary bootloaders >> (whilst potentially allow downgrade/upgrade attacks). Thus a responsible >> upstream should drop this code. >> > > This kind of consideration was taken into account when designing security > system and even when GRUB2 itself was designed. The solution is modules > whitelist. There are many modules that can be dropped from signed build not > just filesystems but also commands or loaders. There is no need to cut old > systems from new grub if existing infrastructure can handle it. At least one grub binary signed as part of the UEFI shim process contains the HFS code. (I'm not involved in the process that signs off on what should be permitted in a signed grub.) Fortunately, the patch I wrote earlier to disable HFS in lockdown should be sufficient to protect the users of that binary. That binary comes from one of the larger software companies in the world, and passed the shim signing process. If they got a shim signed that trusts a grub with HFS built in, I'm not sure we can really trust a module whitelist as a good way to protect end users. You ask in your other email what my concerns with the HFS code are and how it could be fixed. The HFS code crashes when fuzz tested: that is, you can construct a number of HFS images such that `grub-fstest hfs.img ls '(loop0)/'` crashes. (There is public information on fuzzing grub now, and that information is sufficient to reproduce the crashes I've found. I can also provide sample crashing inputs.) It would be really nice if the file systems in grub could survive malicious input, even if ideally they would not be built into a signed grub binary. Kind regards, Daniel > > >> On Fri, 19 Aug 2022, 20:39 John Paul Adrian Glaubitz, < >> glaub...@physik.fu-berlin.de> wrote: >> >>> On 8/19/22 20:09, Steve McIntyre wrote: >>> > On Fri, Aug 19, 2022 at 04:03:38PM +0200, John Paul Adrian Glaubitz >>> wrote: >>> >>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper >>> wrote: >>> >>> >>> >>> If I do not hear any major objections in the following weeks I will >>> >>> merge this patch or a variant of it in the second half of September. >>> >> >>> >> We’re still formatting our /boot partitions for Debian PowerPC for >>> >> PowerMacs using HFS, so this change would be a breaking change for >>> >> us. >>> >> >>> >> So, that would be a no from Debian’s side. >>> > >>> > Not so fast please, Adrian. At the risk of sounding harsh, non-release >>> > old ports like powerpc *really* don't get to dictate things in Debian >>> > terms. >>> >>> Add "Ports" to this. >>> >>> > As Daniel Axtens has been finding out, the HFS code is terrible in >>> > terms of security. If you still need it for old/semi-dead machines, >>> > maybe you should fork an older grub release and stay with that? >>> >>> I don't know what should be the deal with the security of a boot loader >>> to be honest. If someone has access to your hardware so they can control >>> your bootloader, you have much worse problems anyway. >>> >>> Forking is also a terrible idea as every forked package means having to >>> track it manually. >>> >>> Adrian >>> >>> -- >>> .''`. John Paul Adrian Glaubitz >>> : :' : Debian Developer >>> `. `' Physicist >>>`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >>> >>> >>> ___ >>> Grub-devel mailing list >>> Grub-devel@gnu.org >>> https://lists.gnu.org/mailman/listinfo/grub-devel >>> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
>> As Daniel Axtens has been finding out, the HFS code is terrible in >> terms of security. If you still need it for old/semi-dead machines, >> maybe you should fork an older grub release and stay with that? > > I don't know what should be the deal with the security of a boot loader > to be honest. If someone has access to your hardware so they can control > your bootloader, you have much worse problems anyway. > > Forking is also a terrible idea as every forked package means having to > track it manually. Not to engage in the Debian specific parts of this, but fwiw the threat model isn't hardware access. Firmware-enforced secure boot (e.g. UEFI, AIX and Linux on PowerVM, whatever modern macs do) basically goes: - assume an attacker gets root on a running system - prevent the attacker from compromising the kernel On Linux this takes 2 parts: some form of signing grub that gets validated by firmware, and lockdown mode once Linux is booted. Now I haven't really used a PowerMac since I was a kid, but if memory serves, they had no concept of this. If you got access to Mac OS (or if you got root on linux), there is no way to protect the kernel. There is, in effect, no security boundary between root and the kernel. Kind regards, Daniel > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist >`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
"Vladimir 'phcoder' Serbinenko" writes: > No go from me either. Older macs may not be able to read HFS+ /boot. Also > HFS+ presents couple of problems the biggest one is that in case of sudden > reboot HFS+ often needs to be mounted by OSX or cleaning dirty flag > manually before it becomes writeable. I don't understand what you mean about the HFS+ dirtying issue. Aren't grub's accesses to the file-system read-only anyway? I'd really genuinely like to know how old a mac has to be not to support booting from HFS+, a filesystem that came out around 1998, ~24 years ago. I'd also like to know what use people have for running modern grub on a machine that old. Kind regards, Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
Hello! On 8/19/22 21:04, Dimitri John Ledkov wrote: There is no need for that code on any signed grubs or upstream. Ports that want to support this patch can have it conditionally compiled / enabled only on that arch, but not other. That's not how open source works. Individual projects do not get to determine what upstream software supports and what not. And that goes both ways. For example, in Ubuntu we already use separate builds for signed & unsigned bootloaders. Or one may keep grub-2.06 as separate source package. It's not like those old platforms need any new features in the bootloader ever again. That's not the point. Packages are constantly rebuild in Debian for various reasons and having to maintain the package manually in Debian is quite annoying. Forcing older ports to use forks of upstream projects is an "elegant" way to kill of these ports as the maintenance burn gets too high. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
Hi Vladimir! On 8/19/22 21:45, Vladimir 'phcoder' Serbinenko wrote: This kind of consideration was taken into account when designing security system and even when GRUB2 itself was designed. The solution is modules whitelist. There are many modules that can be dropped from signed build not just filesystems but also commands or loaders. There is no need to cut old systems from new grub if existing infrastructure can handle it. Thank you! I don't understand why maintainers concerned with security can't just do that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
On 8/20/22 15:53, Daniel Axtens wrote: Really, plain HFS, not HFS+? Wowsers! Yes, we're currently using HFS. Just to be clear, by PowerMacs you mean Macs with PowerPC chips, so machines last produced around 2006? Yes. 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. Anyway, if I've understood correctly, the _most recent_ PowerMacs date from around 16 years ago, and potentially the machines broken by this would be even older. I still think that's in the domain of retrocomputing and I don't understand the use case for running modern software on something where the performance per watt is worse than a recent raspberry pi. 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 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. FWIW, Gentoo also still uses HFS for booting PowerMacs [2]. Adrian [1] https://popcon.debian.org/ [2] https://wiki.gentoo.org/wiki/GRUB_on_Open_Firmware_(PowerPC) -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
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. 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. 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. (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.) >> 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. 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 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. Kind regards, Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
Hi Vladimir! On 8/19/22 21:01, Vladimir 'phcoder' Serbinenko wrote: But booting old machines is still desirable for GRUB. Is there a reason why HFS is actively bad for modern machines? Especially if it's disabled in case of lockdown. Can I have more details about your security concerns? I may consider rewriting parts of HFS code to improve it. FWIW, in case you would be really interested on improving the HFS code, it should be no problem to collect some funds in the PowerPC community to financially support that task, e.g. through a Bountysource campaign. We have done this in the past to support similar projects in GCC and LLVM. What do you think? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
Le ven. 26 août 2022, 15:47, Daniel Axtens 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 prevent
Re: [PATCH] Remove HFS support
Le ven. 26 août 2022, 17:46, John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> a écrit : > Hi Vladimir! > > On 8/19/22 21:01, Vladimir 'phcoder' Serbinenko wrote: > > But booting old machines is still desirable for GRUB. Is there a reason > why > > HFS is actively bad for modern machines? Especially if it's disabled in > case > > of lockdown. > > > > Can I have more details about your security concerns? I may consider > rewriting > > parts of HFS code to improve it. > > FWIW, in case you would be really interested on improving the HFS code, it > should > be no problem to collect some funds in the PowerPC community to > financially support > that task, e.g. through a Bountysource campaign. > > We have done this in the past to support similar projects in GCC and LLVM. > > What do you think? > I have checked HFS code in general and it looks pretty neat safe for few bugs like cache collision. If I can get these fuses I can probably fix them. I'm currently on weekend and my laptop has died but I can have a look using my phone + VPS > > Thanks, > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist >`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
Daniel Axtens writes: >>> 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. As the person currently responsible for the Red Hat tree: I am also not happy about this state of affairs. If a use case is to be supported, someone needs to actually do the leg work to support it. Bug reports are all well and good, but if no one's actually able to fix them, they're just making a pile that's in the way. What I mean is this: right now the project has people (you) *testing* power macs, but no one actually *fixing* power macs, and unless someone starts fixing problems that materialize, it's at odds with reality to call it a supported platform. (And to be clear here, problems that materialize includes other people's patches, and debugging/sending fixes to them as would be expected from a subject matter expert.) As you point out downthread, I could go out and spend money on a vintage mac almost as old as I am to attempt to debug the problem myself. (This money would have to be my own, because Red Hat, RHEL, and Fedora are all uninterested in supporting power macs.) I would then have to learn the ins and outs of a platform that the manufacturer has not supported for about fifteen years.[1] We're talking about at least a month of my time, probably more, and that assumes it even reproduces on my machine - which there's no guarantee of. (If I did all that, and it didn't, what then?) It's time I don't have, and quite frankly it's more important to me to have grub support currently shipping hardware. Or I could just take the POWER patches from Daniel and IBM folks downstream, and keep a platform that customers care about working. This takes very little of my time in comparison, but fails to heal the current divergence. Be well, --Robbie 1: Having grown up with these beige boxes, I did previously owned an iBook G3 on which I did run Linux - but have not in this decade (as it is far from a capable computing platform in the modern era), nor would I have been able to debug it at the time. I do still use the AEK & AEK II as daily drivers, though. signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
On 8/30/22 18:37, Robbie Harwood wrote: As the person currently responsible for the Red Hat tree: I am also not happy about this state of affairs. I don't want to sound rude, but GRUB isn't a RedHat-only project, it's a community project. So, while I understand RH's point of view, I would also like to ask you to see other people's perspectives. If a use case is to be supported, someone needs to actually do the leg work to support it. Bug reports are all well and good, but if no one's actually able to fix them, they're just making a pile that's in the way. Vladimir has asked multiple times for bug reports on the issues and he said, he would fix them. I also offered that we do a crowd-funding campaign to fund the development. I would be happy to throw in some money as well. So, if we could get some report on what needs to be addressed, that would be great. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
"Vladimir 'phcoder' Serbinenko" writes: > Le ven. 26 août 2022, 15:47, Daniel Axtens 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 signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
John Paul Adrian Glaubitz writes: > On 8/30/22 18:37, Robbie Harwood wrote: > >> As the person currently responsible for the Red Hat tree: I am also >> not happy about this state of affairs. > > I don't want to sound rude, but GRUB isn't a RedHat-only project, it's a > community project. Nowhere in my post did I say I was speaking for grub - the tag at the top literally says that my post is intended as the Red Hat tree maintainer. I'm not an upstream maintainer and it is not reasonable to presume that I speak for grub, or that my views represent those of the project. > So, while I understand RH's point of view, I would also like to ask > you to see other people's perspectives. If you're going to make claims like this, you need to actually engage with what others are saying. Seeing someone else's perspective doesn't mean you think they're right: it means you're trying to engage with their viewpoint in order to reach consensus. I do not see engagement with my viewpoint from you, and meanwhile I'm trying to engage with yours. >> If a use case is to be supported, someone needs to actually do the >> leg work to support it. Bug reports are all well and good, but if no >> one's actually able to fix them, they're just making a pile that's in >> the way. > > Vladimir has asked multiple times for bug reports on the issues and he > said, he would fix them. I also offered that we do a crowd-funding > campaign to fund the development. I would be happy to throw in some > money as well. That's nice of you to offer, but you should know that those of us already employed full-time in software will likely be unable to receive those funds. It is also not the same thing as having that work get done. For my part, I reviewed the original POWER patch and am happy to review changes to make it powermac compatible. > So, if we could get some report on what needs to be addressed, that would > be great. I think I was pretty clear about this in the part of my message that you trimmed out, but I'll reiterate just in case: the series Daniel Axtens and I are talking about is "powerpc-ieee1275: support larger core.elf images" on which you provided feedback on 2021-11-23. Daniel Axtens last asked you on-list for additional debugging information on 2022-05-17, to which you have not replied. Daniel also indicated in that post that they are likely at the limit of their ability to debug the failure regardless. Be well, --Robbie signature.asc Description: PGP signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Remove HFS support
"Vladimir 'phcoder' Serbinenko" writes: > Le ven. 26 août 2022, 15:47, Daniel Axtens 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. ext and fat file systems (and several other more obsure file systems) and all our image parsers reach this standard, best as I can tell. As far as I can tell the grub IPv4 networking stack does too, although I am not as certain that my coverage was very thorough. Several of us are actively working to get all of grub to this standard. grub is a lot simpler than Chrome, so I am optimistic. >> 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 The following two files cause crashes on stock grub-fstest stack overflow (unbounded recursion): files.intermittent.network/grub/hfs.stack-overflow stack buffer overflow -> eventual segv: files.intermittent.network/grub/hfs.stack-buffer-overflow There are an additional set of files that cause crashes when grub is compiled with ASAN: files.intermittent.network/grub/hfs.tar.xz (18MB, 210MB uncompressed) There are 222 files. The corpus is not de-duplicated (there are not 222 unique bugs) and includes the two files called out above, plus other some different heap buffer overflows. I compile grub with ASAN using: ASAN_OPTIONS=detect_leaks=0 make CFLAGS="-fsanitize=address" -j8 Modern gcc works fine. grub-emu will fail to link, but grub-fstest should build fine. In all cases, the crashes reproduce with: ./grub-fstest ls '(loop0)/' Good luck, the stack-overflow one in particular looks especially painful. I will leave your other points for others to address. Kind regards, Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
