Re: How to fix problems with the sashiko review model

On Wed, 22 Jul 2026 11:24:38 -0400
James Bottomley <[email protected]> wrote:

> On Wed, 2026-07-22 at 17:09 +0200, Mauro Carvalho Chehab wrote:
> > On Wed, 22 Jul 2026 10:17:40 -0400
> > James Bottomley <[email protected]> wrote:
> >  =20
> > > On Wed, 2026-07-22 at 16:00 +0200, Johannes Berg wrote: =20
> > > > On Wed, 2026-07-22 at 09:42 -0400, James Bottomley wrote:=C2=A0  =20
> > > > >=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=C2=A0  =20
> > > >=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.=C2=A0  =20
> > >=20
> > > So this is just an efficiency thing.=C2=A0 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.=C2=A0
> > > However, if most of the 144 don't trust their hardware then
> > > absolutely, I agree, it should be per-subsystem opt in.=C2=A0 Part of
> > > the reason for the post was to gauge this ... and so far I count
> > > three opt outs. =20
> >=20
> > I don't trust hardware/firmware. They can be buggy.  =20
>=20
> Wait, buggy is different; we have potentially buggy in SCSI as well
> (rather a lot of it, in fact).  However, we don't fix theoretical
> hardware bugs, we require users to specify a device (which they could
> add to the code as comments to keep sashiko quiet).

That depends on the type of theoretical bug: for instance, if a value
is used to calculate an offset into an array, it makes sense to have
a check to avoid accessing data outside the array size. Also, if
a value is used as a denominator, it makes sense to check if the value
is not zero.

We do have such kind of checks on most media drivers - and there
ended helping to avoid OOPSes due to problematic hardware. That's
specially true on peripheral hardware like USB devices: they tend
to have a lot of such bugs, up to the point that we can't really
trust the device.

So, I'd say that, instead of a global prompt saying to trust hardware,
the best is to do it only on places where people are absolutely sure
that the hardware is trusty enough.

> The general tenor of my driver/ prompt would be that hardware may never
> be assumed to be malicious but could be buggy.  In the event that the
> fix is for buggy hardware, the submitter must state which hardware is
> buggy and confirm they've tested the fix on the actual hardware.

In practice, on most cases, it is hard to distinguish buggy from
malicious. IMO, it is better to prevent cases that could be=20
too dangerous, even if aren't there any confirmation that the
issue happened on an actual hardware.

Thanks,
Mauro