From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1p0PdR-0006Xn-6H for mharc-grub-devel@gnu.org; Wed, 30 Nov 2022 11:08:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0PdL-0006VG-MR for grub-devel@gnu.org; Wed, 30 Nov 2022 11:08:28 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0PdJ-0003bj-6s for grub-devel@gnu.org; Wed, 30 Nov 2022 11:08:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669824501; 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=/+MM+5TPHe0tyzqcbZ5sspaqCFYH31X3VmpOloX6Qec=; b=LGLfU4nhb1NfFo9HPf8qFs3al1/lxOat0AAkU5Uo3eRvvO7TRWyRGF0iivYZg2qcm2P4QQ 4LiNvdd5cg9YxUeweRZrJoRuxLEjSegu95jF78hhcZSiWb1/LfKiIBkI/w9L67tYmTCAAT Q+H6wjuRXgAKLlg2bwQRZAWRu3LMa7A= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-90-hKVtZHjPPP6rh1zmE3sAFQ-1; Wed, 30 Nov 2022 11:08:19 -0500 X-MC-Unique: hKVtZHjPPP6rh1zmE3sAFQ-1 Received: by mail-qk1-f199.google.com with SMTP id i21-20020a05620a405500b006fb25ba3e00so39086692qko.1 for ; Wed, 30 Nov 2022 08:08:19 -0800 (PST) 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:subject:date:message-id:reply-to; bh=/+MM+5TPHe0tyzqcbZ5sspaqCFYH31X3VmpOloX6Qec=; b=VYyvblhaeUQ9dzMhCuzsf/4joAB3u+1XAy73gSrXIdeaywdRVWTP6yMw7avA78oM29 TDEexUG49Kqj5QOQn3JklX1vo7xxYV4n/doStEaEbj7qFlrpoyamowab6WgR1xCDmqWB NxBGAWduKtuu56qPksu3b/iJ5FOtNFMNjPjTPuFVFKZAgo+2i5LSKu7kTUdKmwNaxKV+ aZVq2kuu95DTnQ7oM1O9oqVdBFFoMudI1w4v2F0ZzArd9T1ff0ahriooO9Qptfq4rviw qDeVmeY4ZOd8flnN+tlA+Q+1re/c2liiJcYEp59S9AnmM6P4S5sMZv4v+zkulpGtyr83 82qA== X-Gm-Message-State: ANoB5plmArMUK5pUrReIp27dnijWI1ZW4MlWJKdpmoLbdrSRLabgRj9X cpQ4YEEnCjgx7VA60PwlNZPkNtXNb3v4c8hbnF8AvmwWjXYYSsTSY2Fy2vD1UzXT0VfUoINZQye eLOIQzfvJNiM= X-Received: by 2002:ae9:e507:0:b0:6fa:5778:8e with SMTP id w7-20020ae9e507000000b006fa5778008emr56337545qkf.71.1669824498635; Wed, 30 Nov 2022 08:08:18 -0800 (PST) X-Google-Smtp-Source: AA0mqf5Fq8mnH2jdYWj39mWCOI3BC5b0OVNPK86h2ui6saGfdm0/r7klZqRj4oi1maqrgquDCwQCCA== X-Received: by 2002:ae9:e507:0:b0:6fa:5778:8e with SMTP id w7-20020ae9e507000000b006fa5778008emr56337497qkf.71.1669824497995; Wed, 30 Nov 2022 08:08:17 -0800 (PST) Received: from localhost ([2600:4040:520a:8800:7d1c:f0a7:5c44:ed0e]) by smtp.gmail.com with ESMTPSA id s3-20020ac85283000000b003a4cda52c95sm1030254qtn.63.2022.11.30.08.08.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Nov 2022 08:08:17 -0800 (PST) From: Robbie Harwood To: Zhang Boyang , grub-devel@gnu.org Subject: Re: Fonts and theming and what to do in future with SB In-Reply-To: <51a85758-8d47-6287-7a8e-bc6f82a1f770@gmail.com> References: <20221129183523.GN3245702@tack.einval.com> <51a85758-8d47-6287-7a8e-bc6f82a1f770@gmail.com> Date: Wed, 30 Nov 2022 11:08:14 -0500 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.133.124; envelope-from=rharwood@redhat.com; helo=us-smtp-delivery-124.mimecast.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, 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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: Wed, 30 Nov 2022 16:08:32 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Zhang Boyang writes: > On 2022/11/30 02:35, Steve McIntyre wrote: > >> AFAIK Chris Coulson has a patch for the font loader to cause it to try >> loading fonts from the embedded memdisk first. Is that the best >> approach? If so, what fonts should we be embedding in the signed >> image? It's a tradeoff between size and functionality, of course - >> some people are happy with just "unicode" while others may want a >> wider choice for added theming options. Is the size an issue for most >> people? > > Personally I prefer to embed Unifont to GRUB. This can be done by=20 > memdisk, or embed as code directly (like ASCII chars). For Unifont, this= =20 > will make GRUB about 2.5MB (+150%) fatter. This is sufficient for vast=20 > majority of GRUB usecases. My testing with Chris's patch and approach for unicode.pf2 (in Fedora) adds just under a megabyte - presumably this is due to benefits from xz-compressing it, minus overhead to add the modules required for support to our builds. Is your suggestion that we should officially remove support for other fonts, then? > It's also possible to embed only hashes of font files into GRUB > (although not implemented yet). Therefore, distros can pre-generate a > series of fonts files and add their hashes to GRUB bundle. End-users > can choose their font in the pre-defined list from distros. As you say, someone would have to implement this first :) And if we were to go this route, I think we'd want to do the same for background images. > For those who want to use fonts which not in the pre-defined list. The=20 > last option would be disable secureboot or use MOK to sign their own=20 > GRUB bundle. "Disable secureboot in order to do this" is not a position I ever want to take. In a forced tradeoff between features and security, some users will opt for features. (And it's easier to just disable secureboot than roll out one's own signing, unfortunately.) So my preference is to keep feature parity between SB and non-SB, even if that means dropping customizability. >> Or... Could/should we look at options to sign fonts separately? I've >> heard suggestions to embed them into faked-up modules that we could >> load with insmod, but of course we don't support signing modules yet >> anyway... :-) > > It seems "shim" can process PE files only, so it's hard to implement=20 > signature checking for other files (modules, fonts, etc.). A tradeoff=20 > solution is to wrap PF2 font into a PE file, so they can be processed by= =20 > shim. A better solution would be add more functionality to "shim" to=20 > allow it process more types of files. I don't agree with making shim more complicated. Be well, =2D-Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJIBAEBCgAyFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAmOHf+4UHHJoYXJ3b29k QHJlZGhhdC5jb20ACgkQJTL5F2qVpELYKg/+OyATthcuojNH8eqCYj5WA1N6vNoz imdm3K4irzKD5OtliUTMF5KjhsJHIypK+HLhzIoY93dKrSBIuo1xRxD/9s8z4WFr Ph5uRaFcbik1brit8TU6eLKrwQ3K3OPEQe3YOOmwW0QUeD/I6/Rh7M0bhve5oFRN c3tOhMeq4tpWptGMk+Ad+W4O2ummiufwzBcansAfhlgzg4D0slzwmRg6FtBDmc7C xpiswoJoJChREYnFIMZyKaUrmFo+1/U8YENXAm/e+XKgBS6Izzixo4Mo61zZFrJu /HbTHBRmD5hEV26gaOzPYjXdaNUmlUUwCfIeUV0M2/vzclxKeBIuJu8Fmubo8+Aj ATa0Uv80USAQI/cuE3da+gxsU5fOedM4BAWgeESDBD8ACd9UJdRu2NkaTfyL2PGs FQ8llXxKkN9bWC6PgURGd7qbmeGzjaYmkWfHFETrlmmpzZKJCNKLPHVsqFSAnG1j 9wEub34nsjupZ878Ag1lbEpWmGOFyiI0kFnhIecVkPl8nz2ZnY6PHL0xRfGqUlsE 3E0p5N4RIiy+uKFsIBFO/qs7yAPWCCyx9oL8z120Rz4p9x6rvicYIXzj/s2P0DXr /isRfOd/qXzBrgnTP6eda4XJQZeHKasBKoB7qLDmaR55ieedChkvVWmYJPfcTtHM zg1+fgsQnfdnjNs= =72AV -----END PGP SIGNATURE----- --=-=-=--