Messages in this thread | | | Date | Tue, 7 Feb 2023 07:03:04 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: Linux guest kernel threat model for Confidential Computing |
| |
On Mon, Feb 06, 2023 at 06:27:48PM -0600, Carlos Bilbao wrote: > On 1/25/23 6:28 AM, Reshetova, Elena wrote: > > 2) One of the described in the above doc mitigations is "hardening of the enabled > > code". What we mean by this, as well as techniques that are being used are > > described in this document: > https://intel.github.io/ccc-linux-guest-hardening-docs/tdx-guest-hardening.html > > Regarding driver hardening, does anyone have a better filtering idea? > > The current solution assumes the kernel command line is trusted and cannot > avoid the __init() functions that waste memory.
That is two different things (command line trust and __init() functions), so I do not understand the relationship at all here. Please explain it better.
Also, why would an __init() function waste memory? Memory usage isn't an issue here, right?
> I don't know if the > __exit() routines of the filtered devices are called, but it doesn't sound > much better to allocate memory and free it right after.
What device has a __exit() function? Drivers have module init/exit functions but they should do nothing but register themselves with the relevant busses and they are only loaded if the device is found in the system.
And what exactly is incorrect about allocating memory and then freeing it when not needed?
So again, I don't understand the question, sorry.
thanks,
greg k-h
| |