Re: How to fix problems with the sashiko review model

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.

So this is just an efficiency thing.  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.

Regards,

James
=20