Because it does not end with I/O operations, that's a trivial example.
module unloading is famous for being racy: I just re-read that part of
virtio drivers and sure enough we have bugs there, this is after
they have presumably been audited, so a TDX guest is better off
just disabling hot-unplug completely, and hotplug isn't far behind.
Malicious filesystems can exploit many linux systems unless
you take pains to limit what is mounted and how.
Networking devices tend to get into the default namespaces and can
do more or less whatever CAP_NET_ADMIN can.
Etc.
hange in your subsystem here.
Well I commented on the API patch, not the virtio patch.
If it's a way for a driver to say "I am hardened
and audited" then I guess it should at least say so.
How about creating a defconfig that makes sense for TDX then?TDX can be used in many different ways, I don't think a defconfig is
practical.
In theory you could do some Kconfig dependency (at the pain point of having
separate kernel binariees), but why not just do it at run time then if you
maintain the list anyways. That's much easier and saner for everyone. In the
past we usually always ended up with runtime mechanism for similar things
anyways.
Also it turns out that the filter mechanisms are needed for some arch
drivers which are not even configurable, so alone it's probably not enough,
I guess they aren't really needed though right, or you won't try to
filter them?
So make them configurable?