All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Dahl <ada@thorsis.com>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Torben Hohn <torben.hohn@linutronix.de>
Subject: Re: [PATCH 0/1] ubifs: support authentication without hmac
Date: Tue, 30 Jun 2020 16:36:12 +0200	[thread overview]
Message-ID: <2574588.zHiktFonDK@ada> (raw)
In-Reply-To: <CAFLxGvyqPB45hJ+_kejzs1-1m8XZ8QW-WyXyH+Jnvj9USZ+cEQ@mail.gmail.com>

Hello Richard,

thanks for asking back.

Am Dienstag, 30. Juni 2020, 15:36:28 CEST schrieb Richard Weinberger:
> On Mon, Jun 29, 2020 at 9:11 AM Richard Weinberger <richard@nod.at> wrote:
> > U-Boot choose the UBIFS way AFAICT.
> > 
> > But if you have your own minimal loader you can read from an UBI static
> > volume with a few lines of C (~200 LoC). This is what I see/use most of
> > the time. Using static volumes in U-Boot is also possible, IIRC just use
> > "ubi read".
> > 
> > From http://www.linux-mtd.infradead.org/doc/ubi.html#L_overview:
> > """
> > There are 2 types of UBI volumes: dynamic volumes and static volumes.
> > Static volumes are read-only and their contents are protected by CRC-32
> > checksums, while dynamic volumes are read-write and the upper layers
> > (e.g., a file-system) are responsible for ensuring data integrity.
> > 
> > Static volumes are typically used for the kernel, initramfs, and dtb.
> > Larger static volumes may incur a significant penalty when opening, as
> > the CRC-32 needs to be calculated at this time. If you are looking to use
> > static volumes for anything besides the kernel, initramfs, or dtb you are
> > likely doing something wrong and would be better off using a dynamic
> > volume instead. """
> 
> Did this and Wolfgang's input help?

Yes, it did.  I see the benefits of static UBI volumes, and I wish we had 
known this for our projects like 10 years ago.  However I also appreciated 
Wolfgang's input, it's basically what we do with more recent projects.  The 
possibility to easily upgrade kernel image and/or dts speeds up development a 
lot and causes less headaches on system upgrade.

Greets
Alex




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

  reply	other threads:[~2020-06-30 14:37 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 15:59 [PATCH 0/1] ubifs: support authentication without hmac Torben Hohn
2020-06-25 15:59 ` [PATCH 1/1] ubifs: support authentication, for ro mount, when no key is given Torben Hohn
2020-06-26  4:31   ` Sascha Hauer
2020-06-26  7:27     ` Torben Hohn
2020-06-26  7:53       ` Richard Weinberger
2020-06-26  8:10       ` Sascha Hauer
2020-06-26  9:39         ` Torben Hohn
2020-06-26  8:09 ` [PATCH 0/1] ubifs: support authentication without hmac Richard Weinberger
2020-06-29  6:46   ` Alexander Dahl
2020-06-29  7:04     ` Richard Weinberger
2020-06-29  7:48       ` Wolfgang Denk
2020-06-29  7:51         ` Richard Weinberger
2020-06-30  5:50           ` Wolfgang Denk
2020-06-30 13:36       ` Richard Weinberger
2020-06-30 14:36         ` Alexander Dahl [this message]
2020-06-26 11:29 ` [PATCH v2 0/4] " Torben Hohn
2020-06-26 11:29   ` [PATCH v2 1/4] ubifs: move #include "debug.h" above auth.c Torben Hohn
2020-06-26 11:29   ` [PATCH v2 2/4] ubifs: support authentication, for ro mount, when no key is given Torben Hohn
2020-06-26 11:29   ` [PATCH v2 3/4] ubifs: sprinkle ubifs_assert(c, !c->ro_mount) in hmac auth Torben Hohn
2020-06-26 11:29   ` [PATCH v2 4/4] ubifs: prevent remounting rw when no hmac key was given Torben Hohn
2020-06-26 12:27     ` Richard Weinberger
2020-06-29  8:53       ` Torben Hohn
2020-06-29 10:52         ` Richard Weinberger
2020-06-26 14:16   ` [PATCH v2 0/4] ubifs: support authentication without hmac Richard Weinberger
2020-06-26 14:36     ` Richard Weinberger
2020-06-29  9:13       ` Torben Hohn
2020-06-29  9:07     ` Torben Hohn
2020-06-29 10:46       ` Richard Weinberger
2020-07-02 14:40         ` Thomas Gleixner
2020-07-02 15:00           ` Richard Weinberger
2020-07-02 18:48             ` Thomas Gleixner
2020-07-02 19:03               ` Richard Weinberger
2020-07-03  8:16                 ` bigeasy
2020-07-03  8:20                   ` Richard Weinberger
2020-07-03  9:12                 ` Thomas Gleixner

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=2574588.zHiktFonDK@ada \
    --to=ada@thorsis.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard.weinberger@gmail.com \
    --cc=richard@nod.at \
    --cc=s.hauer@pengutronix.de \
    --cc=torben.hohn@linutronix.de \
    /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.