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-next>] [day] [month] [year] [list]
Message-ID: <fb0340aaf273be84e915214a3d8bae4ac85d7c0b.camel@ew.tq-group.com>
Date:   Wed, 10 Jun 2020 15:15:03 +0200
From:   Matthias Schiffer <matthias.schiffer@...tq-group.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Jens Axboe <axboe@...nel.dk>, s.hauer@...gutronix.de
Cc:     linux-mmc@...r.kernel.org, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Consistent block device references for root= cmdline

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.

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?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ