linux-kernel - Re: Consistent block device references for root= cmdline

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]

Date:   Wed, 10 Jun 2020 12:33:36 -0500
From:   Roger Heflin <rogerheflin@...il.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Matthias Schiffer <matthias.schiffer@...tq-group.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Jens Axboe <axboe@...nel.dk>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Consistent block device references for root= cmdline

No idea if this would still work, but back before label/uuid and lvm
in initird I had a staticly linked "C" program that ran inside initrd,
it searched for likely places a boot device could be (mounted them and
looked for a file to confirm it was the right device, then unmounted
it), and when it found the right one, it then echo's is major/minor
numbers into /proc/sys/kernel/real-root-dev and that is used for root=
without it being on the command line.  Assuming you could get
something similar started by sytemd and/or udev inside the initrd it
might still work.

On Wed, Jun 10, 2020 at 11:51 AM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
> <matthias.schiffer@...tq-group.com> wrote:
> >
> > Hello all,
> >
> > there have been numerous attempts to make the numbering of mmcblk
> > devices consistent, mostly by using aliases from the DTS ([1], [2],
> > [3]), but all have been (rightfully) rejected. Unless I have overlooked
> > a more recent development, no attempts for a different solution were
> > made.
>
> According to aliases attempts, I think those have failed, mainly
> because of two reasons.
>
> 1. Arguments stating that LABELs/UUIDs are variable alternatives. This
> isn't the case, which I think was also concluded from the several
> earlier discussions.
> 2. Patches that tried adding support for mmc aliases, were not
> correctly coded. More precisely, what needs to be addressed is that
> the mmc core also preserves the same ids to be set for the host class
> as the block device, mmc[n] must correspond to mmcblk[n].
>
> >
> > As far as I can tell, the core of the issue seems to be the following:
> >
> > The existing solutions like LABELs and UUIDs are viable alternatives in
> > many cases, but in particular on embedded systems, this is not quite
> > sufficient: In addition to the problem that more knowledge about the
> > system to boot is required in the bootloader, this approach fails
> > completely when the same firmware image exists on multiple devices, for
> > example on an eMMC and an SD card - not an entirely uncommon situation
> > during the development of embedded systems.
> >
> > With udev, I can refer to a specific partition using a path like
> > /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was proposed
> > to add a way to refer to a device path/phandle from the kernel command
> > line. Has there been any progress on this proposal?
>
> Lots of time during the years I have been approached, both publicly
> and offlist, about whether it would be possible to add support for
> "consistent" mmcblk devices. To me, I am fine with the aliases
> approach, as long as it gets implemented correctly.
>
> >
> > Kind regards,
> > Matthias
> >
> >
> > [1] https://patchwork.kernel.org/patch/8685711/
> > [2] https://lore.kernel.org/patchwork/cover/674381/
> > [3] https://www.spinics.net/lists/linux-mmc/msg26586.html
> > [4] https://www.spinics.net/lists/linux-mmc/msg26708.html
> >
>
> Kind regards
> Uffe