On Mon, Oct 04, 2021 at 06:48:33PM +0100, Marc Zyngier wrote:
> This is the second version of this series initially posted at [1] that
> aims at letting a guest express what it considers as MMIO, and only
> let this through to userspace. Together with the guest memory made
> (mostly) inaccessible to the host kernel and userspace, this allows an
> implementation of a hardened IO subsystem.
>
> A lot has been fixed/revamped/improved since the initial posting,
> although I am still not pleased with the ioremap plugging on the guest
> side. I'll take any idea to get rid of it!
>
Pros/cons of the hooks
Pros:
1) VM only needs to have a kernel that supports the feature (and a
kernel command line that enables it)
2) All the ioremapped MMIO ranges are permitted immediately, rather than
deferring until some other event (which would probably be too late in
many cases)
Cons:
1) Having to have hooks, which is never pretty
2) Adding the hypcalls to each ioremap, which adds some overhead
3) Having to reference count all the mappings, which adds even more overhead
4) Not giving the owner of the VM control over what MMIO is permitted
(Well, maybe the VM owner just needs to blacklist drivers for anything
that it doesn't want.)
I don't think any of the Con's are too bad and probably Pro-2 more or less
makes the hooks a necessity.
Thanks,
drew
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
