From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-4.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 045782E087; Wed, 17 Aug 2022 07:53:07 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 312672DF62; Wed, 17 Aug 2022 07:53:04 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by atuin.qyliss.net (Postfix) with ESMTPS id 070E32DF61 for ; Wed, 17 Aug 2022 07:52:59 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D6C705C010D; Wed, 17 Aug 2022 03:52:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 17 Aug 2022 03:52:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1660722777; x=1660809177; bh=CTxXPoKK1l 9OkBxvE+s0e41jnqozR4kGMGrK3oyi+Fc=; b=lHvUBgfpOazCNbfksN/4rO/IRV E8fogHqv+GG7L4g+D2S2JXu6RAiKlF1Xx+cr+bGdVQU6WCcoOj5KLOA8MXXVlvCE pf4dIhd+6xevV+v05HaIRIEjQ8C6SAhChy3NSIKmx5PxcXdB7k+wdi42X7YSDGSC v4mEN2Skd9e94i+6sXi5a8ByyGNEMKkP0F01GgPL/+szCHWwTMJhBEYmCUe3QZDS rduIqCe6K6doaUEKfZdK6oVqpTLab3T8zEjLqJlqDXMtkp2JK25G0/4KUVvA/PgS EIvQugQqDIccsC2+jPzdMrV5lDsD/KF2aACenFo7QdWtKhOcpzQkKLa+pTDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1660722777; x=1660809177; bh=CTxXPoKK1l9OkBxvE+s0e41jnqoz R4kGMGrK3oyi+Fc=; b=X6d8wdc9T4vnGZWHjKD1hJDBErW0qa8L7jJ22xB8fMWe 0qiJVkPRVcqHuFp/yvrYR+gpXo1OAr072iQCu3Qnjb+NSxOjMRfPGSd5j2H9eIaC 0DcCoqXTtNrLzgyrmk3km/bRfhczGW1jQRimsT8RrxKcKIe5L0nLOS8L64n6O9U4 IWCF6oH0IMEz8un+xuxdu5TrOia3gcf3WUuAxigQ3yyHdWx1kfLpESi/X9wWwnno KreG2iP1u0bvWFY/Zq6S/IfQLk31O+FoY3LQxEjhBkh3j/zyI2D1xd3LRNk0WPjs FvsQK/jCQ3oVqc2KDoJPrX9ap+qSwboEu2zZXwwSIQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehhedguddvjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeetlhih shhsrgcutfhoshhsuceohhhisegrlhihshhsrgdrihhsqeenucggtffrrghtthgvrhhnpe elveehhefgteetleffledutefhgfevvdduieegtdetgfeivefgheefuedvueekudenucff ohhmrghinheprghnughrohhiugdrtghomhdplhifnhdrnhgvthdpshhpvggtthhruhhmqd hoshdrohhrghdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepqhihlhhishhssegvvhgvrdhqhihlihhsshdrnhgvth X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 17 Aug 2022 03:52:57 -0400 (EDT) Received: by eve.qyliss.net (Postfix, from userid 1000) id 85D2243F; Wed, 17 Aug 2022 07:52:55 +0000 (UTC) Date: Wed, 17 Aug 2022 07:52:55 +0000 From: Alyssa Ross To: Ville Ilvonen Subject: Re: HW identification and configuration on Spectrum Message-ID: <20220817075255.wjw24mzuyyl3lhgz@eve> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tdx5dvgh5ppxc4ib" Content-Disposition: inline In-Reply-To: Message-ID-Hash: GEEL4YYGCBD62MBIITAP3HRIJGC42GDF X-Message-ID-Hash: GEEL4YYGCBD62MBIITAP3HRIJGC42GDF X-MailFrom: qyliss@eve.qyliss.net X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-discuss.spectrum-os.org-0; header-match-discuss.spectrum-os.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: discuss@spectrum-os.org X-Mailman-Version: 3.3.5 Precedence: list List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --tdx5dvgh5ppxc4ib Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 16, 2022 at 06:50:48PM +0300, Ville Ilvonen wrote: > Hi, > > Now that we've been developing Spectrum ARM (aarch64) support > with iMX8 boards, I'd like to get back to Spectrum HW configuration desig= n. > > On x86 the generic image with kernel supporting most devices as modules c= an > make sense. On ARM, the vendor specific BSP HW quirks are more common. What impact will Google's Generic Kernel Image[1] efforts have on this? As I understand it, going forward Android devices won't be allowed to make arbitrary kernel changes, and will be restricted to adding extra modules. Which presumably means that SOCs aiming to be used for Android devices will have to work with the standard Android kernel, which is hopefully getting closer to mainline over time[2]. Regardless, I understand that there will always be some cases where a non-upstream kernel is a necessity (even if the Android situation gets better, there will always be a new MacBook that doesn't have upstream drivers yet!) so I am keen to figure out how to support that well in Spectrum. [1]: https://source.android.com/docs/core/architecture/kernel/generic-kerne= l-image [2]: https://lwn.net/Articles/830979/ > As of now, the spectrum fork for aarch64 just adds another config > after rpi configs > and replaces the default config to use that to build. With small > changes this could > be handled like rpi configs. In addition, cloud-hypervisor accepts > kernel only in > EFI format for aarch64[1]. Anyway, this would allow us to build an > aarch64 Spectrum installer > - even make it with a more generic kernel. That takes us to ARM > vendor/device specific HW > quirks which would need to be handled anyway. I'll intentionally leave > device specific > kernel hardening and disabling kernel module loading for security > reasons for now. > As of now the vendor/device specifics are not supported unless one builds= device > specific Spectrum image with all configs build-time and skips > installer altogether. > > The other option that I see. We discussed earlier nix-hardware and > device specific modules. > That would bring nixos configuration.nix and installation supporting > scripts to Spectrum, > though. Those could be called from the Spectrum installer but it would > change the installer > logic from writing an image to dynamically configuring the device > during install based on user > selections. I don't think the full NixOS module system, with rebuilds, etc. belongs in Spectrum. Being able to treat images as immutable makes it easier to provide various strong security guarantees. But not wanting to integrate the full module system doesn't prevent us taking advantage of nixos-hardware. It's possible to evaluate NixOS modules standalone in a Spectrum build, in fact we already do that to reuse NixOS's list of all redistributable firmware packages[3]. We could do a similar thing to extract the kernel that nixos-hardware configures for a particular device, something like this: inherit (nixos { configuration =3D [ ]; }.config.boot.kernelPackages) kernel; And naturally which device that's pulling from should be configurable =E2= =80=94 we'll want to have a config file somewhere, just not a full NixOS one. In the medium term, I'd like to decouple nixos-hardware's custom kernel packages from NixOS configurations. But that would require somebody finding the time to sit down and make the change, and also convince other nixos-hardware users that it's the way to go. I don't think it would be a problem though, especially if it meant nixos-hardware getting more active maintenance, which it's lacking at the moment because it's not too well advertised and so not enough people are using it. I am intrigued by the idea of the installer being able to generate images, though. Using Nix with a substituter configured on the installer image would mean that it could download a pre-built image if one exists for that platform, or fall back to generating one if not. (And if there was a pre-built image, it would even still be able to properly Secure Boot with a trusted key once we're in a position to do that.) So I'm definitely keen on exploring that idea, but it might be something to do a bit down the road since the work to generate board-specific Spectrum images wouldn't be contingent on it. [3]: https://spectrum-os.org/git/spectrum/tree/host/rootfs/default.nix?id= =3Db01594b2c089ce2434dacddccf9a285af7334d24#n64 > Any thoughts which would be the preferred way? Maybe some other way? > In the end, HW specifics are needed also on x86 as we saw with NUCs > and different > Lenovo laptops in the spring. I'm not convinced one image to rule them > all is realistic or secure. The issues we saw with Lenovo laptops, etc. wouldn't have been solved by device specific images =E2=80=94 those devices were broken because of bugs = that hadn't affected any other systems I'd tried, but in the end the fixes were applicable everywhere. That itself isn't an indication that we need device-specific images, just more hardware testing. But as I said above, I'm open to having an officially blessed configuration mechanism to make it possible to build custom images. > Finally, this is by no means blocking the hardened iMX8 based Spectrum > development > but will keep that work in Spectrum fork until there's an agreed path > to implement this. > Integrating this sooner and making it more generic would make Spectrum > more useful > for a wider audience. Makes sense =E2=80=94 although of course, if any of the work that's been do= ne so far is not i.MX8-specific, but is instead just generic stuff to make Spectrum more ARM-friendly or cross-compilable, I'd be happy to look at those patches already since they'll be relevant regardless of how we do device-specific stuff. > Best regards, > > -Ville > > [1] https://github.com/tiiuae/spectrum/pull/3#issuecomment-1211834302 --tdx5dvgh5ppxc4ib Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmL8nlAACgkQ+dvtSFmy ccC3Qg//WbeQ8t/JMCzPm2Mi2Dk1SnwOnE1DML7sSiTqhzzIR6qI5wbYeJm5BAbM svqZ21wNZHhMNf1cI2hClyiwxGZIfntUo/HEmiKUivT/Tr4FCJaq7Q09FZX3zk78 t0h9Ft/MjC4rBgDnMQntvEHe9VIvaOhTataX+NPPygl9F89uhDFEXC6UpauIEyrS I1ILTW+NNb7TWwbw/R6fe3AV/uTSOfNTxTWQp54VZeN204B22K8hKra+e2X/tWah gjupYupQbTaK4QhPu1PrnrpoBiu3Rb1PE8gUCNDBLTJIBP20emAo7XKfs4gIns3U 318+N40tC4kq6Bi/am/kno07Up/NDoaBGG2fsLw3pT/4xQWptEpkk9QMrGPfdylC BIPnxXjNQILyHTPXm1eBCd2z2CzTVpie7LMV0qaiYPCn4xIumR9+Kxjk9TSXQmFf yfD2ojOF6u9+MIYB7+Zh8l3wW6H4RmeAjS3iJxeU6MBMpy0QfbnmxeP17BamFOjs d+5OTpy6AXeGe+2c4DCTzLJDwe5ifpDAR127po/Buyrilus4+4NOWp8VNinRHd18 CHFF2Cbor+zvk3Ncv1ZX0TXId5exTZdsrsG9ipkJklXLZy1Yqzsz2l0rQkJYC1i2 XpbXP9BxAvEX1HzOY/ge8bspWMFIc71MMq5H8sh+WsmXwa98E78= =Fve8 -----END PGP SIGNATURE----- --tdx5dvgh5ppxc4ib--