[U-Boot] [PATCH v6 3/3] GPT: provide commands to selectively rename partitions

[Tom Rini]

On Sun, Jun 25, 2017 at 02:54:56PM -0700, Alison Chaiken wrote:
> On Sun, Jun 18, 2017 at 4:03 AM, Wolfgang Denk <wd at denx.de> wrote:
> 
> > Dear Alison,
> >
> > In message <CAOuSAjdHerD7iWSwv5HQmx07nALRHschnH5=XToNEZDqA9JsvQ at mail.
> > gmail.com> you wrote:
> > >
> > > The idea behind the 'swap' mode is that a storage device can have two
> > sets
> > > of partitions, one set all named 'primary' and one set all named
> > 'backup'.
> > >   The software updater in userspace can then simply rename the partitions
> > > with sgdisk in order to pick the new image.   The swap mode changes the
> > > whole set of labels at once, so there's little chance of being
> > interrupted.
> >
> > It's still a sequential, non-atomic operation, and "little chance"
> > is exactly the places where Murphy likes to hit you.
> >
> > > One additional note: the last version I posted worked fine for the
> > sandbox,
> > > but wouldn't link for an ARM target with the Linaro toolchain, as the
> > > linker couldn't find atoi().   I guess the libc for the x86 compiler
> > > includes it.   To test on ARM, I copied in simple_atoi() from
> > > lib/vsprintf.c, but assuredly that is an ugly solution.    Does anyone
> > have
> > > a better idea to solve this problem?
> >
> > U-Boot should always be self-contained and not link regular library
> > code from the tool chain.
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> 
> I'm about to submit a new version of the patches that adopts Wolfgang's and
> Tom's suggestions about replacing atoi().
> 
> Regarding the atomicity of 'gpt swap, the point is that 'gpt swap' first
> modifies the names in an in-memory
> data structure, and then uses the existing 'gpt write' functionality to
> change the actual partition table stored on the device.  Thus,
> interruption of the new command is low-risk, as interruption of the
> modification of the new data structure has no persistent effect, and
> the risk associated with 'gpt write' is the same as always.
> 
> By the way, in the course of testing an earlier version of this patch
> series, I noticed that 'gpt write' and 'gpt verify' segv if presented with
> a non-null-terminated partitions string.  It's the strlen function in lib
> that actually generates an error. I haven't yet quite figured out what the
> best solution to the problem is: should strlen() itself be modified, or is
> it enough to test in gpt.c?   The right solution is not to present the
> commands with poorly formed strings, but it's easy to do so.

It is likely this particular bug is one of many in the class of using
strlen when we cannot really be certain of well formatted input /
buffer, sadly.  So a fix to gpt.c and if you're so inclined, a git grep
around for other likely cases.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170626/e271ce2a/attachment.sig>