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