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: <20071120151032.56bf3e31@poseidon.drzeus.cx>
Date:	Tue, 20 Nov 2007 15:10:32 +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 Tue, 20 Nov 2007 12:26:11 +0000
Dean Jenkins <djenkins@...sta.co.uk> wrote:

> Hi Pierre,
> 
> IMHO the issue is there is no upper bound limit to the valid address
> range in sdio_io_rw_ext_helper() in sdio_io.c.
> 
> I call sdio_memcpy_toio() as it enables the incrementing address flag in
> the CMD53 command but if I try passing too much data then the actual
> address of the subsequent CMD53 commands are erroneously incremented out
> of range.
> 
> The difficulty is the SDIO card can transfer 8 blocks in a single CMD53
> command using the incrementing address flag. However
> sdio_io_rw_ext_helper() will not prevent the attempt at sending 9 blocks
> transferred as 2 CMD53 commands of 8 blocks + 1 block and the last block
> goes to the wrong address. This causes a big system crash. I suspect the
> SDIO card internally resets and the MMC sub-system can't handle the
> error condition.

I'm afraid I still can't see the problem. If you want to transfer 9 blocks, then the method by which you do so shouldn't matter. So 9, or 8 + 1 should give the same end result.

> 
> This means the card driver needs to know that it cannot use
> sdio_memcpy_toio() to send any size of data but must ensure it does not
> exceed 8 blocks before calling sdio_memcpy_toio(). IMHO this makes the
> card driver undesirably tightly coupled with the core driver. OK. I'll
> workaround it using multiple calls to sdio_memcpy_toio().
> 

Well, the problem is that the abstraction used should work just fine according to how the SDIO standard is defined. The problem seems to be that some card vendors decided to go their own way and started treating the SDIO interface as something other than a simple register interface.

As long as that is the case, there will be a lot of pain supporting these weird cards. We can only debate where to put that pain and what compromises to make.

> BTW. Is the API for the exported SDIO core functions documented
> anywhere ?

Yes, as kerneldoc tags for the relevant functions. Have a look in drivers/core/sdio_io.c if you don't want to build the full document.

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/