> 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%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2 > Fdrivers%2Fvirtio%2Fvirtio_ring.c%23n57&data=05%7C02%7Clongli%40microsoft > .com%7C698adb98daa64e20184708de996302b5%7C72f988bf86f141af91ab2d7c > d011db47%7C1%7C0%7C639116847704528406%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HkjUfCDysbQKTuiCsiQai > gySStd%2BI3VrHUnfMC%2FBORc%3D&reserved=0. > > > > 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
Will do, thank you. Long
