linux-kernel - Re: MMC sub-system: SDIO block-mode with increment address issue

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]

Message-ID: <20071121140840.6476c6aa@poseidon.drzeus.cx>
Date:	Wed, 21 Nov 2007 14:08:40 +0100
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	djenkins@...sta.co.uk
Cc:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: MMC sub-system: SDIO block-mode with increment address issue

On Wed, 21 Nov 2007 11:57:01 +0000
Dean Jenkins <djenkins@...sta.co.uk> wrote:

> Hi Pierre,
> 
> I've looked at the SD Card Association's SDIO Part E1 V2.00
> specification concerning the Incrementing Address OP Code field for
> CMD53.
> 
> The specification indicates that the START ADDRESS is inserted into the
> Register Address register field. When the OP Code field has a value of 1
> then the during the transfer the IO address is internally incremented
> for each byte transferred. This applies to a single CMD53 command.
> 
> Looking at the implementation of sdio_io_rw_ext_helper() in sdio_io.c.
> This function can send multiple CMD53 commands. My concern is that with
> incrementing address mode selected the START ADDRESS is erroneously
> changed for subsequent CMD53 commands in the while loop.
> 

Since the caller is not supposed to care about the internal operation of sdio_io_rw_ext_helper(), the address increase is a must to maintain a consistent behaviour regardless of what transactions it decides to use.

I.e. if I write 2048 bytes with start address 0x1000, I expect it to do a single write to register 0x1000 through 0x17FF, not and unknown number of writes to some unknown interval.

Now what I suspect you're championing is to support some broken card that treats the address increase bit in CMD53 as "Magic voodoo bit #5" instead of the definition in the SDIO spec. I.e. the only address it cares about is the start address and hence needs it to be the same for each transaction. This kind of blatant disregard for the SDIO register design is of course not what sdio_io_rw_ext_helper() was designed for, and probably never will be.

> What I am trying to say is I don't believe the START ADDRESS should be
> changed by the core driver when incrementing address mode is used. I
> think incrementing address mode only applies internally to a single
> CMD53 command. The SDIO card must physically have a suitable register
> present at the START ADDRESS so changing this address to something
> dependent on the data size is going to fail I think.
> 

The SDIO card must physically have a suitable register present at the entire relevant range, not just the start address. If it doesn't then it isn't following the register interface design of SDIO (having the "increase address" bit would just be silly if the arguments were arbitrary tokens and not part of a consistent address space).

> Do you have any evidence that any card drivers will use
> sdio_io_rw_ext_helper() in a manner that needs the START ADDRESS to be 
> changed by the core driver ?
> 

There are no drivers using "increase address" yet. The ones so far have all used a single byte FIFO port.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
-
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/