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: <5e9a80d6-6c89-478e-99c9-584647661f5e@pengutronix.de>
Date: Thu, 5 Dec 2024 12:21:24 +0100
From: Ahmad Fatoum <a.fatoum@...gutronix.de>
To: Christian Marangi <ansuelsmth@...il.com>, 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>, Daniel Golle <daniel@...rotopia.org>,
 INAGAKI Hiroshi <musashino.open@...il.com>,
 Christian Brauner <brauner@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
 Ming Lei <ming.lei@...hat.com>, Li Lingfeng <lilingfeng3@...wei.com>,
 Christian Heusel <christian@...sel.eu>, Avri Altman <avri.altman@....com>,
 Linus Walleij <linus.walleij@...aro.org>,
 Adrian Hunter <adrian.hunter@...el.com>,
 Riyan Dhiman <riyandhiman14@...il.com>,
 Mikko Rapeli <mikko.rapeli@...aro.org>,
 Jorge Ramirez-Ortiz <jorge@...ndries.io>, Li Zhijian
 <lizhijian@...itsu.com>,
 Dominique Martinet <dominique.martinet@...ark-techno.com>,
 Jens Wiklander <jens.wiklander@...aro.org>,
 Christophe JAILLET <christophe.jaillet@...adoo.fr>,
 linux-block@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
 devicetree@...r.kernel.org, Lorenzo Bianconi <lorenzo@...nel.org>,
 Miquel Raynal <miquel.raynal@...tlin.com>, upstream@...oha.com,
 Christoph Hellwig <hch@...radead.org>,
 Pengutronix Kernel Team <kernel@...gutronix.de>
Cc: Christoph Hellwig <hch@....de>
Subject: Co-existence of GPT and fixed partitions (Was: Re: [PATCH v6 5/6]
 block: add support for partition table defined in OF)

Hi,

sorry for not writing sooner. I only noticed this now.

On 03.10.24 00:11, Christian Marangi wrote:
> Add support for partition table defined in Device Tree. Similar to how
> it's done with MTD, add support for defining a fixed partition table in
> device tree.
> 
> A common scenario for this is fixed block (eMMC) embedded devices that
> have no MBR or GPT partition table to save storage space. Bootloader
> access the block device with absolute address of data.

How common are these? I never worked with a system that didn't use MBR
or GPT for the user partition.

> This is to complete the functionality with an equivalent implementation
> with providing partition table with bootargs, for case where the booargs
> can't be modified and tweaking the Device Tree is the only solution to
> have an usabe partition table.
> 
> The implementation follow the fixed-partitions parser used on MTD
> devices where a "partitions" node is expected to be declared with
> "fixed-partitions" compatible in the OF node of the disk device
> (mmc-card for eMMC for example) and each child node declare a label
> and a reg with offset and size. If label is not declared, the node name
> is used as fallback. Eventually is also possible to declare the read-only
> property to flag the partition as read-only.

barebox has for many years supported defining fixed partitions on SD/MMC
nodes and it's used heavily to define e.g. the location of the barebox
environment. Many who do so, do this either before the first partition
of the MBR/GPT or overlay the fixed partition to be identical to
an existing MBR/GPT partition.

barebox also by default copies all fixed partitions it is aware of
into the kernel DT, so if the kernel now stops parsing GPT/MBR when
a fixed partition node is defined, this would break compatibility of
existing barebox-booting systems with new kernels.

> +config OF_PARTITION
> +	bool "Device Tree partition support" if PARTITION_ADVANCED
> +	depends on OF
> +	help
> +	  Say Y here if you want to enable support for partition table
> +	  defined in Device Tree. (mainly for eMMC)
> +	  The format for the device tree node is just like MTD fixed-partition
> +	  schema.

Thanks for making this configurable and disabled by default, so users
won't experience breakage if they just do a make olddefconfig.

> diff --git a/block/partitions/core.c b/block/partitions/core.c
> index abad6c83db8f..dc21734b00ec 100644
> --- a/block/partitions/core.c
> +++ b/block/partitions/core.c
> @@ -43,6 +43,9 @@ static int (*const check_part[])(struct parsed_partitions *) = {
>  #ifdef CONFIG_CMDLINE_PARTITION
>  	cmdline_partition,
>  #endif
> +#ifdef CONFIG_OF_PARTITION
> +	of_partition,		/* cmdline have priority to OF */
> +#endif
>  #ifdef CONFIG_EFI_PARTITION
>  	efi_partition,		/* this must come before msdos */
>  #endif

If I understand correctly, it's possible to have both partitions-boot1 and
a GPT on the user area with your patch, right?

So this only leaves the matter of dealing with both fixed-partitions and
GPT for the same device node.

What are the thoughts on this? An easy way out would be to make of_partition
come later than efi_partition/mbr_partition, but I think it would be
nice if the kernel could consume partition info out of both of_partition
and efi_partition as long they don't collide.

Thanks,
Ahmad



-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ