Re: adding aliases to mmc ... again

[Stephen Warren <swarren@wwwdotorg.org>]

On 05/22/2014 12:21 PM, Sascha Hauer wrote:
> On Thu, May 22, 2014 at 10:16:35AM -0600, Stephen Warren wrote:
>> On 05/22/2014 09:30 AM, Sascha Hauer wrote:
>>> Hi all,
>>>
>>> The wish to have persistent MMC block device names for passing a suitable
>>> root=/dev/mmcblkX option came up several times already and has been discussed
>>> at least in these threads:
>>>
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/109984.html
>>> https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg22104.html
>>> http://comments.gmane.org/gmane.linux.kernel.mmc/21519
>>>
>>> Several patches have been proposed to nail the slot index to a known number.
>>> Arguments against these patches were:
>>>
>>> - Use an initrd and locate the correct root device there
>>>   even Thomas who suggested this admitted this would be painful to do
>>> - use root=UUID= or root=PARTUUID=
>>>   This generally works but has an important downside. With the UUID
>>>   approach devices which should boot from the internal eMMC may start
>>>   booting from an external SD slot when somebody deliberately inserts
>>>   a SD card with the same UUID.
>>>
>>> The following patches should have the technical issues fixed. It works
>>> by counting the mmc aliases in the devicetree during initialization of
>>> the mmc framework. Those slot numbers will never be assigned to other
>>> hosts.
>>
>> Does it solve the following, which AFAIK has always been the primary
>> argument against aligning block device IDs with controller IDs:
>>
>> - User inserts SD card into MMC controller ID (or alias) 1.
>> - /dev/mmcblk1 now exists
>> - Mount /dev/mmcblk1 on /mnt/tmp
>> - User removes that SD card
>> - /dev/mmcblk1 still exists, since it's mounted so can't be deleted
>> after the card removal.
>> - User inserts SD card into MMC controller ID (or alias) 1.
>> - /dev/mmcblkN (N is something other than 1) now exists
>>
>> Now, the block device ID must be != the original ID, since two block
>> devices exist.
> 
> No, it shouldn't solve that, but it's out of scope for this patch. All
> it solves is to reliably find the rootfs. If the card containing your
> rootfs is removed you are in trouble anyway and it won't help if it gets
> the same mmcblkno once it's plugged again. For other devices which don't
> contain the rootfs there are enough possibilities to find them in userspace.

I don't think there should be any special cases for the root fs.

I don't think the disadvantage of the UUID= or PARTUUID= issue you
mention enough is really an issue in general. If it is for some
platform, then the root fs should be cryto-signed and validated to
prevent someone from using the wrong root fs.