[PATCH 0/2] spapr/nvram: Fix QEMU crash

[PATCH 0/2] spapr/nvram: Fix QEMU crash

[Greg Kurz]

This series fixes the following crash:

$ qemu-system-ppc64 -M pseries $(for ((x=0;x<128;x++)); do \
  echo -n " -prom-env "$(for ((y=0;y<1024;y++)); do echo -n x ; done) ; \
  done) # this requires ~128 Kib
malloc(): corrupted top size
Aborted (core dumped)

This also affects g3beige and mac99 machine types, and probably some
sparc/sparc64 machine types as well, but I prefer to leave the fixing
to knowledgeable people.

---

Greg Kurz (2):
      nvram: Add dry_run argument to chrp_nvram_create_system_partition()
      spapr/nvram: Allocate enough space for all -prom-env options


 hw/nvram/chrp_nvram.c         |   35 +++++++++++++++++++++++------------
 hw/nvram/mac_nvram.c          |    2 +-
 hw/nvram/spapr_nvram.c        |    7 ++++++-
 hw/sparc/sun4m.c              |    2 +-
 hw/sparc64/sun4u.c            |    2 +-
 include/hw/nvram/chrp_nvram.h |    3 ++-
 6 files changed, 34 insertions(+), 17 deletions(-)

--
Greg

[PATCH 1/2] nvram: Add dry_run argument to chrp_nvram_create_system_partition()

[Greg Kurz]

Since commit 55d9950aaa8e ("nvram: Introduce helper functions for CHRP
"system" and "free space" partitions") it is possible to pre-initialize
a "system" partition in the NVRAM with the data passed to all -prom-env
parameters on the QEMU command line.

Unfortunately, this doesn't take the total size of the data into account
and chrp_nvram_create_system_partition() may crash at some point if the
caller hasn't allocated enough space.

Add a dry_run argument that causes chrp_nvram_create_system_partition()
to only return the size of the partition without actually copying data
into it. This can be used by callers to allocate enough memory.

Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/nvram/chrp_nvram.c         |   35 +++++++++++++++++++++++------------
 hw/nvram/mac_nvram.c          |    2 +-
 hw/nvram/spapr_nvram.c        |    3 ++-
 hw/sparc/sun4m.c              |    2 +-
 hw/sparc64/sun4u.c            |    2 +-
 include/hw/nvram/chrp_nvram.h |    3 ++-
 6 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/hw/nvram/chrp_nvram.c b/hw/nvram/chrp_nvram.c
index d969f267048e..548cb8b5c97a 100644
--- a/hw/nvram/chrp_nvram.c
+++ b/hw/nvram/chrp_nvram.c
@@ -24,37 +24,47 @@
 #include "hw/nvram/chrp_nvram.h"
 #include "sysemu/sysemu.h"
 
-static int chrp_nvram_set_var(uint8_t *nvram, int addr, const char *str)
+static int chrp_nvram_set_var(uint8_t *nvram, int addr, const char *str,
+                              bool dry_run)
 {
     int len;
 
     len = strlen(str) + 1;
-    memcpy(&nvram[addr], str, len);
-
+    if (!dry_run) {
+        memcpy(&nvram[addr], str, len);
+    }
     return addr + len;
 }
 
 /**
  * Create a "system partition", used for the Open Firmware
- * environment variables.
+ * environment variables. If @dry_run is false, only returns
+ * the size of the partition but don't write the data.
  */
-int chrp_nvram_create_system_partition(uint8_t *data, int min_len)
+int chrp_nvram_create_system_partition(uint8_t *data, int min_len, bool dry_run)
 {
     ChrpNvramPartHdr *part_header;
     unsigned int i;
     int end;
 
-    part_header = (ChrpNvramPartHdr *)data;
-    part_header->signature = CHRP_NVPART_SYSTEM;
-    pstrcpy(part_header->name, sizeof(part_header->name), "system");
+    assert(data || dry_run);
+
+    if (!dry_run) {
+        part_header = (ChrpNvramPartHdr *)data;
+        part_header->signature = CHRP_NVPART_SYSTEM;
+        pstrcpy(part_header->name, sizeof(part_header->name), "system");
+    }
 
     end = sizeof(ChrpNvramPartHdr);
     for (i = 0; i < nb_prom_envs; i++) {
-        end = chrp_nvram_set_var(data, end, prom_envs[i]);
+        end = chrp_nvram_set_var(data, end, prom_envs[i], dry_run);
     }
 
     /* End marker */
-    data[end++] = '\0';
+    if (!dry_run) {
+        data[end] = '\0';
+    }
+    end++;
 
     end = (end + 15) & ~15;
     /* XXX: OpenBIOS is not able to grow up a partition. Leave some space for
@@ -62,8 +72,9 @@ int chrp_nvram_create_system_partition(uint8_t *data, int min_len)
     if (end < min_len) {
         end = min_len;
     }
-    chrp_nvram_finish_partition(part_header, end);
-
+    if (!dry_run) {
+        chrp_nvram_finish_partition(part_header, end);
+    }
     return end;
 }
 
diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
index beec1c4e4d11..4396f893f14a 100644
--- a/hw/nvram/mac_nvram.c
+++ b/hw/nvram/mac_nvram.c
@@ -141,7 +141,7 @@ static void pmac_format_nvram_partition_of(MacIONVRAMState *nvr, int off,
 
     /* OpenBIOS nvram variables partition */
     sysp_end = chrp_nvram_create_system_partition(&nvr->data[off],
-                                                  DEF_SYSTEM_SIZE) + off;
+                                                  DEF_SYSTEM_SIZE, false) + off;
 
     /* Free space partition */
     chrp_nvram_create_free_partition(&nvr->data[sysp_end], len - sysp_end);
diff --git a/hw/nvram/spapr_nvram.c b/hw/nvram/spapr_nvram.c
index 15d08281d411..992b818d34e7 100644
--- a/hw/nvram/spapr_nvram.c
+++ b/hw/nvram/spapr_nvram.c
@@ -188,7 +188,8 @@ static void spapr_nvram_realize(SpaprVioDevice *dev, Error **errp)
         }
     } else if (nb_prom_envs > 0) {
         /* Create a system partition to pass the -prom-env variables */
-        chrp_nvram_create_system_partition(nvram->buf, MIN_NVRAM_SIZE / 4);
+        chrp_nvram_create_system_partition(nvram->buf, MIN_NVRAM_SIZE / 4,
+                                           false);
         chrp_nvram_create_free_partition(&nvram->buf[MIN_NVRAM_SIZE / 4],
                                          nvram->size - MIN_NVRAM_SIZE / 4);
     }
diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c
index 9be930415f8e..61804ccd4286 100644
--- a/hw/sparc/sun4m.c
+++ b/hw/sparc/sun4m.c
@@ -143,7 +143,7 @@ static void nvram_init(Nvram *nvram, uint8_t *macaddr,
     memset(image, '\0', sizeof(image));
 
     /* OpenBIOS nvram variables partition */
-    sysp_end = chrp_nvram_create_system_partition(image, 0);
+    sysp_end = chrp_nvram_create_system_partition(image, 0, false);
 
     /* Free space partition */
     chrp_nvram_create_free_partition(&image[sysp_end], 0x1fd0 - sysp_end);
diff --git a/hw/sparc64/sun4u.c b/hw/sparc64/sun4u.c
index 9e30203dcc44..2409e739e81b 100644
--- a/hw/sparc64/sun4u.c
+++ b/hw/sparc64/sun4u.c
@@ -136,7 +136,7 @@ static int sun4u_NVRAM_set_params(Nvram *nvram, uint16_t NVRAM_size,
     memset(image, '\0', sizeof(image));
 
     /* OpenBIOS nvram variables partition */
-    sysp_end = chrp_nvram_create_system_partition(image, 0);
+    sysp_end = chrp_nvram_create_system_partition(image, 0, false);
 
     /* Free space partition */
     chrp_nvram_create_free_partition(&image[sysp_end], 0x1fd0 - sysp_end);
diff --git a/include/hw/nvram/chrp_nvram.h b/include/hw/nvram/chrp_nvram.h
index 09941a9be454..1d32dbf61331 100644
--- a/include/hw/nvram/chrp_nvram.h
+++ b/include/hw/nvram/chrp_nvram.h
@@ -50,7 +50,8 @@ chrp_nvram_finish_partition(ChrpNvramPartHdr *header, uint32_t size)
     header->checksum = sum & 0xff;
 }
 
-int chrp_nvram_create_system_partition(uint8_t *data, int min_len);
+int chrp_nvram_create_system_partition(uint8_t *data, int min_len,
+                                       bool dry_run);
 int chrp_nvram_create_free_partition(uint8_t *data, int len);
 
 #endif

[PATCH 2/2] spapr/nvram: Allocate enough space for all -prom-env options

[Greg Kurz]

Since commit 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to
support the -prom-env parameter"), pseries machines can pre-initialize
the "system" partition in the NVRAM with the data passed to all -prom-env
parameters on the QEMU command line.

In this cases it is assumed that all the data fits in 64 KiB, but the user
can easily pass more and crash QEMU:

$ qemu-system-ppc64 -M pseries $(for ((x=0;x<128;x++)); do \
  echo -n " -prom-env "$(for ((y=0;y<1024;y++)); do echo -n x ; done) ; \
  done) # this requires ~128 Kib
malloc(): corrupted top size
Aborted (core dumped)

Call chrp_nvram_create_system_partition() first with its recently added
parameter dry_run set to false, to know the required size and allocate
the NVRAM buffer accordingly.

Fixes: 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameter")
Signed-off-by: Greg Kurz <groug@kaod.org>
---
 hw/nvram/spapr_nvram.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/hw/nvram/spapr_nvram.c b/hw/nvram/spapr_nvram.c
index 992b818d34e7..1b74bec6200a 100644
--- a/hw/nvram/spapr_nvram.c
+++ b/hw/nvram/spapr_nvram.c
@@ -165,6 +165,10 @@ static void spapr_nvram_realize(SpaprVioDevice *dev, Error **errp)
         if (ret < 0) {
             return;
         }
+    } else if (nb_prom_envs > 0) {
+        nvram->size = chrp_nvram_create_system_partition(NULL,
+                                                         MIN_NVRAM_SIZE / 4,
+                                                         true);
     } else {
         nvram->size = DEFAULT_NVRAM_SIZE;
     }

Re: [PATCH 2/2] spapr/nvram: Allocate enough space for all -prom-env options

[Laurent Vivier]

On 11/08/2020 17:30, Greg Kurz wrote:
> Since commit 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to
> support the -prom-env parameter"), pseries machines can pre-initialize
> the "system" partition in the NVRAM with the data passed to all -prom-env
> parameters on the QEMU command line.
> 
> In this cases it is assumed that all the data fits in 64 KiB, but the user
> can easily pass more and crash QEMU:
> 
> $ qemu-system-ppc64 -M pseries $(for ((x=0;x<128;x++)); do \
>   echo -n " -prom-env "$(for ((y=0;y<1024;y++)); do echo -n x ; done) ; \
>   done) # this requires ~128 Kib
> malloc(): corrupted top size
> Aborted (core dumped)
> 
> Call chrp_nvram_create_system_partition() first with its recently added
> parameter dry_run set to false, to know the required size and allocate
> the NVRAM buffer accordingly.
> 
> Fixes: 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameter")
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  hw/nvram/spapr_nvram.c |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/hw/nvram/spapr_nvram.c b/hw/nvram/spapr_nvram.c
> index 992b818d34e7..1b74bec6200a 100644
> --- a/hw/nvram/spapr_nvram.c
> +++ b/hw/nvram/spapr_nvram.c
> @@ -165,6 +165,10 @@ static void spapr_nvram_realize(SpaprVioDevice *dev, Error **errp)
>          if (ret < 0) {
>              return;
>          }
> +    } else if (nb_prom_envs > 0) {
> +        nvram->size = chrp_nvram_create_system_partition(NULL,
> +                                                         MIN_NVRAM_SIZE / 4,
> +                                                         true);

I think this will break the migration: the prom-env parameters can be on
the source side without being on the dest side. And so the pram size
will differ and the migration will fail.

Thanks,
Laurent

Re: [PATCH 2/2] spapr/nvram: Allocate enough space for all -prom-env options

[Greg Kurz]

On Tue, 11 Aug 2020 18:05:21 +0200
Laurent Vivier <lvivier@redhat.com> wrote:

> On 11/08/2020 17:30, Greg Kurz wrote:
> > Since commit 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to
> > support the -prom-env parameter"), pseries machines can pre-initialize
> > the "system" partition in the NVRAM with the data passed to all -prom-env
> > parameters on the QEMU command line.
> > 
> > In this cases it is assumed that all the data fits in 64 KiB, but the user
> > can easily pass more and crash QEMU:
> > 
> > $ qemu-system-ppc64 -M pseries $(for ((x=0;x<128;x++)); do \
> >   echo -n " -prom-env "$(for ((y=0;y<1024;y++)); do echo -n x ; done) ; \
> >   done) # this requires ~128 Kib
> > malloc(): corrupted top size
> > Aborted (core dumped)
> > 
> > Call chrp_nvram_create_system_partition() first with its recently added
> > parameter dry_run set to false, to know the required size and allocate
> > the NVRAM buffer accordingly.
> > 
> > Fixes: 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameter")
> > Signed-off-by: Greg Kurz <groug@kaod.org>
> > ---
> >  hw/nvram/spapr_nvram.c |    4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/hw/nvram/spapr_nvram.c b/hw/nvram/spapr_nvram.c
> > index 992b818d34e7..1b74bec6200a 100644
> > --- a/hw/nvram/spapr_nvram.c
> > +++ b/hw/nvram/spapr_nvram.c
> > @@ -165,6 +165,10 @@ static void spapr_nvram_realize(SpaprVioDevice *dev, Error **errp)
> >          if (ret < 0) {
> >              return;
> >          }
> > +    } else if (nb_prom_envs > 0) {
> > +        nvram->size = chrp_nvram_create_system_partition(NULL,
> > +                                                         MIN_NVRAM_SIZE / 4,
> > +                                                         true);
> 
> I think this will break the migration: the prom-env parameters can be on
> the source side without being on the dest side. And so the pram size

Huh ? Migration mandates to have the same arguments on the command line,
and libvirt buys us that AFAIK or am I missing something ?

> will differ and the migration will fail.
> 
> Thanks,
> Laurent
> 

Re: [PATCH 2/2] spapr/nvram: Allocate enough space for all -prom-env options

[Laurent Vivier]

On 11/08/2020 18:36, Greg Kurz wrote:
> On Tue, 11 Aug 2020 18:05:21 +0200
> Laurent Vivier <lvivier@redhat.com> wrote:
> 
>> On 11/08/2020 17:30, Greg Kurz wrote:
>>> Since commit 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to
>>> support the -prom-env parameter"), pseries machines can pre-initialize
>>> the "system" partition in the NVRAM with the data passed to all -prom-env
>>> parameters on the QEMU command line.
>>>
>>> In this cases it is assumed that all the data fits in 64 KiB, but the user
>>> can easily pass more and crash QEMU:
>>>
>>> $ qemu-system-ppc64 -M pseries $(for ((x=0;x<128;x++)); do \
>>>   echo -n " -prom-env "$(for ((y=0;y<1024;y++)); do echo -n x ; done) ; \
>>>   done) # this requires ~128 Kib
>>> malloc(): corrupted top size
>>> Aborted (core dumped)
>>>
>>> Call chrp_nvram_create_system_partition() first with its recently added
>>> parameter dry_run set to false, to know the required size and allocate
>>> the NVRAM buffer accordingly.
>>>
>>> Fixes: 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameter")
>>> Signed-off-by: Greg Kurz <groug@kaod.org>
>>> ---
>>>  hw/nvram/spapr_nvram.c |    4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/hw/nvram/spapr_nvram.c b/hw/nvram/spapr_nvram.c
>>> index 992b818d34e7..1b74bec6200a 100644
>>> --- a/hw/nvram/spapr_nvram.c
>>> +++ b/hw/nvram/spapr_nvram.c
>>> @@ -165,6 +165,10 @@ static void spapr_nvram_realize(SpaprVioDevice *dev, Error **errp)
>>>          if (ret < 0) {
>>>              return;
>>>          }
>>> +    } else if (nb_prom_envs > 0) {
>>> +        nvram->size = chrp_nvram_create_system_partition(NULL,
>>> +                                                         MIN_NVRAM_SIZE / 4,
>>> +                                                         true);
>>
>> I think this will break the migration: the prom-env parameters can be on
>> the source side without being on the dest side. And so the pram size
> 
> Huh ? Migration mandates to have the same arguments on the command line,
> and libvirt buys us that AFAIK or am I missing something ?

It's not true for all the arguments: take for instance the blockdev, the
chardev, the netdev, vnc,  ... I think it's true only for parameters
that define the devices, the machine. And until now for prom-env it was
not the case, look at the migration-test test case.

Thanks,
Laurent

Re: [PATCH 2/2] spapr/nvram: Allocate enough space for all -prom-env options

[Greg Kurz]

On Tue, 11 Aug 2020 19:27:50 +0200
Laurent Vivier <lvivier@redhat.com> wrote:

> On 11/08/2020 18:36, Greg Kurz wrote:
> > On Tue, 11 Aug 2020 18:05:21 +0200
> > Laurent Vivier <lvivier@redhat.com> wrote:
> > 
> >> On 11/08/2020 17:30, Greg Kurz wrote:
> >>> Since commit 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to
> >>> support the -prom-env parameter"), pseries machines can pre-initialize
> >>> the "system" partition in the NVRAM with the data passed to all -prom-env
> >>> parameters on the QEMU command line.
> >>>
> >>> In this cases it is assumed that all the data fits in 64 KiB, but the user
> >>> can easily pass more and crash QEMU:
> >>>
> >>> $ qemu-system-ppc64 -M pseries $(for ((x=0;x<128;x++)); do \
> >>>   echo -n " -prom-env "$(for ((y=0;y<1024;y++)); do echo -n x ; done) ; \
> >>>   done) # this requires ~128 Kib
> >>> malloc(): corrupted top size
> >>> Aborted (core dumped)
> >>>
> >>> Call chrp_nvram_create_system_partition() first with its recently added
> >>> parameter dry_run set to false, to know the required size and allocate
> >>> the NVRAM buffer accordingly.
> >>>
> >>> Fixes: 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameter")
> >>> Signed-off-by: Greg Kurz <groug@kaod.org>
> >>> ---
> >>>  hw/nvram/spapr_nvram.c |    4 ++++
> >>>  1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/hw/nvram/spapr_nvram.c b/hw/nvram/spapr_nvram.c
> >>> index 992b818d34e7..1b74bec6200a 100644
> >>> --- a/hw/nvram/spapr_nvram.c
> >>> +++ b/hw/nvram/spapr_nvram.c
> >>> @@ -165,6 +165,10 @@ static void spapr_nvram_realize(SpaprVioDevice *dev, Error **errp)
> >>>          if (ret < 0) {
> >>>              return;
> >>>          }
> >>> +    } else if (nb_prom_envs > 0) {
> >>> +        nvram->size = chrp_nvram_create_system_partition(NULL,
> >>> +                                                         MIN_NVRAM_SIZE / 4,
> >>> +                                                         true);
> >>
> >> I think this will break the migration: the prom-env parameters can be on
> >> the source side without being on the dest side. And so the pram size
> > 
> > Huh ? Migration mandates to have the same arguments on the command line,
> > and libvirt buys us that AFAIK or am I missing something ?
> 
> It's not true for all the arguments: take for instance the blockdev, the
> chardev, the netdev, vnc,  ... I think it's true only for parameters
> that define the devices, the machine. And until now for prom-env it was
> not the case, look at the migration-test test case.
> 

        arch_source = g_strdup_printf("-nodefaults "
                                      "-prom-env 'use-nvramrc?=true' -prom-env "
                                      "'nvramrc=hex .\" _\" begin %x %x "
                                      "do i c@ 1 + i c! 1000 +loop .\" B\" 0 "
                                      "until'", end_address, start_address);
        arch_target = g_strdup("");

Ok, my bad... I should have run that before posting.

So, I'll go the other way around and have QEMU to error out if the -prom-env
data doesn't fit in the default size (64 Kib).

> Thanks,
> Laurent
> 
>