All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Matt Fleming
	<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Leif Lindholm
	<leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCH 3/3] efi/libstub: fix deletion of FDT memory nodes
Date: Wed, 07 Oct 2015 14:04:55 -0400	[thread overview]
Message-ID: <1444241095.25536.10.camel@redhat.com> (raw)
In-Reply-To: <CAKv+Gu-ZgLOxqL3CWCpR=Ae-BHVExFRVj4d5nEdz3tPK1a-FGw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, 2015-10-07 at 18:56 +0100, Ard Biesheuvel wrote:
> On 7 October 2015 at 17:02, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On 7 October 2015 at 16:49, Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > On Wed, 2015-10-07 at 09:35 +0100, Ard Biesheuvel wrote:
> > > > This fixes two issues with the EFI libstub code that removes the memory
> > > > nodes from the FDT:
> > > > a) fdt_del_node() invalidates the iterator, so we should restart from the
> > > >    top after calling it;
> > > > b) use fixed length of 6 when matching against 'memory' using strncmp(),
> > > >    since otherwise, substrings like 'm' or 'mem' could match as well.
> > > > 
> > > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > > ---
> > > >  drivers/firmware/efi/libstub/fdt.c | 5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
> > > > index 0ef16923b4f0..2c7d09936479 100644
> > > > --- a/drivers/firmware/efi/libstub/fdt.c
> > > > +++ b/drivers/firmware/efi/libstub/fdt.c
> > > > @@ -200,6 +200,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
> > > >        * Delete any memory nodes present. We must delete nodes which
> > > >        * early_init_dt_scan_memory may try to use.
> > > >        */
> > > > +restart:
> > > >       prev = 0;
> > > >       for (;;) {
> > > >               const char *type;
> > > > @@ -210,9 +211,9 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
> > > >                       break;
> > > > 
> > > >               type = fdt_getprop(fdt, node, "device_type", &len);
> > > > -             if (type && strncmp(type, "memory", len) == 0) {
> > > > +             if (type && strncmp(type, "memory", 6) == 0) {
> > > 
> > > I see what you're trying to fix here, but I think using 6 is wrong
> > > also. A plain strcmp() would work as long as property is a string.
> > > 
> > 
> > That is what Leif suggested as well, but it pulls in yet another
> > string function into the stub, so I tried to avoid it. I think this
> > particular case is safe, since the property names are in the string
> > table, which is after the nodes in the DTB structure, so 'type' is
> > guaranteed not to point right before the end of a mapped region.
> > 
> 
> ... or is your concern about matching on longer strings that only
> start with 'memory'?

Yes. And the old code would match shorted strings than "memory".

> 
> I guess it makes sense to use strcmp() after all, only arm64 does not
> have an asm implementation, so under the stricter rules that I am
> proposing for fencing off the EFI stub code from the kernel proper, I
> will have to go and add a strcmp() implementation to
> drivers/firmware/efi/libstub/string.c.
> 
> But still better than this, I guess ...

You could also add an explicit length comparison but adding strcmp
seems pretty reasonable.

> 
> 
> > > 
> > > >                       fdt_del_node(fdt, node);
> > > > -                     continue;
> > > > +                     goto restart;
> > > >               }
> > > > 
> > > >               prev = node;
> > > 
> > > Maybe do:
> > > 
> > >                 if (type && strncmp(type, "memory", len) == 0) {
> > >                         fdt_del_node(fdt, node);
> > > -                       continue;
> > > -               }
> > > -
> > > -               prev = node;
> > > +                       prev = NULL;
> > > +               } else
> > > +                       prev = node;
> > >         }
> > > 
> > > 
> > > instead of adding a goto.
> > > 
> > 
> > Yes, that is actually better. Thanks.

  parent reply	other threads:[~2015-10-07 18:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-07  8:35 [PATCH 0/3] UEFI stub FDT handling fixes Ard Biesheuvel
     [not found] ` <1444206929-13374-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-10-07  8:35   ` [PATCH 1/3] efi/libstub: move FDT sanity check out of allocation loop Ard Biesheuvel
     [not found]     ` <1444206929-13374-2-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-11-17 11:47       ` Mark Rutland
2015-11-17 12:09         ` Ard Biesheuvel
2015-10-07  8:35   ` [PATCH 2/3] efi/libstub: sanity check the /reserved-memory DT node Ard Biesheuvel
2015-10-07  8:35   ` [PATCH 3/3] efi/libstub: fix deletion of FDT memory nodes Ard Biesheuvel
     [not found]     ` <1444206929-13374-4-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-10-07 15:49       ` Mark Salter
     [not found]         ` <1444232962.25536.7.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-10-07 16:02           ` Ard Biesheuvel
     [not found]             ` <CAKv+Gu_0haKU-nBB6t+iWeLteLDHz8YLOByfo7fWsrAr7txXpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-07 17:56               ` Ard Biesheuvel
     [not found]                 ` <CAKv+Gu-ZgLOxqL3CWCpR=Ae-BHVExFRVj4d5nEdz3tPK1a-FGw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-07 17:57                   ` Ard Biesheuvel
2015-10-07 18:04                   ` Mark Salter [this message]
2015-10-08  2:25   ` [PATCH 0/3] UEFI stub FDT handling fixes Roy Franz
     [not found]     ` <CAFECyb9MdmH=0_9JA-1c=-ggTGLR_A8d0p5T2NUwGGzhDc_XAA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-08  6:02       ` Ard Biesheuvel

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=1444241095.25536.10.camel@redhat.com \
    --to=msalter-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /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.