Messages in this thread |  | | Date | Tue, 7 Feb 2023 20:51:56 -0500 | | From | "Theodore Ts'o" <> | | Subject | Re: Linux guest kernel threat model for Confidential Computing |
| |
On Tue, Feb 07, 2023 at 01:53:34PM -0600, Carlos Bilbao wrote: > Currently proposed device filtering does not stop the __init() functions > from these drivers to be called. Whatever memory is allocated by > blacklisted drivers is wasted because those drivers cannot ever be used. > Sure, memory can be allocated and freed as soon as it is no longer needed, > but these memory would never be needed. > > > More pressing concern than wasted memory, which may be unimportant, there's > the issue of what are those driver init functions doing. For example, as > part of device setup, MMIO regs may be involved, which we cannot trust. It's > a lot more code to worry about from a CoCo perspective.
Why not just simply compile a special CoCo kernel that doesn't have any drivers that you don't trust. Now, the distros may be pushing back in that they don't want to support a separate kernel image. But this apparently really a pain allocation negotiation, isn't it? Intel and other companies want to make $$$$$ with CoCo.
In order to make $$$$$, you need to push the costs onto various different players in the ecosystem. This is cleverly disguised as taking current perfectly acceptable design paradigm when the trust boundary is in the traditional location, and causing all of the assumptions which you have broken as "bugs" that must be fixed by upstream developers.
But another place to push the costs is to the distro vendors, who might need to maintain a separate CoCo kernel that is differently configured. Now, Red Hat and company will no doubt push back. But the usptream development community will also push back if you try to dump too much work on *us*.
- Ted
|  |