Re: How to fix problems with the sashiko review model

On Wed, 22 Jul 2026 10:17:40 -0400
James Bottomley <[email protected]> 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
> > >=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
> >=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
>=20
> 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.

I don't trust hardware/firmware. They can be buggy.=20

For instance, there's currently a bug at UEFI spec affecting RAS where
one particular field may have 3 different meanings because UEFI changed
its meaning on different versions of the spec without changing the version
field inside the CPER record:

	https://github.com/tianocore/edk2/issues/12708=09

If even firmware specs can't be trusted, I don't think it is safe to
assume that any particular implementation of the firmware or hardware
would be safe.

Thanks,
Mauro