On Fri, Apr 10, 2026 at 10:29:45PM +0000, Long Li wrote: > > On Sat, Mar 21, 2026 at 12:56:39AM +0000, Long Li wrote: > > > > > How we rephrase this in this way: the driver should not corrupt or > > > overflow other parts of the kernel if its device is misbehaving (or > > > has a bug). > > > > If we are going to do this CC hardening stuff I think I want to see a more > > comphrensive approach, like if we detect an attack then the kernel instantly > > crashes or something. Or at least an approach in general agreed to by the > > CC and > > kernel community. > > > > Igoring the issue and continuing seems just wrong. > > > > This sprinkling of random checks in this series doesn't feel comprehensive > > or > > cohesive to me. > > > > Jason > > Can we follow the virtio BAD_RING()/vq->broken pattern in > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/virtio/virtio_ring.c#n57. > > Add a broken flag to mana_ib_dev. When any hardware response > contains out-of-range values, mark the device broken and fail the > operation - during probe this prevents device registration entirely, > at runtime all subsequent operations return -EIO.
If that's the plan I would think it should be struct device based, but yeah, I'm more comfortable with this sort of direction as a CC hardening plan. Jason
