From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oT5yt-00027h-H0 for mharc-grub-devel@gnu.org; Tue, 30 Aug 2022 14:28:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55690) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oT5yr-00027I-Jp for grub-devel@gnu.org; Tue, 30 Aug 2022 14:28:57 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:20795) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oT5yn-0002ii-Eo for grub-devel@gnu.org; Tue, 30 Aug 2022 14:28:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661884132; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KYZRHwUMNPq2EQw9Z6EXqLltuSaT0BWIKecnmjVZAbw=; b=jDc8ZMykYrdjvnE3Woh0RYd/2+Im9nQ6/cMlGV8b+R+ep/Nikpkf+c+63gk4kXXcFVwDtw Cg9dU2guyo7AWNH+CB93pWS5JqdvRsvy4BqjKGT/fo1nxomzPnOp5cVsZfzd7diSsAKM1x WJYNIV/LRZzFaw7XwtvEPJbaqkSQ5Rw= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-519-cDL5MqiYP8i81ypHYfuLpg-1; Tue, 30 Aug 2022 14:28:50 -0400 X-MC-Unique: cDL5MqiYP8i81ypHYfuLpg-1 Received: by mail-qv1-f71.google.com with SMTP id ll5-20020a056214598500b0049905d71166so3632103qvb.14 for ; Tue, 30 Aug 2022 11:28:50 -0700 (PDT) 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:to:from :x-gm-message-state:from:to:cc; bh=KYZRHwUMNPq2EQw9Z6EXqLltuSaT0BWIKecnmjVZAbw=; b=QnC4JfSpPPYG1RJOyLGbpSILWvToRi/06qooNOEhGbD7cofPSSAHdoDbCHLtyqtJ7L VVgy72CkupfUBU8pAhGuovy0q8Jpziy+MSdDp3D2Lm3xB24B5viyJLd2rdKLWbcC6Mu2 Ov/TXfI/+2ouEQVI9l6nAnVLTfDLK8OHD2BWjDBlKFtKVfrpnM86wy3oGxa8MtqkqMtl An86ZVr9YdHlVbfPEmSTXQuihgtU7f7pStNegLd1aAbgU3AnUGhPE97pClVN/mKkq1+W IH1aq3V9N9m7FrTy34xzroJFcdvWlOPSq/dJKV06LPUygP8QW7bCHH41JeMUB9HdoHrH 5r9A== X-Gm-Message-State: ACgBeo37DMs0xFDRywUHx9xYOir/U8XLtxuTyxpT63qEk5V4VGg2IA8v u8bTCj8MiXb8ZngXcLm86QwZr/jmrkuERvUBqqI3To1nKlba1Ceo+d1zsiWcvM18ooo4DvhO/z5 qFZSyV2FBKqM= X-Received: by 2002:a05:6214:5299:b0:47e:89e9:e27b with SMTP id kj25-20020a056214529900b0047e89e9e27bmr16487143qvb.52.1661884129800; Tue, 30 Aug 2022 11:28:49 -0700 (PDT) X-Google-Smtp-Source: AA6agR6JPbWbLzsLncY6TpD0JLz+3G1hcGEGxYr3QvoLuxKPGsnJxYP4VP7dC2u7rvthUPsmZG9h8A== X-Received: by 2002:a05:6214:5299:b0:47e:89e9:e27b with SMTP id kj25-20020a056214529900b0047e89e9e27bmr16487126qvb.52.1661884129464; Tue, 30 Aug 2022 11:28:49 -0700 (PDT) Received: from localhost (pool-96-237-164-50.bstnma.fios.verizon.net. [96.237.164.50]) by smtp.gmail.com with ESMTPSA id v7-20020a05620a0f0700b006b5d9a1d326sm9024901qkl.83.2022.08.30.11.28.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Aug 2022 11:28:49 -0700 (PDT) From: Robbie Harwood 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> <871qtbowcj.fsf@dja-thinkpad.axtens.net> <181a0e9e-cf1c-a11f-e30f-2b14093462ad@physik.fu-berlin.de> <871qt3uo53.fsf@dja-thinkpad.axtens.net> Date: Tue, 30 Aug 2022 14:28:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=170.10.129.124; envelope-from=rharwood@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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: Tue, 30 Aug 2022 18:28:57 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "Vladimir 'phcoder' Serbinenko" writes: > Le ven. 26 ao=C3=BBt 2022, 15:47, Daniel Axtens a =C3=A9= 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-vulnerabi= lity-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, =2D-Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJIBAEBCgAyFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAmMOVt4UHHJoYXJ3b29k QHJlZGhhdC5jb20ACgkQJTL5F2qVpEL5mg/+JiXjiTAE8Vqd6u/6P9qCmqaYh3o8 G1prHq98ySDBwWUm0dzlM0d/mepKovHZ/qa9zMe239nC2shskeNOeyDDfbC/vrpm oLCRvoez13Y3Ar0UDdv5zYyNozK3bZ9OosCgoGDzFYscF2R2+JtZeM/RMZ++PlmP 6t+YCKJNAI+y22iC0XF1F1zZapUkgZneXfTobWJ+auWj0WKDcv+mFYX9RnbA791b PLQB4EYCNhZjEiaoMDApP4qlaxh6iDCsjdfKfQ2vR1UVndR61x7IJ9Av1V/Uf47M EtLs3nYUQSCp4b3nJdBbYX3lV1u3ozrdIk7hqKZuTX89245VPibwI6Ld8cRaOAho MmTHX/NQGLzkuywDgjBoOzZwuFvntqgdlu6OOSYCGb06aBOmbdfcxqgvSlqStNix tk4glT2uy8kDA4sG7AEFAt1jpjf7PsOpvERV/xtpSnkO7dbS0ZJ1MHx366yQHW20 MbT6jqSrnVrvn5gxa02V8FLnC/Tlc3/L7s/ir95T/b2eKicM3TZpDbeKHz0faHUp UD725TcVK/BiEVEhh/sseEC4MRQwvwoiiVN4ARB+iwhLzoNrTYPowzYaHKXos1MT StizhvbTKGGAewcujZ5Ab7HG/PBYpJS9BwCCZz+3hiYkZ0Yga/3D2Xv4GduuvxWB 73ypV/BnrU/oCH8= =XuYs -----END PGP SIGNATURE----- --=-=-=--