Re: [PATCH] virtio_net: validate device stats reply records before use
"Michael S. Tsirkin" <[email protected]>
| Newsgroups | dev.linux.lists.virtualization,org.kernel.vger.linux-kernel,org.kernel.vger.netdev,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Jul 11, 2026 at 11:29:56AM -0400, Michael Bommarito wrote: > On Sat, Jul 11, 2026 at 11:20 AM Michael S. Tsirkin <[email protected]> wrote: > > Why does it "matter most", or at all, there? > > Host can always deny guest service. In fact, this is how cloud vendors > > charge their clients, by denying service to whoever did not pay them. > ... > > I'm all for making things easier to debug even when the device is buggy. > > But I'm not inclined to add tons of hard to maintain code to > > that end, and I would be worried broken hosts will come to > > rely on drivers working around them. > > I am always confused by the CoCo threat model to be honest, Confidential computing? It's vague at points, given the term covers a lot of different hardware. But one thing is clear - it's about confidentiality. DoS by host is empathically outside the threat model. On any virtualization platform I know without exception, host can just exit the VM, done, service denied. > since it > seems like some people care a lot about maximalist reliance on the > contract and other people are more practical about how many other > vectors exist anyway. I don't really know what "vectors" or "the contract" are here. Making a guest recover from a misbehaving device has as much a chance to reduce security as increase it. So the only benefit is robustness for users/developers, not security. And that has to be weighted against the maintainance cost of the change. This one is too costly, I judge. > No hard feelings if you want to NACK, but at > least it's documented publicly now for people to consider. > > Thanks, > Mike