> Let's be frank, even without encryption disabling most drivers - > especially weird ones that poke at hardware before probe - > is far safer than keeping them, but one loses a bunch of features.Usually we don't lose features at all. None of the legacy drivers are needed on a guest (or even a modern native system). It's all just all for old hardware. Maybe in 20+ years it can be all removed, but we can't wait that long.> IOW all this hardening is nice but which security/feature tradeoff > to take it a policy decision, not something kernel should do > imho.There's no mechanism to push this kind of policy to user space. Users don't have control what initcalls run. At the time they execute there isn't even any user space yet. Even if they could somehow control them it's very unlikely they would understand them and make an informed decision. Doing it at build time is not feasible either since we want to run on standard distribution kernels. For modules we have a policy mechanism (prevent udev probing by preventing enumeration), and that is implemented, but only handling modules is not enough. The compiled in drivers have to be handled too, otherwise you have gaping holes in the protection. We don't prevent users manually loading modules that might probe, but that is a policy decision that users actually sensibly make in user space. Also I changing this single call really that bad? It's not that we changing anything drastic here, just give the low level subsystem a better hint about the intention. If you don't like the function name, could make it an argument instead? -Andi>
Michael S. Tsirkin
2021-Aug-29 22:26 UTC
[PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}
On Sun, Aug 29, 2021 at 09:17:53AM -0700, Andi Kleen wrote:> Also I changing this single call really that bad? It's not that we changing > anything drastic here, just give the low level subsystem a better hint about > the intention. If you don't like the function name, could make it an > argument instead?My point however is that the API should say that the driver has been audited, not that the mapping has been done in some special way. For example the mapping can be in some kind of wrapper, not directly in the driver. However you want the driver validated, not the wrapper. Here's an idea: diff --git a/include/linux/audited.h b/include/linux/audited.h new file mode 100644 index 000000000000..e23fd6ad50db --- /dev/null +++ b/include/linux/audited.h @@ -0,0 +1,3 @@ +#ifndef AUDITED_MODULE +#define AUDITED_MODULE +#endif Now any audited driver must do #include <linux/audited.h> first of all. Implementation-wise it can do any number of things, e.g. if you like then sure you can do: #ifdef AUDITED_MODULE #define pci_ioremap pci_ioremap_shared #else #define pci_ioremap pci_ioremap #endif but you can also thinkably do something like (won't work, but just to give you the idea): #ifdef AUDITED_MODULE #define __init __init #else #define __init #endif or any number of hacks like this. -- MST