On 2024-06-20 16:32, Ulf Hansson wrote:
On Thu, 20 Jun 2024 at 14:59, Daniel Kucera <linux-mmc@xxxxxxxxx>
wrote:
On 2024-06-20 14:38, Ulf Hansson wrote:
> On Thu, 6 Jun 2024 at 15:12, <linux-mmc@xxxxxxxxx> wrote:
>>
>> From: Daniel Kucera <linux-mmc@xxxxxxxxx>
>>
>> Locked SD card will not reply to SEND_SCR or SD_STATUS commands
>> so it was failing to initialize previously. When skipped,
>> the card will get initialized and CMD42 can be sent using
>> ioctl to unlock the card or remove password protection.
>> For eMMC, this is not necessary because all initialization
>> commands are allowed in locked state.
>> Until unlocked, all read/write calls will timeout.
>
> Skipping the commands above, only means the card gets partially
> initialized.
Correct, but it's an improvement in comparison to current state.
Not sure I agree with that, sorry.
Are you saying that that being able to work with locked card is not an
improvement in comparison to not being able to? Or did I misunderstand
that?
> Leaving a card in that state seems fragile.
Fragile in what sense? Nothing can happen to the card as it is locked.
We may end up having a card half-way initialized that we can't really
communicate with in a stable manner. From a system point of view, I
would be worried.
It's not half-way initialized, it's initialized correctly, it's just not
using the full potential of the card (higher speeds, etc.).
The situation would be the same as it is currently with emmc. Locked
emmc gets initialized correctly but reads/writes time-out. What is wrong
in having the same result for both sd and emmc?
I would rather just power off the card if initialization fails and
remove its corresponding device from the system.
> What will
> happen to upper block layers and filesystems when trying to access it?
Everything will simply time-out.
Yes, but it's uncertain what that could lead to?
What will happen with power consumption and power management support,
for example.
Okay, this is a valid concern. Would it be acceptable if we just enabled
this "feature" with a module parameter, something like
"sd_initialize_locked=1" with default 0?
>
> Several years ago Al Cooper made an attempt [1] to manage the
> unlocking of the card during initialization, by finding the password
> through the "keys" subsystem. The series didn't really make it to the
> upstream kernel, but overall the approach seemed to make sense to me.
> It should allow us to complete the initialization of the card inside
> the kernel and prevent unnecessary complexity for userspace to manage.
Yes, he did a great work but obviously no-one got too excited to
review/merge
his work. His solution was complex.
It's quite some amount of code. On the other hand, it seemed quite
straight forward, not that complex to me.
It doesn't solve the situation when you don't know the password and you
just want to erase the card and continue using in. The (un)locking
doesn't belong to kernel IMO, if it can be implemented in user-space, it
should and it is more flexible that way.
Mine targets the smallest change possible to make it work at least.
I wanted to avoid a solution that would be hard to test, review and
maintain.
Especially when there is only a small interest in the feature.
> Perhaps you can have a closer look at that series and see if it's
> possible to update it?
I don't think I have the skills to revive his work.
I see, maybe we should ping Al and other interested folkz to see if
there still is some interest to move this forward?
Okay, Al, are you interested?
[...]
Kind regards
Uffe
BR
Daniel
