On Sat, Aug 13, 2022 at 12:49:43AM -0700, Christoph Hellwig wrote:
>
> On Fri, Aug 12, 2022 at 11:03:07AM +0300, Dmitry Bogdanov wrote:
> > > > + .support = SCSI_SUPPORT_FULL,
> > > > + .opcode = XDWRITEREAD_10,
> > > > + .cdb_size = 10,
> > > > + .usage_bits = {XDWRITEREAD_10, 0x18, 0xff, 0xff,
> > > > + 0xff, 0xff, SCSI_GROUP_NUMBER_MASK, 0xff,
> > > > + 0xff, SCSI_CONTROL_MASK},
> > > > +};
>
> > > one of Martin's tree after you made this patch.
> > Yes, I saw, Iwill remove XDWRITEREAD_* in the next revision.
>
> What this does point out is that the way the patches are done,
> we have a fundamental issue with these descriptors being potentially
> out of sync with the actually supported commands. Once way to fix
> this would be to add a parse callback to these dscriptors to unwind
> sbc_parse_cdb. The big downside would be an extra expensive indirect
> call per command, though.
Yes, there is such a risk. I was raising it in our company 2 years ago
when I did this patchset. We agreed that, until there is somebody who
can notice about it, it's OK :). It's happened not so often. There was
just one case when we changed RSOC structs - when I was adding support
of ACA condition.
Recently someone wants to have some defence against fuzzy-logic attacks,
may be he (or someone else) will intergate RSOC descriptors into
sbc_parse_cmd within his task.
