From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oP7vn-0003mQ-CT for mharc-grub-devel@gnu.org; Fri, 19 Aug 2022 15:45:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45080) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oP7vl-0003m8-QX for grub-devel@gnu.org; Fri, 19 Aug 2022 15:45:22 -0400 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]:36429) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oP7vi-0000i0-7h for grub-devel@gnu.org; Fri, 19 Aug 2022 15:45:20 -0400 Received: by mail-ej1-x635.google.com with SMTP id fy5so10674162ejc.3 for ; Fri, 19 Aug 2022 12:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc; bh=FlABMhIPc/89t0ysNb6V05t72yPnL/bVBP/1hk/jqWY=; b=ED0WTYUsJ3Si/UyhsCaKh4Iy2fg3WSCWz8iC3zFlRFk0fx3GOqtdePW2WZXB3BXykt cmhvY1yjVXbjt9j1zlMyDLkLWVdLPs4wxpNXm8XxOXmoAD6DYO444WzLp+Tall2NHkMJ 1EYDp6Fv8MX9sn7vsinI3VD+uOKVln0fjnlPencdOi4T9pV8f8cRIi/Ji6qWSQAmRo/k Nx/bAPOfeKXrRSFhHqk/5Shpb+sAi6LjocFACSO5jR2ugNzjZbkMK38SBOc/D6c716Te 0eFNfobS3HqJwhMOeWf+s2s4Dp5x2Fd9vc1pREXlJY8XGu61t8dVZUiUyj/456bphxxh HAAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc; bh=FlABMhIPc/89t0ysNb6V05t72yPnL/bVBP/1hk/jqWY=; b=qYpuctHhKhPDKqvSbWeHabnVgsB+zZSpvwTRHQUJH7p//nZuZvBQ1pKYc9GXhhWwe6 U0u5VpV6ibLCahMyeqCqpa5I8f4UNpU/PboJ6sTaWhOooZaRSkETpg0Q1Lt2KGoV2Z5M /rORo2SAyZunf3L9fCkHXelTWf1Vbm3tQ/ZZjCtUD356d5KmKbDYixsWGhW065pBf7Jg svbL0RNMTBev75g1+xrXIjrlX+/xKmplhZSi4kSPWuQkag0hpv+Ed5GjWcAfb/Joy7qA iCp0sNS7hdBPTYYeBXF7zImIalr2kJuWw7/kfo+42wfYDB/hGGOxd10h/xktpswcjAS3 WI+g== X-Gm-Message-State: ACgBeo29YlPdPacSc5s/UzmfujyJdds2mD3dV9aZs+qUGVENIBXdZdxw u46xuFKneJtQcibdhKgYNOV6CvfiK92DCaIKazuRxxnpyxWDLQ== X-Google-Smtp-Source: AA6agR4HvVK9e2wzDJQ//H8QlEWI/WUdIS+UaDOpHxSjLRmYKPpCCt1RSILA5Uh9FH2QO3L6/o4UlySh71oATBzuGdQ= X-Received: by 2002:a17:906:9b16:b0:73d:478c:b480 with SMTP id eo22-20020a1709069b1600b0073d478cb480mr2339094ejc.63.1660938316110; Fri, 19 Aug 2022 12:45:16 -0700 (PDT) MIME-Version: 1.0 References: <20220819135755.vpfkmfyvysmdbzov@tomti.i.net-space.pl> <0F68F479-0EC8-4BF8-B21D-81B5FC725226@physik.fu-berlin.de> <20220819180916.GG2668594@tack.einval.com> In-Reply-To: From: "Vladimir 'phcoder' Serbinenko" Date: Fri, 19 Aug 2022 21:45:07 +0200 Message-ID: Subject: Re: [PATCH] Remove HFS support To: The development of GNU GRUB Content-Type: multipart/alternative; boundary="000000000000535f7705e69d56f0" Received-SPF: pass client-ip=2a00:1450:4864:20::635; envelope-from=phcoder@gmail.com; helo=mail-ej1-x635.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2022 19:45:22 -0000 --000000000000535f7705e69d56f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le ven. 19 ao=C3=BBt 2022, 21:05, Dimitri John Ledkov < dimitri.ledkov@canonical.com> a =C3=A9crit : > There is no need for that code on any signed grubs or upstream. Ports tha= t > 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 packag= e. > 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 bootloader= s > (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, < > 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 >> 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=E2=80=99re still formatting our /boot partitions for Debian PowerP= C for >> >> PowerMacs using HFS, so this change would be a breaking change for >> >> us. >> >> >> >> So, that would be a no from Debian=E2=80=99s 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 > --000000000000535f7705e69d56f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le ven. 19 ao=C3=BBt 2022, 21:05, Dimitri John Ledkov = <dimitri.ledkov@canonica= l.com> a =C3=A9crit=C2=A0:
<= div dir=3D"auto">There is no need for that code on any signed grubs or upst= ream. Ports that want to support this patch can have it conditionally compi= led / 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 s= ource 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 i= s a separate level of protection that prevents replacing arbitrary bootload= ers (whilst potentially allow downgrade/upgrade attacks). Thus a responsibl= e upstream should drop this code.

This kind of consideration was tak= en into account when designing security system and even when GRUB2 itself w= as 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 inf= rastructure can handle it.



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 wr= ote:
>>> On Aug 19, 2022, at 3:59 PM, Daniel Kiper <dkip= er@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 Sept= ember.
>>
>> We=E2=80=99re still formatting our /boot partitions for Debian Pow= erPC for
>> PowerMacs using HFS, so this change would be a breaking change for=
>> us.
>>
>> So, that would be a no from Debian=E2=80=99s 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 Deb= ian
> 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

--
=C2=A0 .''`.=C2=A0 John Paul Adrian Glaubitz
: :' :=C2=A0 Debian Developer
`. `'=C2=A0 =C2=A0Physicist
=C2=A0 =C2=A0`-=C2=A0 =C2=A0 GPG: 62FF 8A75 84E0 2956 9546=C2=A0 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/g= rub-devel
--000000000000535f7705e69d56f0--