Reject CAMIOGET and CAMIOQUEUE ioctl's on pass(4) 32-bit compat mode

[brooks]

Summary

These take a union ccb argument which is full of kernel pointers and was
not designed to be exposed to userspace. Substantial translation
efforts would be required to make this work. By rejecting the request
we avoid processing or returning entierly wrong data.

Sponsored by: DARPA, AFRL

[markj]

sys/cam/scsi/scsi_pass.c

1866 ↗

(On Diff #40168)

This distinction doesn't matter in practice, but shouldn't we be checking the flags from the "td" argument to passdoioct()?

[brooks]

• Use SV_PROC_FLAG rather than SV_CURPROC_FLAG.

[imp]

Yea, there's no way in hell this could possibly work now. Better to say so than to allow it. Not sure ENOTTY is the right error, but have no appetite to bikeshed on it.

[ken]

This is fine. It would be an unusual situation in any case to have a 32-bit binary attempting to use these ioctls, since they are relatively new (late 2015 when they went in the tree).

For what it's worth, CAM was designed from the beginning with the idea that CCBs would be shared between userland and the kernel. All of the CDB filling routines (e.g. scsi_read_write(), scsi_inquiry(), etc.) and many others are available in userland and the kernel, so that you can write to much the same API in userland and in the kernel.

There are kernel pointers in there, though, and we might do things a little differently if we were doing it today.