All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: Richard Weinberger <richard@nod.at>
Cc: chengzhihao1 <chengzhihao1@huawei.com>,
	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>,
	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: Mon, 30 Sep 2024 20:39:48 +0100	[thread overview]
Message-ID: <Zvr-hOM2DfveaqeC@makrotopia.org> (raw)
In-Reply-To: <364911897.123906.1727721820227.JavaMail.zimbra@nod.at>

On Mon, Sep 30, 2024 at 08:43:40PM +0200, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
> > Von: "chengzhihao1" <chengzhihao1@huawei.com>
> >>> 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.
> > 
> > Yes, I agree that it is meaningful to prevent user from operating
> > volumes accidently. How about doing that by some existing methods? Eg.
> > selinux(Design sepolicy for ioctl cmd).
> 
> Another thought, do we really need to enforce this in kernel space?
> Teaching ubi-tools to be super careful with some volumes is also an option.
> 
> like a ubirmvol ... --i-know-what-im-doing.

True, enforcement doesn't need to happen in kernel (though I think it's
nicer, but really just a matter of taste, I guess). ubi-tools would still
need to be able to recognize critical volumes somehow, and that could be
done by checking if the 'volume-is-critical' property is present in
/sys/class/ubi/ubi*_*/of_node/

If you prefer going down that road instead I will work on patches for
git.infradead.org/mtd-utils.git instead.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Golle <daniel@makrotopia.org>
To: Richard Weinberger <richard@nod.at>
Cc: chengzhihao1 <chengzhihao1@huawei.com>,
	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>,
	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: Mon, 30 Sep 2024 20:39:48 +0100	[thread overview]
Message-ID: <Zvr-hOM2DfveaqeC@makrotopia.org> (raw)
In-Reply-To: <364911897.123906.1727721820227.JavaMail.zimbra@nod.at>

On Mon, Sep 30, 2024 at 08:43:40PM +0200, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
> > Von: "chengzhihao1" <chengzhihao1@huawei.com>
> >>> 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.
> > 
> > Yes, I agree that it is meaningful to prevent user from operating
> > volumes accidently. How about doing that by some existing methods? Eg.
> > selinux(Design sepolicy for ioctl cmd).
> 
> Another thought, do we really need to enforce this in kernel space?
> Teaching ubi-tools to be super careful with some volumes is also an option.
> 
> like a ubirmvol ... --i-know-what-im-doing.

True, enforcement doesn't need to happen in kernel (though I think it's
nicer, but really just a matter of taste, I guess). ubi-tools would still
need to be able to recognize critical volumes somehow, and that could be
done by checking if the 'volume-is-critical' property is present in
/sys/class/ubi/ubi*_*/of_node/

If you prefer going down that road instead I will work on patches for
git.infradead.org/mtd-utils.git instead.

  reply	other threads:[~2024-09-30 19:40 UTC|newest]

Thread overview: 32+ 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:47 ` Daniel Golle
2024-09-28 12:48 ` [PATCH RFC 2/2] mtd: ubi: add support for protecting critical volumes Daniel Golle
2024-09-28 12:48   ` Daniel Golle
2024-09-29 12:26   ` Richard Weinberger
2024-09-29 12:26     ` Richard Weinberger
2024-09-30  1:56     ` Zhihao Cheng
2024-09-30  1:56       ` Zhihao Cheng
2024-09-30 18:43       ` Richard Weinberger
2024-09-30 18:43         ` Richard Weinberger
2024-09-30 19:39         ` Daniel Golle [this message]
2024-09-30 19:39           ` Daniel Golle
2024-09-30 19:54           ` Richard Weinberger
2024-09-30 19:54             ` Richard Weinberger
2024-10-08  2:55             ` Zhihao Cheng
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:02   ` Krzysztof Kozlowski
2024-09-28 13:09   ` Daniel Golle
2024-09-28 13:09     ` Daniel Golle
2024-09-28 13:45     ` Krzysztof Kozlowski
2024-09-28 13:45       ` Krzysztof Kozlowski
2024-09-28 14:38       ` Daniel Golle
2024-09-28 14:38         ` Daniel Golle
2024-09-29  4:03         ` Zhihao Cheng
2024-09-29  4:03           ` Zhihao Cheng
2024-09-29 10:52           ` Daniel Golle
2024-09-29 10:52             ` Daniel Golle
2024-09-29 11:23             ` Zhihao Cheng
2024-09-29 11:23               ` Zhihao Cheng
2024-09-29 12:16               ` Daniel Golle
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=Zvr-hOM2DfveaqeC@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=chengzhihao1@huawei.com \
    --cc=conor+dt@kernel.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=richard@nod.at \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.