From: Alyssa Ross <hi@alyssa.is>
To: Ville Ilvonen <ville.ilvonen@unikie.com>
Cc: discuss@spectrum-os.org
Subject: Re: HW identification and configuration on Spectrum
Date: Wed, 17 Aug 2022 07:52:55 +0000 [thread overview]
Message-ID: <20220817075255.wjw24mzuyyl3lhgz@eve> (raw)
In-Reply-To: <CAP-nJwHTmROzMbyYNtrTrOdXGV-iJvwPuJ3FSZb3gLy5R3z80Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6042 bytes --]
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 design.
>
> On x86 the generic image with kernel supporting most devices as modules can
> 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-kernel-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 = [ <nixos-hardware/pine64/pinebook-pro/default.nix> ];
}.config.boot.kernelPackages) kernel;
And naturally which device that's pulling from should be configurable —
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=b01594b2c089ce2434dacddccf9a285af7334d24#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 — 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 — although of course, if any of the work that's been done 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-08-17 7:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-16 15:50 Ville Ilvonen
2022-08-17 7:52 ` Alyssa Ross [this message]
2022-08-17 13:25 ` Ville Ilvonen
2022-08-17 13:39 ` Alyssa Ross
2022-08-18 9:15 ` Ville Ilvonen
2022-08-18 10:17 ` Development on the Spectrum host Alyssa Ross
2022-08-19 6:26 ` Ville Ilvonen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220817075255.wjw24mzuyyl3lhgz@eve \
--to=hi@alyssa.is \
--cc=discuss@spectrum-os.org \
--cc=ville.ilvonen@unikie.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).