The Linux Userspace API Group
OEM customization partition #113
Replies: 4 comments 5 replies
-
|
hmm, shouldn't just be some new partition type "oem-sysexts" or so, that we automatically mount somewhere, and then after validation apply all contained sysexts from? |
Beta Was this translation helpful? Give feedback.
-
|
IMO, no. We don't want OEM settings to automatically apply onto a user system. The software running on that system must opt into loading something from the OEM partition. This limits the scope of the influence over the system the OEM has, and gives control to the distro. In other words, I want a proper, well-docunented API for OEMs to put together a customization image. Not a generic "let OEM add files to the OS" mechanism. Especially because with the second one the OEM needs to be a Linux expert to make that work, with the former they can throw files into a folder structure, zip it up, and send it to us for signature. We can even provide templates, to lower the barrier of entry into Linux for OEMs. |
Beta Was this translation helpful? Give feedback.
-
|
The |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it'll work with sysexts. It would be hard to build a sysext generic enough to work across distros (for example, consider NixOS). With a sysext there's no way to define restrictions on what the OEM can and cannot do. I would like to draw an incredibly clear boundary between "this config came from the vendor" vs "this config came from the OEM". Software should be able to decide at runtime if it listens to or ignores OEM settings. And, like any settings, it should be able to decide what settings it exposes to OEMs I understand that sysexts exist to blur the definition of "vendor" when we say that /usr comes from the vendor. But IMO extending that definition to OEMs is too much of a stretch. Fact is if we give them too powerful of a mechanism it'll be used against us. |
Beta Was this translation helpful? Give feedback.
-
|
In the Windows model:
The first person to see any given combination of those is the end user. In the Android world, since the vendor takes the image from Google and ships it to their users themselves, they can guaranteed test the final combination before shipping to the user. The latter model has advantages in terms of stability and user experience. Android (for all its problems) pretty much never has drivers break on updates. Unless I'm mistaken, the model you're suggesting is essentially the Windows model where the two components update separately. |
Beta Was this translation helpful? Give feedback.
-
|
I know I originally mentioned drivers but that kinda goes counter to the no-exec argument. So maybe drivers don't belong in there. I mean you can't even do that, because drivers are linked closely to the kernel version and you can't have a generic image that's kernel-agnostic. I'll write more in drivers in a follow up tomorrow maybe. OEMs can test their customization partition before sending it over for signature. It's just files on disk, there could easily be a tool to bind-mount that over /oem on next boot or something. On the other hand, I don't actually expect OEMs to test anything. Maybe I'm jaded but I've definitely run into big QA failures on my old OnePlus phone. |
Beta Was this translation helpful? Give feedback.
-
|
Re signatures. Maybe I overcomplicated the scheme. Ultimately, the harm an OEM can do by dropping config files into a directory is nonzero, but probably very minimal. Not on the same level of impact as shim, for example. So we probably don't need a shim-review tier of review for these things. So how about this: OEMs could create and sign their own OEM customization images if they want to, or they can let their partner distros do it for them. UAPI group would maintain a a list of trusted public keys for OEMs and distros. Distros can choose to distribute this list, which will allow them to use all the OEM customization partitions in the ecosystem. Kinda like secure boot's wide chain of trust, but with much lower stakes. So for example: let's say Lenovo makes laptops with Fedora. They want to ship a customized wallpaper pack, and default the accent color to red to match their brand. One option: Lenovo has their own keypair that they maintain. They generate the customization image, test it, sign it, and put it on their device. They apply to get their public key added to the UAPI-group's list, and since it's coming from Lenovo it's allowed. All the distros start trusting that key. So, all the distros can mount Fedora's image. Second option: Lenovo doesn't want to deal with it, so they don't. They ask Fedora to do it. So Fedora makes the image and signs it. Everything else is similar: Fedora gets their key added to the list, and distros can mount Fedora-approved OEM partitions. |
Beta Was this translation helpful? Give feedback.
-
|
If OEMs would be making and packing their own OEM partitions, there would need to be some way for them to push updates. So either the contents of the partition should self-describe how to update itself. Which is possible, but requires the OEM to not only generate and sign images, but also host them on bespoke infra. Or the distribution should be centralized somewhere. But now it sounds like I'm reinventing the LVFS. Maybe this is something fwupd would be interestes in? Thoughts, @hughsie? |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it's a great fit for the LVFS; we're optimised for <100MB files with ITAR/EAR-compliant geoip controls and we're not really positioned for every machine connected to the LVFS to download huge amounts of data. It sounds like more the kind of thing you want to host on quay.io, no? |
Beta Was this translation helpful? Give feedback.
-
Prior Art
Over in the Windows world, OEMs tend to install Windows, and then do a bunch of work installing drivers, customization, bloatware, etc, before they prep the installation for imaging and then deploy it to all their machines. ChromeOS, too, has an OEM Customization partition. Ships custom backgrounds, shortcuts to websites, and so on.
Elementary OS, a package-based Linux distro that has had relative success distributing through OEMs, allows OEMs to customize the installations they ship to customers too, including custom extension points in the settings app, custom pre-installed software, etc.
Android seems to be the only major OS that lets the OEM control the entire software stack, including distribution and updates. So different Android "distros" are vastly different from each other, and often extremely insecure.
Plan
Ultimately we want to meet OEMs somewhere in the middle. They should be able to customize our atomic distributions, in ways like:
Without giving them free reign to include GTK themes, shell extensions, bloatware, etc. that will negatively impact the user experience.
Solution
We can have a standardized "OEM Customization" partition type as part of the DPS. Automatically mounted to /oem (my preferred location), or /usr/oem, or /usr/share/oem (ChromeOS's preferred location) by systemd-gpt-auto-generator. These wouldn't be architecture-specific partition types, because we would not allow OEMs to ship executable binary data (no way to verify it, plus no way to make it work cross-distro). Mounted noexec, readonly, nosetuid, etc.
If an OEM wants to ship a customization partition with some distro preinstalled, they can send the file structure over to the distribution they're partnering with (i.e. in a zip file or tarball). The distribution will unpack the files, inspect them, and if satisfactory create a squashfs/erofs partition, dm-verity hash, and sign the roothash with a key trusted by the distro. Then the three partitions are sent back over to the OEM, who can include them in the default installation (at the end of the disk, so a system admin can delete the OEM partition and grow their data partition). The distro, meanwhile, can redistribute these images to ship updates, restore them in the event of a clean install, etc.
In a perfect world, we would actually have some shared cross-distro infrastructure for this. The "satisfactory" check would depend mostly on whether or not the content is malicious or broken in some way, and reviews would be staffed by representatives of lots of distros (similar to shim-review) and possibly upstream projects ("namespaces", as used below). The cross-distro group would be responsible for distributing updates to the OEM partition and each individual distro would be responsible to deploy them somehow (using a sysupdate component is probably the right thing to do on the distro's side, but not all distros use systemd)
Individual distros remain in control even with a cross-distro group providing signatures. First of all, distros are free to configure their software to ignore the /oem directory - so if some distro has no interest in respecting the OEM's wallpapers they can configure their software to ignore
/oem/backgrounds. Second, the cross-distro group would sign the images in such a way that distros get to choose which subset they want to trust, for example with a root cert that signs a per-OEM cert that signs a per-model cert. The distro can choose to trust the root cert, but if they've had trouble with an OEM in the past they can exclude that one OEM. Alternatively, distros can choose to only mount the OEM partitions of OEMs they have their own agreements with. Ultimately the system administrator also gets to make these decisions by including/excluding certificates in /etc. If a signature verification fails on an OEM directory it's just silently not mounted by the OS, and thus /oem is empty, and thus no OEM settings are used.The contents of the partition would look something like this:
/oem/hw-info: a/usr/lib/os-release-esque file that contains information about the OEM and the device model. Device support URLs, warranty checking URL, stuff like that? Also OEM name, logo. Display model name and number. Chassis type. Hardware support EOL date/oem/[namespace]: Per-namespace directories. Each namespace would be its own mini-spec, belonging to some upstream project that looks into /oem to obtain settings. Each namespace would define policies like copyright, upstream-ability, etc, along with the obvious things like the file structure that's found in there and how those settings are used. The uapi-group spec would list all the known namespaces, their purposes, and where to read that individual mini-spec. For example:backgrounds: Namespace containing OEM-defined wallpapers, with some standardized file defining attribution, copyright, light/dark variants, which DEs to show/hide the wallpapers in, etc. The wallpapers here would appear under a section in Settings like "Provided by [OEM]:" or similar.flatpak: Namespace owned by the Flatpak project, containing some sort of configuration of pre-installed apps from Flathub. These would appear as icons in the desktop, but when clicked would install the app on-demand and launch it.appstream: Appstream metadata that allows the OEM to curate software in the various graphical app stores. Would show up as a "Recommended by [OEM]" section in the app store.xdg: Shared cross-desktop standardized things. Default accent color, default light/dark mode. Sound themes. Icon themes. Fonts. Etc.gnome: GNOME-specific customization. Maybe a OEM-curated list of GNOME extensions to recommend, or even pre-install if permissible.kde: Ditto but for KDE. Maybe KDE plugins to auto-install from the plugin store, boot animations, etc?hwdb.d: hwdb entries for working around hardware quirks. OEMs would be encouraged to submit these upstream too, but if they're required to make certain hardware work on older systemd versions they'll stick around. Eventually they can be dropped once most distros are on a new-enough systemd. Explicitly, the cross-distro group would be allowed to modify these definitions however they want without approval of the OEM to fix issues with it.locale: configuration for default language and keyboard layout (via systemd-localed?)firmware: firmware blobs that can't make it into /usr/lib/firmware for some reason? (probably legal issues involved here, maybe best not to touch it)tuned: tuned power profiles for the machine?Beta Was this translation helpful? Give feedback.
All reactions