From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oPP6W-00005T-9B for mharc-grub-devel@gnu.org; Sat, 20 Aug 2022 10:05:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56842) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oPP6R-000054-SZ for grub-devel@gnu.org; Sat, 20 Aug 2022 10:05:31 -0400 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]:35445) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oPP6P-0002FS-Re for grub-devel@gnu.org; Sat, 20 Aug 2022 10:05:31 -0400 Received: by mail-pj1-x102f.google.com with SMTP id m10-20020a17090a730a00b001fa986fd8eeso10011465pjk.0 for ; Sat, 20 Aug 2022 07:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:to:from:from:to:cc; bh=+c5VzH3TYrqh8QCujMS4kTaNKPhRdB+wA5jqE26CgLk=; b=cfpTjpWV6by8NQuAwjE2Lhj0gpc6tnhwvMgtwSYnlKe9a7EMhDjlwj/nh6pz/gSe0v 1DUhJN6PI3g4B6KlewM9WzRoHPnJTTYXx3RoT+d8rTjBxvcmOCkOpeFcbbPXuesOhZIg i1RAQHeuWQFpmlOi7yLlgtERB9a5RDuCvu1qE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:to:from:x-gm-message-state:from:to:cc; bh=+c5VzH3TYrqh8QCujMS4kTaNKPhRdB+wA5jqE26CgLk=; b=hrRmy1WT9U84FKshrKeiwns2zd64SPyH0zXZnuniOUX4RWcZ3lWqKXtmLl3m6q39kw nRp2neZl07kDSW1CBGCuPNF25mDDFDNXCwVgsEuwLjUlFRoOrfRqTzqADumBRLmDFw8A ZxiLQmC3KcTY7wfdLrwTiuwx+5FaqpW4pTdWJvkUs5qvYxvN9FeZs4jMZKtbAFX3h0Lu yrPKYJxnOs82wNe6WGhwxPLlOOp90zXJMPi37zQ21aC/+HlPZ1fPJxOcM/Gln2b+5kGj ca67igBxWJ++5qDGMuEWSRvsfAbrj1gWpyeH1yv8ld4VxHHwqG9RNSVP5fP6eHHjlFjr E2lA== X-Gm-Message-State: ACgBeo2PIaZwmYzmhmx7aQOUBEwLEdKFbVnffVxjLjcFEGWxj9/eowii sff++4mELw/Mre98vBKEdUZhWQ== X-Google-Smtp-Source: AA6agR5s1O9Wp1JriAOtCfiFpHh7fL4JMPELs2e6JFbNRhjeQHfCLSpwhbIjrI02kVK2b92JWsLA/w== X-Received: by 2002:a17:90a:6308:b0:1fa:b280:7a45 with SMTP id e8-20020a17090a630800b001fab2807a45mr19678036pjj.159.1661004328154; Sat, 20 Aug 2022 07:05:28 -0700 (PDT) Received: from localhost ([2001:4479:e300:5b00:c85d:e7b9:8f13:8764]) by smtp.gmail.com with ESMTPSA id p4-20020a1709026b8400b001729da53673sm5028066plk.14.2022.08.20.07.05.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 20 Aug 2022 07:05:27 -0700 (PDT) From: Daniel Axtens To: Vladimir 'phcoder' Serbinenko , The development of GNU GRUB Subject: Re: [PATCH] Remove HFS support In-Reply-To: References: <20220819135755.vpfkmfyvysmdbzov@tomti.i.net-space.pl> <0F68F479-0EC8-4BF8-B21D-81B5FC725226@physik.fu-berlin.de> <20220819180916.GG2668594@tack.einval.com> Date: Sun, 21 Aug 2022 00:05:24 +1000 Message-ID: <87y1vjnh7f.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::102f; envelope-from=dja@axtens.net; helo=mail-pj1-x102f.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, 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: Sat, 20 Aug 2022 14:05:32 -0000 "Vladimir 'phcoder' Serbinenko" writes: > 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 th= at >> 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 packa= ge. >> 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 bootloade= rs >> (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 n= ot > 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 >>> 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 Power= PC 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 >> > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel