Re: How to fix problems with the sashiko review model
Johannes Berg <[email protected]> Wed, 22 Jul 2026 16:25:03 +0200
| Newsgroups | dev.linux.lists.ksummit,dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-scsi |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 2026-07-22 at 10:17 -0400, James Bottomley wrote: > On Wed, 2026-07-22 at 16:00 +0200, Johannes Berg wrote: > > On Wed, 2026-07-22 at 09:42 -0400, James Bottomley wrote: > > >=20 > > > Well, I noted that in my reply above.=C2=A0 The way I was thinking of > > > implementing it was to add a general instruction file for drivers > > > which would make hardware trusted for pretty much everything and > > > then instruct the AI to consult driver specific files for overrides > > > to this so we could add the additional threat checks to usb.md and > > > virt.md > >=20 > > I guess it's a question which way around it should be - but I'll note > > that generally for wifi customers tend to not trust the "hardware" > > because it's mostly firmware, is generally buggy and can be attacked > > over the air too... > >=20 > > Personally (with that background) I'd tend to lean towards saying the > > high-performance stuff that does want/need to trust the device should > > opt out, it's harder to get that wrong. If we generally opt out as > > you describe and then forgot to include something, we might have > > issues. >=20 > So this is just an efficiency thing. Yeah I see what you're trying to get at, but I guess I just disagree. There's also a risk thing - if you erroneously get a report for SCSI (as you did, IIUC) then you can opt out at that point and not worry about it again. If we erroneously _don't_ get a report for something that didn't speak up because they're not on the list, didn't dare say anything, didn't pay attention, etc. then nobody ever knows until someone starts exploiting it? > There are 144 driver subsystems, > so if most of the want to trust the hardware it makes more sense to > have this as default but overriden by subsystems. However, if most of > the 144 don't trust their hardware then absolutely, I agree, it should > be per-subsystem opt in. Part of the reason for the post was to gauge > this ... and so far I count three opt outs. Well, you could also argue that there's one opt-out the other way around so far (yours). You're not going to get the full set of information required on this list either way around. Maybe all that just means it needs to be easier to actually decide either way. Doing it in the kernel as Greg suggested, would perhaps lower the bar vs. some external Sashiko contribution. johannes