From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oRZRO-0003Gq-87 for mharc-grub-devel@gnu.org; Fri, 26 Aug 2022 09:32:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oRZRL-0003CE-0h for grub-devel@gnu.org; Fri, 26 Aug 2022 09:32:03 -0400 Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]:39773) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oRZRI-0005tv-1h for grub-devel@gnu.org; Fri, 26 Aug 2022 09:32:02 -0400 Received: by mail-pl1-x62e.google.com with SMTP id d12so1594549plr.6 for ; Fri, 26 Aug 2022 06:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc; bh=4EALdifcBJaA4BoS9dkBoUwjxEFdajsPvM+t7pQbbhI=; b=dzyTaJ9I9qaP+thKRQKSFFzGx3JNI6tZyXm9Q6pTtfL7Rmx8XGpv2kaOETlqyidPsD 6kKZ9d8Kwc05L6lx9eB7A0wuJLnTQaJPcHYgi5/2b8Ng4GnQQ2HlBLLQQHIekxIR5LTJ Pl8iZZdGItPRlvlMqpyE4m06AWQ8VpXbyJ3CM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc; bh=4EALdifcBJaA4BoS9dkBoUwjxEFdajsPvM+t7pQbbhI=; b=NSKSUbCurGHDVDoEZ+4vrqLJ7D6xAaJVobwyf0J3alIgVt/tw88uNaZh2m5j3tYF8U nIZVa3d8lVIi8Z7JkCfShHNxg0V4Kp5ptzbNEraLyrQ94/0lEbxAqcMZF2u5R0xE2ijB SvteHrR8KyyqNfD6WFuV7v9bkIyMsC+9aAQH2SN/l6zzJsEU74vtBL3ke5xp4VFyLQ7b hWSySdlIT/hOy4aGSD3uri4BXiiU1ObUnEKcEOiN4/RV3TwhXei+JU61FONnWtdOy7Nf 04Q0V46jtjza2OclfNjXeTqFZ1VR/BjYtBFgSV4T3Qc67CXZPJQtot1v7ZUeJ/YlVFAv GxcQ== X-Gm-Message-State: ACgBeo0R89MTU7W7ac0UNEaM3y16juNR2n59kifssDlUmjQBpAoZLRfn +iSprrJC4hUMMxDJ1UPu3qWnFd1T82ii+Q== X-Google-Smtp-Source: AA6agR6aeIX3xuxULvf7jBIzLOAcMFubFIxXFr+CBpGnYRKZxNUcXQWiHoAsv9WQx5O6bUcW9fHldg== X-Received: by 2002:a17:90b:38c8:b0:1fb:af8a:e47 with SMTP id nn8-20020a17090b38c800b001fbaf8a0e47mr4385143pjb.148.1661520716703; Fri, 26 Aug 2022 06:31:56 -0700 (PDT) Received: from localhost ([2001:4479:e300:5b00:bda0:df81:b93d:3679]) by smtp.gmail.com with ESMTPSA id p186-20020a62d0c3000000b005367c28fd32sm1712008pfg.185.2022.08.26.06.31.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Aug 2022 06:31:56 -0700 (PDT) From: Daniel Axtens To: John Paul Adrian Glaubitz Cc: The development of GNU GRUB Subject: Re: [PATCH] Remove HFS support In-Reply-To: <181a0e9e-cf1c-a11f-e30f-2b14093462ad@physik.fu-berlin.de> References: <20220819135755.vpfkmfyvysmdbzov@tomti.i.net-space.pl> <0F68F479-0EC8-4BF8-B21D-81B5FC725226@physik.fu-berlin.de> <871qtbowcj.fsf@dja-thinkpad.axtens.net> <181a0e9e-cf1c-a11f-e30f-2b14093462ad@physik.fu-berlin.de> Date: Fri, 26 Aug 2022 23:31:52 +1000 Message-ID: <871qt3uo53.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::62e; envelope-from=dja@axtens.net; helo=mail-pl1-x62e.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: Fri, 26 Aug 2022 13:32:04 -0000 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