qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 9/9] hw/sd: Allow card size not power of 2 again


From: Tom Yan
Subject: Re: [RFC PATCH 9/9] hw/sd: Allow card size not power of 2 again
Date: Thu, 24 Jun 2021 18:24:41 +0800

Hi,

On Thu, 24 Jun 2021 at 02:01, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> In commit a9bcedd15a5 ("hw/sd/sdcard: Do not allow invalid SD card
> sizes") we tried to protect us from CVE-2020-13253 by only allowing
> card with power-of-2 sizes. However doing so we disrupted valid user
> cases. As a compromise, allow any card size, but warn only power of 2
> sizes are supported, still suggesting the user how to increase a
> card with 'qemu-img resize'.
>
> Cc: Tom Yan <tom.ty89@gmail.com>
> Cc: Warner Losh <imp@bsdimp.com>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1910586
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/sd/sd.c | 25 +++++++++----------------
>  1 file changed, 9 insertions(+), 16 deletions(-)
>
> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> index 9c8dd11bad1..cab4aab1475 100644
> --- a/hw/sd/sd.c
> +++ b/hw/sd/sd.c
> @@ -2131,23 +2131,16 @@ static void sd_realize(DeviceState *dev, Error **errp)
>          blk_size = blk_getlength(sd->blk);
>          if (blk_size > 0 && !is_power_of_2(blk_size)) {
>              int64_t blk_size_aligned = pow2ceil(blk_size);
> -            char *blk_size_str;
> +            g_autofree char *blk_size_s = size_to_str(blk_size);
> +            g_autofree char *blk_size_aligned_s = 
> size_to_str(blk_size_aligned);
>
> -            blk_size_str = size_to_str(blk_size);
> -            error_setg(errp, "Invalid SD card size: %s", blk_size_str);
> -            g_free(blk_size_str);
> -
> -            blk_size_str = size_to_str(blk_size_aligned);
> -            error_append_hint(errp,
> -                              "SD card size has to be a power of 2, e.g. 
> %s.\n"
> -                              "You can resize disk images with"
> -                              " 'qemu-img resize <imagefile> <new-size>'\n"
> -                              "(note that this will lose data if you make 
> the"
> -                              " image smaller than it currently is).\n",
> -                              blk_size_str);
> -            g_free(blk_size_str);
> -
> -            return;
> +            warn_report("SD card size is not a power of 2 (%s). It might 
> work"
> +                        " but is not supported by QEMU. If possible, resize"
> +                        " your disk image to %s with:",
> +                        blk_size_s, blk_size_aligned_s);
> +            warn_report(" 'qemu-img resize <imagefile> <new-size>'");
> +            warn_report("(note that this will lose data if you make the"
> +                        " image smaller than it currently is).");

Not trying to be picky, but I don't think this is much better. IMHO
it's quite irresponsible to give a warning like that, leaving users in
a state like "Should I use it or not then?", without giving a concrete
reference to what exactly might/would lead to the warned problem.

I really think we should get (/ have gotten) things clear first. What
exactly is the bug we have been talking about here? I mean like, where
does it occur and what's the nature of it.

1. Is it specific to a certain type / model of backend / physical
storage device that will be made use of by qemu for the emulated
storage? (I presume not since you mention about image, unless you
irrationally related/bound the emulated storage type and the physical
storage type together.)

2. Does it have anything to do with a certain flaw in qemu itself?
Like the code that does read/write operation is flawed that it cannot
be handled by a certain *proper* backend device?

3. Or is it actually a bug in a certain driver / firmware blob that
will be used by an *emulated* device in the guest? In that case, can
we emulate another model so that it won't be using the problematic
driver / firmware?

Also, could you provide any information / reference to what the bug
really is? Like a bug report (for the problem itself, not some vague
claim that qemu should workaround the problem)?

>          }
>
>          ret = blk_set_perm(sd->blk, BLK_PERM_CONSISTENT_READ | 
> BLK_PERM_WRITE,
> --
> 2.31.1
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]