linux-hardening - Re: [PATCH v4 5/5] dt-bindings: mmc: Document support for partition table in mmc-card

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]

Message-ID: <66fa9810.050a0220.3b136f.bc29@mx.google.com>
Date: Mon, 30 Sep 2024 14:22:32 +0200
From: Christian Marangi <ansuelsmth@...il.com>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Jens Axboe <axboe@...nel.dk>, Jonathan Corbet <corbet@....net>,
	Ulf Hansson <ulf.hansson@...aro.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Kees Cook <kees@...nel.org>,
	Andy Shevchenko <andy@...nel.org>,
	Daniel Golle <daniel@...rotopia.org>,
	INAGAKI Hiroshi <musashino.open@...il.com>,
	Christian Brauner <brauner@...nel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Li Lingfeng <lilingfeng3@...wei.com>,
	Ming Lei <ming.lei@...hat.com>,
	Christian Heusel <christian@...sel.eu>, linux-block@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
	linux-hardening@...r.kernel.org,
	Miquel Raynal <miquel.raynal@...tlin.com>,
	Lorenzo Bianconi <lorenzo@...nel.org>, upstream@...oha.com
Subject: Re: [PATCH v4 5/5] dt-bindings: mmc: Document support for partition
 table in mmc-card

On Mon, Sep 30, 2024 at 02:18:14PM +0200, Rasmus Villemoes wrote:
> Christian Marangi <ansuelsmth@...il.com> writes:
> 
> > Document support for defining a partition table in the mmc-card node.
> >
> > This is needed if the eMMC doesn't have a partition table written and
> > the bootloader of the device load data by using absolute offset of the
> > block device. This is common on embedded device that have eMMC installed
> > to save space and have non removable block devices.
> >
> > If an OF partition table is detected, any partition table written in the
> > eMMC will be ignored and won't be parsed.
> >
> > eMMC provide a generic disk for user data and if supported (JEDEC 4.4+)
> > also provide two additional disk ("boot0" and "boot1") for special usage
> > of boot operation where normally is stored the bootloader or boot info.
> >
> 
> This looks quite useful.
> 
> Could this be extended to also be applicable to the four "general
> purpose" hardware partitions, i.e. what is exposed as /dev/mmcblkXgpY ?
> These would often also contain some fundamental boot data at various
> offsets but also, as for the boot partitions, often without a regular
> partition table.
> 
> The eMMC spec consistently refers to the boot partitions as "boot
> partition 1" and "boot partition 2"; the boot0/boot1 naming is kind of a
> linux'ism. Similarly, the general purpose partitions are _almost_
> exclusively referred to as 1 through 4, except (at least in my copy),
> the heading for 7.4.89 says GP_SIZE_MULT_GP0 - GP_SIZE_MULT_GP3, but
> then goes on to describe GP_SIZE_MULT_1_y through GP_SIZE_MULT_4_y. So I
> wonder if on the binding level one should use partitions-{boot1,boot2}
> and, if implemented, partitions-{gp1,gp2,gp3,gp4} ?
>

Just to make sure, they are exposed as disk or char device? This is the
case of rpmb.

Adding support for this should be no-brainer as it's just a matter of
more case of the strends and more regex case on the binding.

I also notice the conflicting names, to adapt to JEDEC naming I will rename
the property to boot1 and boot2.

-- 
	Ansuel