Hi,
On Thu, 24 Jun 2021 at 02:01, Philippe Mathieu-Daudé <f4...@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.t...@gmail.com>
> Cc: Warner Losh <i...@bsdimp.com>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1910586
> Signed-off-by: Philippe Mathieu-Daudé <f4...@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
>
