linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding
Date: Fri, 20 Mar 2015 15:25:19 +0000	[thread overview]
Message-ID: <20150320152518.GI14766@leverpostej> (raw)
In-Reply-To: <550B3F2E.2000303@gmail.com>

> > You can already check the hash if you want to check that you copies the
> > correct version; which is better than trusting an arbitrary string,
> > because if anything fiddles with the DTB it will change.
> 
> I'm confused.  If the bootloader fiddles with the DTB then I can not
> compare a hash of the DTB from the build host to a hash of the DTB
> on the target.  Of course the bootloader can also fiddle with the
> dtb-info if it wants to .  Bootloaders do what they want to do.  :-(

This is a fundamental issue with the approach: if bootloaders  mess with
the DTB, then the provenance information is at best misleading.

If bootloaders don't mess with the DTB, then a hash gives you reliable
provenance information, provided you have a DB of the hashes of DTBs
you've shipped. If you're already in the habit of distributing binaries
that should be fine, and if you're not then it presumably doesn't matter
anyway.

> >>>> +dtb-path
> >>>> +	The build directory relative path of the DTB.
> >>>> +
> >>>> +dts-path
> >>>> +	The absolute path of the .dts file compiled to create the DTB.
> >>>
> >>> Why do you need the DTB path?
> >>
> >> Paranoia.  Even if not probable, one could build different DTBs from
> >> the same .dts.
> > 
> > One could also build the same DTB from two different dts files, no?
> > 
> > You could build the same dtb from the same dts, but with some arbitrary
> > things changed, such that the at either end of the process is
> > irrelevant. Personally, I end up doing this a fair amount when testing.
> 
> Exactly.  And the dtb version number will change when the DTB is
> recompiled.

Consider having to work around stale object issues in the build system
with git clean -fdx or similar. While unfortunate, this is sometimes
necessary. Due to this, I build two different DTBs with exactly the same
"version".

If you need to tell these apart, you can do that by hash. You don't need
the "version" to do so.

(and yes, I am aware that the same is true of the kernel).

> >>> Why do these differ w.r.t. absolute/relative?
> >>
> >> Those are the forms of the path that are present in the build
> >> system.  If there is a good reason to change one of them to the
> >> other form, I could add the extra complexity to massage the path.
> >>
> >>>
> >>> Why would you _ever_ need an absolute path!?
> >>
> >> The absolute path tells you which source repository contained the source.
> > 
> > Except that the absolute path is realtive to the machine it was built
> > on, so doesn't actually help.
> 
> Different use cases for different people.

Given the reservations that have been expressed so far, it sounds like
the set of negative use cases is larger than the set of positives.

> In all cases the absolute path includes the relative path, so it is
> just a case of extra information.  The relative portion of the path
> is still useful for anyone who wants to know what .dts was used in
> the build, even if they don't have access to the build machine.
> (They do have access to the gpl v2 source code, which will have
> at least the relative portion of the path because that is needed
> to build the DTB from the .dts.)
> 
> The extra information in the absolute path could be useful to a
> build engineer, a distro engineer, or a support person for a distro.
> Or could just be useless extra info.

I very much suspect it will end up being the latter. For example I've
seen various iterations of certain FW ship with all-zero ID numbers, for
which the use-cases of said ID numbers are exactly those you mention
above.

As far as I can see, the only consistent and sane way to identify a
binary object is by its hash, which for obvious reasons cannot be
encoded within itself (though can be computed consistently).

> > On various machines I have folders called /home/mark/src/linux. These
> > are not the same folder. If I gave you a DTB that told you it was from
> > /home/mark/src/linux/arch/arm64/boot/dts/vendor/foo.dts, you would have
> > difficulty acquiring that precise file.
> 
> If you distributed the DTB to me under the gpl v2 then you have also
> either distributed the source to me or offered to make it available
> to me.

That being the case you don't care about the fields; we've established
that they're meaningless to the end user.

Were I to have distributed files to you, I would have archived the
relevant build (with source, config, and so on). I can look up what I've
distributed to you and hand you the source without needing additional
properties in the DTB.

Mark.

  reply	other threads:[~2015-03-20 15:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19  3:29 [patch 0/7] dt: dtb version: add version info to dtb Frank Rowand
2015-03-19  3:31 ` [patch 1/7] dt: dtb version: consolidate documentation of chosen node bindings Frank Rowand
2015-03-19 13:40   ` Mark Rutland
2015-03-19  3:33 ` [patch 2/7] dt: dtb version: document chosen/dtb-info node binding Frank Rowand
2015-03-19 13:23   ` Rob Herring
2015-03-19 16:42     ` Frank Rowand
2015-03-19 18:41     ` Russell King - ARM Linux
2015-03-19 18:53       ` Mark Rutland
2015-03-19 19:01       ` Frank Rowand
2015-03-19 19:32         ` Russell King - ARM Linux
2015-03-19 20:44           ` Frank Rowand
2015-03-20 14:42             ` Mark Rutland
2015-03-19 13:49   ` Mark Rutland
2015-03-19 17:02     ` Frank Rowand
2015-03-19 17:23       ` Geert Uytterhoeven
2015-03-19 19:12       ` Mark Rutland
2015-03-19 21:27         ` Frank Rowand
2015-03-20 15:25           ` Mark Rutland [this message]
2015-03-19 17:37   ` Frank Rowand
2015-03-19  3:34 ` [patch 3/7] dt: dtb version: arm dts Makefile Frank Rowand
2015-03-19  3:36 ` [patch 4/7] dt: dtb version: kernel Makefile Frank Rowand
2015-03-19  3:38 ` [patch 5/7] dt: dtb version: kbuild scripts Frank Rowand
2015-03-19  3:39 ` [patch 6/7] dt: dtb version: dtsi files Frank Rowand
2015-03-19 18:46   ` Sascha Hauer
2015-03-19  3:41 ` [patch 7/7] dt: dtb version: report dtb info Frank Rowand
2015-03-19  8:12 ` [patch 0/7] dt: dtb version: add version info to dtb Gregory CLEMENT
2015-03-19 17:05   ` Frank Rowand
2015-03-20 13:46 ` Rob Herring
2015-03-20 19:14   ` Uwe Kleine-König

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=20150320152518.GI14766@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --subject='Re: [patch 2/7] dt: dtb version: document chosen/dtb-info node binding' \
    /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

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).