Re: [PATCH] ata: libata-scsi: reject non-PIO protocols for READ/WRITE MULTIPLE

[Damien Le Moal <dlemoal@kernel.org>]

On 2026/11/10 17:41, Niklas Cassel wrote:
> There is nothing in SAT specs that requires us to validate the protocol field.
> When using normal (non-passthrough commands), the protocol field is initialized
> by the regular SCSI to ATA translation done by libata.
> 
> For passthrough commands, it comes from the user.
> 
> Not only does it come from the user, it requires CAP_SYS_RAWIO:
> 
> scsi_cmd_allowed() {
>         if (capable(CAP_SYS_RAWIO))
>                 return true;
>     ...
> 
> 
> (ATA_12 / ATA_16 / ATA_32 will all return false, so not allowed for a regular
> user.)
> 
> And... even if the user sends a command with a protocol that is not as per
> ACS spec, the command should time out and EH should reset the device.
> 
> 
> So... If the user sends a passthrough command with the wrong protocol...
> Well, that is on the user, no?
> (It also requires CAP_SYS_RAWIO)
> 
> 
> If we were to add protocol checks all passthrough commands, then we should
> not only check READ/WRITE MULTIPLE, we should check other commands like
> WRITE SECTORS (30h) and IDENTIFY DEVICE (ECh) too.
> 
> But, I don't think we want that. Damien, thoughts?

Unless we are talking about a command that libata-scsi emulates, passthrough
commands should not be parsed. We do not want that. So unless the bad SG_IO
command can crash the kernel, we should do nothing if the user sends a bad
command and it fails. We can let the drive fail it, even if that leads to drive
resets etc. As Niklas pointed out, SG_IO is priviledged, so it is not like any
user can create a DOS with bad SG_IO commands.

Also, the use case for this is a little silly in my opinion... Who wants to send
a PIO multi-sector IO using a modern command like ATA 32? libata supports that
if that is all that the drive can do. If the drive can do DMA and/or NCQ, then
better commands will be used without relaying on a PIO passthrough command.


-- 
Damien Le Moal
Western Digital Research