| Message ID | 20210623180021.898286-10-f4bug@amsat.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | hw/sd: Allow card size not power of 2 again | expand |
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 <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)."); In what scenarios will non-power of 2 not work and what is the effect ? Is it a QEMU bug or not ? Regards, Daniel
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 >
On Thu, 24 Jun 2021 at 11:27, Tom Yan <tom.ty89@gmail.com> 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
> On Jun 24, 2021, at 4:56 AM, Peter Maydell <peter.maydell@linaro.org> wrote: > > On Thu, 24 Jun 2021 at 11:27, Tom Yan <tom.ty89@gmail.com> 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
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)."); } ret = blk_set_perm(sd->blk, BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE,
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(-)