devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	 Vignesh Raghavendra <vigneshr@ti.com>, robh <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	 chengzhihao1 <chengzhihao1@huawei.com>,
	 John Crispin <john@phrozen.org>,
	 linux-mtd <linux-mtd@lists.infradead.org>,
	 devicetree <devicetree@vger.kernel.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC 2/2] mtd: ubi: add support for protecting critical volumes
Date: Sun, 29 Sep 2024 14:26:02 +0200 (CEST)	[thread overview]
Message-ID: <251386789.117942.1727612762462.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <b43a7155f80995c3986893951c092291caf3a5f4.1727527457.git.daniel@makrotopia.org>

----- Ursprüngliche Mail -----
> Von: "Daniel Golle" <daniel@makrotopia.org>
> Allow the boot firmware to define volumes which are critical for the
> system to boot, such as the bootloader itself if stored inside a UBI
> volume. Protect critical volumes by preventing the user from removing,
> resizing or writing to them, and also prevent the UBI device from
> being detached if a critical volume is present.

I agree with the doubts raised in patch 1/2, if userspace is so hostile
to delete system partitions, there is little hope.
But I'm still open for discussion.

What I veto is preventing detach.
This makes a clean tear down of the system impossible.
It becomes more and more common that advanced userspace shuts down
everything it setup during boot. e.g. while reboot switching back
to an initramfs, umounting root, shutting down all storage, etc...

Thanks,
//richard

  reply	other threads:[~2024-09-29 12:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-28 12:47 [PATCH RFC 1/2] dt-bindings: mtd: ubi-volume: add 'volume-is-critical' property Daniel Golle
2024-09-28 12:48 ` [PATCH RFC 2/2] mtd: ubi: add support for protecting critical volumes Daniel Golle
2024-09-29 12:26   ` Richard Weinberger [this message]
2024-09-30  1:56     ` Zhihao Cheng
2024-09-30 18:43       ` Richard Weinberger
2024-09-30 19:39         ` Daniel Golle
2024-09-30 19:54           ` Richard Weinberger
2024-10-08  2:55             ` Zhihao Cheng
2024-09-28 13:02 ` [PATCH RFC 1/2] dt-bindings: mtd: ubi-volume: add 'volume-is-critical' property Krzysztof Kozlowski
2024-09-28 13:09   ` Daniel Golle
2024-09-28 13:45     ` Krzysztof Kozlowski
2024-09-28 14:38       ` Daniel Golle
2024-09-29  4:03         ` Zhihao Cheng
2024-09-29 10:52           ` Daniel Golle
2024-09-29 11:23             ` Zhihao Cheng
2024-09-29 12:16               ` Daniel Golle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=251386789.117942.1727612762462.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=chengzhihao1@huawei.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=devicetree@vger.kernel.org \
    --cc=john@phrozen.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=robh@kernel.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).