Adding a new x86 image or related packages to the default x86 image

[Philip Prindeville]

> On Nov 13, 2023, at 10:44 PM, Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
> 
> On Tue, Nov 14, 2023 at 03:44:57AM +0000, Daniel Golle wrote:
>> On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote:
>>> On Mon, Nov 13, 2023 at 12:48:14PM +0000, Daniel Golle wrote:
>>>> On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote:
>>>>> 
>>>>> How about we follow the approach of Alpine Linux[1] and offer a standard, an extended and a virtual firmware for the x86/64 target?
>>>>> 
>>>>> What packages specifically is another discussion but the approach could be that standard contains all kmods to get network working on all device, extended includes extra LED drivers etc and virtual only contains network drivers for, well, virtual things.
>>>> 
>>>> +1
>>>> I like that much more than adding board-specific images on a platform
>>>> with standardized boot process (such as x86 or armsr).
>>> 
>>> Are you stating you're planning to modify OpenWRT's boot process to
>>> match the standard way of dealing with that standardized boot process?
>>> Mainly, using a minimal kernel and then using an initial ramdisk to
>>> load device drivers as appropriate to the hardware.
>> 
>> Using squashfs (which is what we are doing) has actually quite
>> a similar effect than using initramfs. Filesystem cache of files which
>> aren't accessed gets freed.
>> 
>> What is missing is hotplug-based loading of kmods based on present
>> devices -- right now every module present gets loaded and remains
>> loaded indefinitely even if the hardware isn't present.
> 
> First, an initial ramdisk allows the kernel to not include any block
> drivers, but instead load them during boot.  ie a VM build could include
> drivers for interacting with every hypervisor, but only load the ones
> for the hypervisor in use.
> 
> Second, while suboptimal having those drivers as modules allows them to
> be unloaded.  If the drivers for every hypervisor were unconditionally
> loaded, the inappropriate ones might be unloaded by /etc/rc.local.
> 
> 
>>> Each hypervisor will have a small set of drivers guaranteed to be
>>> present.  These though will be completely different between hypervisors.
>> 
>> Do you really think having just the (partially shared) drivers for 3
>> hypervisors (KVM/virtio, Hyper-V, VMWare) present in one image is too
>> much? Those drivers are very tiny...
> 
> Permanently built into the kernel?  Not acceptable.


Every once-in-a-while a vulnerable driver is discovered that is a CVE even when it's not active.

Having the modules linked in makes it harder to blacklist their initialization.

-Philip