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] [day] [month] [year] [list]
Date:	Fri, 29 Jan 2016 22:44:55 +0800
From:	Chen-Yu Tsai <wens@...e.org>
To:	Ulf Hansson <ulf.hansson@...aro.org>
Cc:	Chen-Yu Tsai <wens@...e.org>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Hans de Goede <hdegoede@...hat.com>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [PATCH RFC 03/15] mmc: sunxi: Block signal voltage switching (CMD11)

On Fri, Jan 29, 2016 at 6:42 PM, Ulf Hansson <ulf.hansson@...aro.org> wrote:
> On 21 January 2016 at 06:26, Chen-Yu Tsai <wens@...e.org> wrote:
>> Allwinner's mmc controller supports signal voltage switching. This is
>> supported in code in Allwinner's kernel. However, publicly available
>> boards all tie it to a fixed 3.0/3.3V regulator, with options to tie
>> it to 1.8V for eMMC on some.
>>
>> Since Allwinner's kernel is an ancient 3.4, it is hard to say whether
>> adapting it's code to a modern mainline kernel would work. Block signal
>> voltage switching until someone has proper hardware to implement and
>> test this.
>>
>> This only affects SD UHS-1 modes, as eMMC switches the voltage directly
>> without any signaling.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@...e.org>
>> ---
>>  drivers/mmc/host/sunxi-mmc.c | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>> index 790f01662b4e..0495ae7da6d6 100644
>> --- a/drivers/mmc/host/sunxi-mmc.c
>> +++ b/drivers/mmc/host/sunxi-mmc.c
>> @@ -816,6 +816,20 @@ static void sunxi_mmc_request(struct mmc_host *mmc, struct mmc_request *mrq)
>>                 }
>>         }
>>
>> +       /*
>> +        * TODO Support signal voltage switching
>> +        *
>> +        * Compared to Allwinner's kernel, recent updates in the mmc core
>> +        * mean this should be as easy as setting the flags in cmd_val and
>> +        * imask, and waiting for it to finish. However no boards support
>> +        * this so this cannot be tested. Block it for now.
>> +        */
>> +       if (cmd->opcode == SD_SWITCH_VOLTAGE) {
>> +               mrq->cmd->error = -EPERM;
>> +               mmc_request_done(mmc, mrq);
>> +               return;
>> +       }
>
> Unless some of the MMC_CAP_UHS* mode is set, this command shouldn't be sent.
>
> So, if you *really* want to protect from this, I think it's better to
> clear these caps in the ->probe() function, after mmc_of_parse() has
> been called.

OK. If we need to block these, then we need to block all the other
unsupported caps, which seems excessive and unnecessary. I'll drop
this patch.

Thanks
ChenYu

>
>> +
>>         if (cmd->opcode == MMC_GO_IDLE_STATE) {
>>                 cmd_val |= SDXC_SEND_INIT_SEQUENCE;
>>                 imask |= SDXC_COMMAND_DONE;
>> --
>> 2.7.0.rc3
>>
>
> Kind regards
> Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ