Re: [RFC PATCH 9/9] hw/sd: Allow card size not power of 2 again
> On Jun 24, 2021, at 4:56 AM, Peter Maydell wrote: > > On Thu, 24 Jun 2021 at 11:27, Tom Yan wrote: >> 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? > > Definitely agreed -- before we start changing QEMU code we need > to identify clearly (a) what the real hardware does and (b) what > the situation was we were originally trying to fix. Real SD and MMC cards do not have power-of-two constraints in the number of blocks. None of the SD/MMC bridges I’ve ever dealt with have a power-of-two constraint on the size of the card. The only constraint on the size related to the card is the block size. If non-power-of-2 sized cards fail, that’s a cat-1 sev-1 bug that needs to be fixed, rather than a warning be generated. Warner signature.asc Description: Message signed with OpenPGP
Re: [RFC PATCH 9/9] hw/sd: Allow card size not power of 2 again
On Thu, 24 Jun 2021 at 11:27, Tom Yan wrote: > 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? Definitely agreed -- before we start changing QEMU code we need to identify clearly (a) what the real hardware does and (b) what the situation was we were originally trying to fix. thanks -- PMM
Re: [RFC PATCH 9/9] hw/sd: Allow card size not power of 2 again
Hi,
On Thu, 24 Jun 2021 at 02:01, Philippe Mathieu-Daudé 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
> Cc: Warner Losh
> Buglink: https://bugs.launchpad.net/qemu/+bug/1910586
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> 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 '\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 '");
> +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
>
Re: [RFC PATCH 9/9] hw/sd: Allow card size not power of 2 again
On Wed, Jun 23, 2021 at 08:00:21PM +0200, Philippe Mathieu-Daudé 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
> Cc: Warner Losh
> Buglink: https://bugs.launchpad.net/qemu/+bug/1910586
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> 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 '\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 '");
> +warn_report("(note that this will lose data if you make the"
> +" image smaller than it currently is).");
In what scenarios will non-power of 2 not work and what is the effect ?
Is it a QEMU bug or not ?
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
[RFC PATCH 9/9] hw/sd: Allow card size not power of 2 again
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
Cc: Warner Losh
Buglink: https://bugs.launchpad.net/qemu/+bug/1910586
Signed-off-by: Philippe Mathieu-Daudé
---
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 '\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 '");
+warn_report("(note that this will lose data if you make the"
+" image smaller than it currently is).");
}
ret = blk_set_perm(sd->blk, BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE,
--
2.31.1
