linux-kernel - Re: libata passthru: support PIO multi commands

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 Jun 2007 10:57:21 +0800
From:	Albert Lee <albertcc@...ibm.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Jeff Garzik <jeff@...zik.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	IDE/ATA development list <linux-ide@...r.kernel.org>
Subject: Re: libata passthru: support PIO multi commands

Alan Cox wrote:
>>ata_scsi_pass_thru() is not executed at ioctl submission time (block 
>>queue submission time), but rather immediately before it is issued to 
>>the drive.  At that point you know the bus is idle, all other commands 
>>have finished executing, and dev->multi_count is fresh not stale.  The 
>>code path goes from ata_scsi_pass_thru() to ata_qc_issue() without 
>>releasing the spinlock, even.
> 
> 
> Think up to user space
> 
> Poorusersapp			set multicount to 4
> 
> Evilproprietarytuningdaemon	set multicount to 8
> 
> Poorusersapp			issue I/O
> 
> at which point an error is indeed best.
> 
> 
>>But the last point is true -- we should error rather than just warn 
>>there, AFAICS.
> 
> 
> Definitely. We've been asked "please do something stupid" and not even in
> a case where the requester may know better.
> 

It looks like the ATA passthru commands contain more information than
what libata needs to execute a command.

e.g. protocol number:
     libata could possibly infer the protocol from the command opcode.

e.g. multi_count:
     libata caches dev->multi_count. Passing multi_count along with
     each passthru command looks useless for libata.     

e.g. t_dir:
     libata could possible infer the direction from the command opcode
     or from the protocol number (e.g. 4: PIO_IN / 5: PIO_OUT).

Due to the redundant info, there is possiblely inconsistency between
the parameters. e.g. t_dir vs protocol. e.g. command vs protocol.

It seems the "redundant" parameters are designed to allow stateless SATL
implementation: The application/passthru command tells the stateless SATL
implementation the protocol and the multi_count, etc. Then SATL just
follows the instruction blindly, even if asked to do something stupid.

Currently libata
 - uses the passthru protocol number blindly
   (even if the application issues a DMA command with wrong PIO protocol.)
 - checks and warns about multi_count
 - ignores t_dir, byte_block and so on.

Maybe we need a strategy to deal with incorrect passed-thru commands?
say,
 - check and reject if something wrong
 - mimimal check and warn/ignore, if it doesn't hurt command execution

--
albert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/