> On Nov 13, 2023, at 10:44 PM, Elliott Mitchell <ehem+open...@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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
