On Sun, 27 Mar 2022 at 09:32, Alper Nebi Yasak <alpernebiya...@gmail.com> wrote: > > Binman can embed a copy of the image description into the images it > builds as a fdtmap entry, but it omits the /binman/<image-name> prefix > from the node paths while doing so. When reading an already-built image > file, entries are reconstructed using this fdtmap and their associated > nodes still lack that prefix. > > Some entries like fit and vblock create intermediate files whose names > are based on an entry unique name. This name is constructed from their > node's path by concatenating the parents with dots up to the binman > node, e.g. /binman/image/foo/bar becomes 'image.foo.bar'. > > However, we don't have this /binman/image prefix when replacing entries > in such an image. The /foo/bar entry we read when doing so erroneously > has the unique name of '/.foo.bar', causing permission errors when the > entry attempts to create files based on that. > > Fix the unique-name generation by stopping at the '/' node like how it > stops at the binman node. As the unique names are used as filenames, add > tests that check if they're safe to use as filenames. > > Signed-off-by: Alper Nebi Yasak <alpernebiya...@gmail.com> > --- > > tools/binman/entry.py | 2 +- > tools/binman/ftest.py | 31 ++++++++++++++++ > tools/binman/test/230_unique_names.dts | 34 ++++++++++++++++++ > tools/binman/test/231_unique_names_multi.dts | 38 ++++++++++++++++++++ > 4 files changed, 104 insertions(+), 1 deletion(-) > create mode 100644 tools/binman/test/230_unique_names.dts > create mode 100644 tools/binman/test/231_unique_names_multi.dts
Reviewed-by: Simon Glass <s...@chromium.org>