All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pintu Agarwal <pintu.ping@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: Greg KH <greg@kroah.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Phillip Lougher <phillip@squashfs.org.uk>,
	Sean Nyekjaer <sean@geanix.com>,
	Kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: MTD: How to get actual image size from MTD partition
Date: Tue, 20 Jul 2021 13:31:55 +0530	[thread overview]
Message-ID: <CAOuPNLhti3tocN-_D7Q0QaAx5acHpb3AQyWaUKgQPNW3XWu58g@mail.gmail.com> (raw)
In-Reply-To: <1556211076.48404.1626763215205.JavaMail.zimbra@nod.at>

On Tue, 20 Jul 2021 at 12:10, Richard Weinberger <richard@nod.at> wrote:

> > Anyways, I will create a separate thread for dm-verity issue and keep
> > this thread still open for UBI image size issue.
> > We may use dm-verify for rootfs during booting, but still we need to
> > perform integrity check for other nand partitions and UBI volumes.
> >
> > So, instead of calculating the checksum for the entire partition, is
> > it possible to perform checksum only based on the image size ?
> > Right now, we are still exploring what are the best possible
> > mechanisms available for this.
>
> I still don't fully understand what you are trying to achieve.
> Is it about cryptographic integrity of your storage or detecting
> errors after the flashing process?
>
Yes, it is about md5 checksum verification for every partition to
check its integrity before updates.


> But let me advertise ubiblock a second time.
Sorry, I could not understand about the ubiblock request. Is it
possible to elaborate little more ?
We are already using squashfs on top of our UBI volumes (including
rootfs mounting).
This is the kernel command line we pass:
rootfstype=squashfs root=/dev/mtdblock44 ubi.mtd=40,0,30
And CONFIG_MTD_UBI_BLOCK=y is already enabled in our kernel.
Do we need to do something different for ubiblock ?

> If you place your squashfs on a UBI static volume, UBI knows the exact length and you can checksum it
> more easily.
Yes, we use squashfs on UBI volumes, but our volume type is still dynamic.
Also, you said, UBI knows the exact length, you mean the whole image length ?
How can we get this length at runtime ?
Also, how can we get the checksum of the entire UBI volume content
(ignoring the erased/empty/bad block content) ?

Or, you mean to say, the whole checksum logic is in-built inside the
UBI layer and users don't need to worry about the integrity at all ?


Thanks,
Pintu

WARNING: multiple messages have this Message-ID (diff)
From: Pintu Agarwal <pintu.ping@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: Greg KH <greg@kroah.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	 linux-mtd <linux-mtd@lists.infradead.org>,
	 linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Phillip Lougher <phillip@squashfs.org.uk>,
	 Sean Nyekjaer <sean@geanix.com>,
	Kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: MTD: How to get actual image size from MTD partition
Date: Tue, 20 Jul 2021 13:31:55 +0530	[thread overview]
Message-ID: <CAOuPNLhti3tocN-_D7Q0QaAx5acHpb3AQyWaUKgQPNW3XWu58g@mail.gmail.com> (raw)
In-Reply-To: <1556211076.48404.1626763215205.JavaMail.zimbra@nod.at>

On Tue, 20 Jul 2021 at 12:10, Richard Weinberger <richard@nod.at> wrote:

> > Anyways, I will create a separate thread for dm-verity issue and keep
> > this thread still open for UBI image size issue.
> > We may use dm-verify for rootfs during booting, but still we need to
> > perform integrity check for other nand partitions and UBI volumes.
> >
> > So, instead of calculating the checksum for the entire partition, is
> > it possible to perform checksum only based on the image size ?
> > Right now, we are still exploring what are the best possible
> > mechanisms available for this.
>
> I still don't fully understand what you are trying to achieve.
> Is it about cryptographic integrity of your storage or detecting
> errors after the flashing process?
>
Yes, it is about md5 checksum verification for every partition to
check its integrity before updates.


> But let me advertise ubiblock a second time.
Sorry, I could not understand about the ubiblock request. Is it
possible to elaborate little more ?
We are already using squashfs on top of our UBI volumes (including
rootfs mounting).
This is the kernel command line we pass:
rootfstype=squashfs root=/dev/mtdblock44 ubi.mtd=40,0,30
And CONFIG_MTD_UBI_BLOCK=y is already enabled in our kernel.
Do we need to do something different for ubiblock ?

> If you place your squashfs on a UBI static volume, UBI knows the exact length and you can checksum it
> more easily.
Yes, we use squashfs on UBI volumes, but our volume type is still dynamic.
Also, you said, UBI knows the exact length, you mean the whole image length ?
How can we get this length at runtime ?
Also, how can we get the checksum of the entire UBI volume content
(ignoring the erased/empty/bad block content) ?

Or, you mean to say, the whole checksum logic is in-built inside the
UBI layer and users don't need to worry about the integrity at all ?


Thanks,
Pintu

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

WARNING: multiple messages have this Message-ID (diff)
From: Pintu Agarwal <pintu.ping@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: Kernelnewbies <kernelnewbies@kernelnewbies.org>,
	Greg KH <greg@kroah.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Sean Nyekjaer <sean@geanix.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Phillip Lougher <phillip@squashfs.org.uk>
Subject: Re: MTD: How to get actual image size from MTD partition
Date: Tue, 20 Jul 2021 13:31:55 +0530	[thread overview]
Message-ID: <CAOuPNLhti3tocN-_D7Q0QaAx5acHpb3AQyWaUKgQPNW3XWu58g@mail.gmail.com> (raw)
In-Reply-To: <1556211076.48404.1626763215205.JavaMail.zimbra@nod.at>

On Tue, 20 Jul 2021 at 12:10, Richard Weinberger <richard@nod.at> wrote:

> > Anyways, I will create a separate thread for dm-verity issue and keep
> > this thread still open for UBI image size issue.
> > We may use dm-verify for rootfs during booting, but still we need to
> > perform integrity check for other nand partitions and UBI volumes.
> >
> > So, instead of calculating the checksum for the entire partition, is
> > it possible to perform checksum only based on the image size ?
> > Right now, we are still exploring what are the best possible
> > mechanisms available for this.
>
> I still don't fully understand what you are trying to achieve.
> Is it about cryptographic integrity of your storage or detecting
> errors after the flashing process?
>
Yes, it is about md5 checksum verification for every partition to
check its integrity before updates.


> But let me advertise ubiblock a second time.
Sorry, I could not understand about the ubiblock request. Is it
possible to elaborate little more ?
We are already using squashfs on top of our UBI volumes (including
rootfs mounting).
This is the kernel command line we pass:
rootfstype=squashfs root=/dev/mtdblock44 ubi.mtd=40,0,30
And CONFIG_MTD_UBI_BLOCK=y is already enabled in our kernel.
Do we need to do something different for ubiblock ?

> If you place your squashfs on a UBI static volume, UBI knows the exact length and you can checksum it
> more easily.
Yes, we use squashfs on UBI volumes, but our volume type is still dynamic.
Also, you said, UBI knows the exact length, you mean the whole image length ?
How can we get this length at runtime ?
Also, how can we get the checksum of the entire UBI volume content
(ignoring the erased/empty/bad block content) ?

Or, you mean to say, the whole checksum logic is in-built inside the
UBI layer and users don't need to worry about the integrity at all ?


Thanks,
Pintu

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  reply	other threads:[~2021-07-20  8:02 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-16  6:42 MTD: How to get actual image size from MTD partition Pintu Agarwal
2021-07-16  6:42 ` Pintu Agarwal
2021-07-16  6:42 ` Pintu Agarwal
2021-07-16  7:16 ` Richard Weinberger
2021-07-16  7:16   ` Richard Weinberger
2021-07-16  7:16   ` Richard Weinberger
2021-07-16 15:41 ` Greg KH
2021-07-16 15:41   ` Greg KH
2021-07-16 15:41   ` Greg KH
2021-07-16 16:26   ` Richard Weinberger
2021-07-16 16:26     ` Richard Weinberger
2021-07-16 16:26     ` Richard Weinberger
2021-07-19  9:09     ` Pintu Agarwal
2021-07-19  9:09       ` Pintu Agarwal
2021-07-19  9:09       ` Pintu Agarwal
2021-07-19  9:28       ` Richard Weinberger
2021-07-19  9:28         ` Richard Weinberger
2021-07-19  9:28         ` Richard Weinberger
2021-07-20  6:17         ` Pintu Agarwal
2021-07-20  6:17           ` Pintu Agarwal
2021-07-20  6:17           ` Pintu Agarwal
2021-07-20  6:40           ` Richard Weinberger
2021-07-20  6:40             ` Richard Weinberger
2021-07-20  6:40             ` Richard Weinberger
2021-07-20  8:01             ` Pintu Agarwal [this message]
2021-07-20  8:01               ` Pintu Agarwal
2021-07-20  8:01               ` Pintu Agarwal
2021-07-21 20:54               ` Richard Weinberger
2021-07-21 20:54                 ` Richard Weinberger
2021-07-21 20:54                 ` Richard Weinberger
2021-07-22 11:10                 ` Pintu Agarwal
2021-07-22 11:10                   ` Pintu Agarwal
2021-07-22 11:10                   ` Pintu Agarwal
2021-07-27 21:16                   ` Richard Weinberger
2021-07-27 21:16                     ` Richard Weinberger
2021-07-27 21:16                     ` Richard Weinberger
2021-07-29 11:17                     ` Ezequiel Garcia
2021-07-29 11:17                       ` Ezequiel Garcia
2021-07-29 11:17                       ` Ezequiel Garcia
2021-07-29 11:45                       ` Richard Weinberger
2021-07-29 11:45                         ` Richard Weinberger
2021-07-29 11:45                         ` Richard Weinberger
2021-07-29 12:03                         ` Ezequiel Garcia
2021-07-29 12:03                           ` Ezequiel Garcia
2021-07-29 12:03                           ` Ezequiel Garcia
2021-07-29 17:11                           ` Pintu Agarwal
2021-07-29 17:11                             ` Pintu Agarwal
2021-07-29 17:11                             ` Pintu Agarwal
2021-08-20 18:24                             ` Pintu Agarwal
2021-08-20 18:24                               ` Pintu Agarwal
2021-08-20 18:24                               ` Pintu Agarwal
2021-08-22 14:21                               ` Ezequiel Garcia
2021-08-22 14:21                                 ` Ezequiel Garcia
2021-08-22 14:21                                 ` Ezequiel Garcia
2021-08-30 15:58                                 ` Pintu Agarwal
2021-08-30 15:58                                   ` Pintu Agarwal
2021-08-30 15:58                                   ` Pintu Agarwal
2021-10-29 16:12                                   ` Pintu Agarwal
2021-10-29 16:12                                     ` Pintu Agarwal
2021-10-29 16:12                                     ` Pintu Agarwal
2021-10-29 16:48                                     ` Ezequiel Garcia
2021-10-29 16:48                                       ` Ezequiel Garcia
2021-10-29 16:48                                       ` Ezequiel Garcia
2021-11-08 13:51                                       ` Pintu Agarwal
2021-11-08 13:51                                         ` Pintu Agarwal
2021-11-08 13:51                                         ` Pintu Agarwal
2021-11-12 13:58                                         ` Ezequiel Garcia
2021-11-12 13:58                                           ` Ezequiel Garcia
2021-11-12 13:58                                           ` Ezequiel Garcia

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=CAOuPNLhti3tocN-_D7Q0QaAx5acHpb3AQyWaUKgQPNW3XWu58g@mail.gmail.com \
    --to=pintu.ping@gmail.com \
    --cc=greg@kroah.com \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=phillip@squashfs.org.uk \
    --cc=richard@nod.at \
    --cc=sean@geanix.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.