On Tue, Oct 12, 2021 at 11:35 AM Andi Kleen [off-list ref] wrote:
quoted
The "better safe-than-sorry" argument is hard to build consensus
around. The spectre mitigations ran into similar problems where the
community rightly wanted to see the details and instrument the
problematic paths rather than blanket sprinkle lfence "just to be
safe".
But that was due to performance problems in hot paths. Nothing of this
applies here.
It applies because a new API that individual driver authors is being
proposed and that's an ongoing maintenance burden that might be
mitigated by hiding that implementation detail from leaf drivers.
quoted
In this case the rules about when a driver is suitably
"hardened" are vague and the overlapping policy engines are confusing.
What is confusing exactly?
Multiple places to go to enable functionality. The device-filter
firewall policy can collide with the ioremap access control policy.
For me it both seems very straight forward and simple (but then I'm biased)
You seem to be having a difficult time iterating this proposal toward
consensus. I don't think the base principles are being contested as
much as the semantics, scope, and need for the proposed API that is in
the purview of all leaf driver developers.
The policy is:
- Have an allow list at driver registration.
- Have an additional opt-in for MMIO mappings (and potentially config
space, but that's not currently there) to cover init calls completely.
The proliferation of policy engines and driver special casing is the
issue. Especially in this case where the virtio use case being
opted-in is *already* in a path that has been authorized by the
device-filter policy engine. I.e. why special case the ioremap() in
virtio to be additionally authorized when the device has already been
authorized to probe? Put another way, the easiest driver API change to
merge would be no additional changes in leaf drivers.
quoted
I'd rather see more concerted efforts focused/limited core changes
rather than leaf driver changes until there is a clearer definition of
hardened.
A hardened driver is a driver that
- Had similar security (not API) oriented review of its IO operations
(mainly MMIO access, but also PCI config space) as a non privileged user
interface (like a ioctl). That review should be focused on memory safety.
- Had some fuzzing on these IO interfaces using to be released tools.
What is the intersection of ioremap() users that are outside of the
proposed probe authorization regime AND want confidential computing
support?
Right now it's only three virtio drivers (console, net, block)
Really it's no different than what we do for every new unprivileged user
interface.
quoted
I.e. instead of jumping to the assertion that fixing up
these init-path vulnerabilities are too big to fix, dig to the next
level to provide more evidence that per-driver opt-in is the only
viable option.
For example, how many of these problematic paths are built-in to the
average kernel config?
I don't think arguments from "the average kernel config" (if such a
thing even exists) are useful. That's would be just hand waving.
I'm trying to bridge to your contention that this enabling can not
rely on custom kernel configs and must offer protection on the same
kernel image that might ship in the host, but lets set this aside and
focus on when and where leaf drivers need to adopt a new API.
quoted
A strawman might be to add a sprinkling error
exits in the module_init() of the problematic drivers, and only fail
if the module is built-in, and let modprobe policy handle the rest.
That would be already hundreds of changes. I have no idea how such a
thing could be maintained or sustained either.
Really I don't even see how these alternatives can be considered. Tree
sweeps should always be last resort. They're a pain for everyone. But
here they're casually thrown around as alternatives to straight forward
one or two line changes.
If it looked straightforward I'm not sure we would be having this
discussion, I think it's reasonable to ask if this is a per-driver
opt-in responsibility that must be added in addition to probe
authorization.
quoted
quoted
Default policy in user space just seems to be a bad idea here. Who
should know if a driver is hardened other than the kernel? Maintaining
the list somewhere else just doesn't make sense to me.
I do not understand the maintenance burden correlation of where the
policy is driven vs where the list is maintained?
All the hardening and auditing happens in the kernel tree. So it seems
the natural place to store the result is in the kernel tree.
But there's no single package for initrd, so you would need custom
configurations for all the supported distros.
Also we're really arguing about a list that currently has three entries.
quoted
Even if I agreed
with the contention that out-of-tree userspace would have a hard time
tracking the "hardened" driver list there is still an in-tree
userspace path to explore. E.g. perf maintains lists of things tightly
coupled to the kernel, this authorized device list seems to be in the
same category of data.
You mean the event list? perf is in the kernel tree, so it's maintained
together with the kernel.
But we don't have a kernel initrd.
I'm proposing that this list is either tiny and slow moving enough for
initrd builders to track manually, or it's a data file that ships in
distro kernel packages that initrd builders can pull in.
quoted
quoted
Also there is the more practical problem that some devices are needed
for booting. For example in TDX we can't print something to the console
with this mechanism, so you would never get any output before the
initrd. Just seems like a nightmare for debugging anything. There really
needs to be an authorization mechanism that works reasonably early.
I can see a point of having user space overrides though, but we need to
have a sane kernel default that works early.
Right, as I suggested [1], just enough early authorization to
bootstrap/debug initramfs and then that can authorize the remainder.
But how do you debug the kernel then? Making early undebuggable seems
just bad policy to me.
I am not proposing making the early undebuggable.
And if you fix if for the console why not add the two more entries for
virtio net and block too?
Again because there seems to be struggling consensus around what
criteria constitutes being added to this list. In order to move this
series forward I'm trying to find common ground.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization