Re: [PATCH] Remove HFS support

[Daniel Axtens]

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

> Le ven. 19 août 2022, 21:05, Dimitri John Ledkov <
> dimitri.ledkov@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, <
>> glaubitz@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 <dkiper@net-space.pl>
>>> 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