Re: [PULL 0/5] Python patches

On 11/17/21 1:33 AM, John Snow wrote: The following changes since commit 2b22e7540d6ab4efe82d442363e3fc900cea6584: Merge tag 'm68k-for-6.2-pull-request' of git://github.com/vivier/qemu-m68k into staging (2021-11-09 13:16:56 +0100) are available in the Git repository at:

Re: [PATCH-for-6.2 v2 1/2] hw/nvme/ctrl: Fix buffer overrun in nvme_changed_nslist (CVE-2021-3947)

On Nov 17 13:35, Philippe Mathieu-Daudé wrote: > Both 'buf_len' and 'off' arguments are under guest control. > Since nvme_c2h() doesn't check out of boundary access, the > caller must check for eventual buffer overrun on 'trans_len'. > > Cc: qemu-sta...@nongnu.org > Reported-by: Qiuhao Li >

[PATCH for-6.2] hw/nvme: fix buffer overrun in nvme_changed_nslist (CVE-2021-3947)

From: Klaus Jensen Fix missing offset verification. Cc: qemu-sta...@nongnu.org Cc: Philippe Mathieu-Daudé Reported-by: Qiuhao Li Fixes: f432fdfa121 ("support changed namespace asynchronous event") Signed-off-by: Klaus Jensen --- Note: Since its so easy to mess this fix up, the log pages

[PATCH-for-6.2 v2 0/2] hw/nvme/ctrl: Fix buffer overrun (CVE-2021-3947)

Since v1: - Do not add more buffer overflows in modify nvme_smart_info(), nvme_fw_log_info() and nvme_cmd_effects() (Klaus) - Split nvme_error_info() change in another patch Philippe Mathieu-Daudé (2): hw/nvme/ctrl: Fix buffer overrun in nvme_changed_nslist (CVE-2021-3947) hw/nvme/ctrl:

Re: [PATCH v4 20/25] block_int-common.h: assertion in the callers of BlockDriver function pointers

On 17.11.21 14:09, Emanuele Giuseppe Esposito wrote: On 17/11/2021 13:51, Hanna Reitz wrote: On 17.11.21 12:33, Emanuele Giuseppe Esposito wrote: On 15/11/2021 13:48, Hanna Reitz wrote: On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote: Signed-off-by: Emanuele Giuseppe Esposito

Re: [PATCH v2 08/15] hw/nvme: Implement the Function Level Reset

On Tue, Nov 16, 2021 at 01:28:19PM -0800, Keith Busch wrote: > On Tue, Nov 16, 2021 at 04:34:39PM +0100, Łukasz Gieryk wrote: > > if (!pci_is_vf(>parent_obj) && n->params.sriov_max_vfs) { > > -pcie_sriov_pf_disable_vfs(>parent_obj); > > +if (rst != NVME_RESET_CONTROLLER) { > >

[PATCH-for-6.2 v2 1/2] hw/nvme/ctrl: Fix buffer overrun in nvme_changed_nslist (CVE-2021-3947)

Both 'buf_len' and 'off' arguments are under guest control. Since nvme_c2h() doesn't check out of boundary access, the caller must check for eventual buffer overrun on 'trans_len'. Cc: qemu-sta...@nongnu.org Reported-by: Qiuhao Li Fixes: f432fdfa121 ("support changed namespace asynchronous

Failing QEMU iotests

Hi! I think it has been working fine for me a couple of weeks ago, but when I now run: make check SPEED=slow I'm getting a couple of failing iotests... not sure whether these are known issues already, so I thought I'd summarize them here: *** First one is 045 in raw mode: *** TEST

Re: [PATCH-for-6.2 v2 2/2] hw/nvme/ctrl: Prevent buffer overrun in nvme_error_info()

On Nov 17 13:35, Philippe Mathieu-Daudé wrote: > Both 'buf_len' and 'off' arguments are under guest control. > Since nvme_c2h() doesn't check out of boundary access, the > caller must check for eventual buffer overrun on 'trans_len'. > > Cc: qemu-sta...@nongnu.org > Fixes: 94a7897c41d ("add

Re: [PATCH v4 24/25] job.h: split function pointers in JobDriver

On 17.11.21 14:43, Emanuele Giuseppe Esposito wrote: On 15/11/2021 16:11, Hanna Reitz wrote: On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote: The job API will be handled separately in another serie. Signed-off-by: Emanuele Giuseppe Esposito Reviewed-by: Stefan Hajnoczi ---  

Re: [PATCH 1/2] block:hdev: support BLKSECDISCARD

On Tue, Nov 16, 2021 at 09:53:39PM -0800, Christoph Hellwig wrote: > On Tue, Nov 16, 2021 at 10:58:30AM +, Stefan Hajnoczi wrote: > > Question for Jens and Christoph: > > > > Is there a way for userspace to detect whether a Linux block device > > supports SECDISCARD? > > I don't know of one.

Re: [PATCH v4 20/25] block_int-common.h: assertion in the callers of BlockDriver function pointers

On 15/11/2021 13:48, Hanna Reitz wrote: On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote: Signed-off-by: Emanuele Giuseppe Esposito Reviewed-by: Stefan Hajnoczi ---   block.c | 17 +   1 file changed, 17 insertions(+) diff --git a/block.c b/block.c index

Re: Failing QEMU iotests

On 17/11/2021 11.59, Hanna Reitz wrote: On 17.11.21 11:07, Thomas Huth wrote:  Hi! I think it has been working fine for me a couple of weeks ago, but when I now run:  make check SPEED=slow I'm getting a couple of failing iotests... not sure whether these are known issues already, so I

Re: [PATCH v4 20/25] block_int-common.h: assertion in the callers of BlockDriver function pointers

On 17.11.21 12:33, Emanuele Giuseppe Esposito wrote: On 15/11/2021 13:48, Hanna Reitz wrote: On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote: Signed-off-by: Emanuele Giuseppe Esposito Reviewed-by: Stefan Hajnoczi ---   block.c | 17 +   1 file changed, 17 insertions(+)

[PATCH-for-6.2 v2 2/2] hw/nvme/ctrl: Prevent buffer overrun in nvme_error_info()

Both 'buf_len' and 'off' arguments are under guest control. Since nvme_c2h() doesn't check out of boundary access, the caller must check for eventual buffer overrun on 'trans_len'. Cc: qemu-sta...@nongnu.org Fixes: 94a7897c41d ("add support for the get log page command") Signed-off-by: Philippe

Re: [PATCH v4 20/25] block_int-common.h: assertion in the callers of BlockDriver function pointers

On 17/11/2021 13:51, Hanna Reitz wrote: On 17.11.21 12:33, Emanuele Giuseppe Esposito wrote: On 15/11/2021 13:48, Hanna Reitz wrote: On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote: Signed-off-by: Emanuele Giuseppe Esposito Reviewed-by: Stefan Hajnoczi ---   block.c | 17

Re: [PATCH v4 24/25] job.h: split function pointers in JobDriver

On 15/11/2021 16:11, Hanna Reitz wrote: On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote: The job API will be handled separately in another serie. Signed-off-by: Emanuele Giuseppe Esposito Reviewed-by: Stefan Hajnoczi ---   include/qemu/job.h | 16   1 file changed, 16

Re: [PULL 0/5] Python patches

Hi, > https://gitlab.com/jsnow/qemu.git tags/python-pull-request What is the status of the plan to upload this to pypi eventually? thanks, Gerd

Re: Failing QEMU iotests

On 17.11.21 11:07, Thomas Huth wrote:  Hi! I think it has been working fine for me a couple of weeks ago, but when I now run:  make check SPEED=slow I'm getting a couple of failing iotests... not sure whether these are known issues already, so I thought I'd summarize them here: Thanks!

Re: [PATCH v2 03/13] hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get()

Yes, there's SD and MMC buses. It looks like the current code only supports mmc ("soc->mmc.sdhci") but not the sd ("soc->sd.sdhci"). It's probably good to make the bus number a parameter as well and use them to distinguish. We might need a separate patch to do that. On Wed, Nov 17, 2021 at 8:54

Re: [PULL 0/5] Python patches

On Wed, Nov 17, 2021 at 4:42 AM Gerd Hoffmann wrote: > Hi, > > > https://gitlab.com/jsnow/qemu.git tags/python-pull-request > > What is the status of the plan to upload this to pypi eventually? > > Thanks for asking! The honest answer is "I'm not exactly sure", but there are a few things to

Re: [PATCH for-6.2? 2/2] nbd/server: Simplify zero and trim

17.11.2021 20:02, Eric Blake wrote: Now that the block layer supports 64-bit operations, we no longer have to self-fragment requests larger than 2G, reverting the workaround added in 890cbccb08 (nbd: Fix large trim/zero requests). Signed-off-by: Eric Blake Reviewed-by: Vladimir

Re: [PULL 0/5] Python patches

On Wed, Nov 17, 2021 at 1:20 PM Vladimir Sementsov-Ogievskiy < vsement...@virtuozzo.com> wrote: > 17.11.2021 20:56, John Snow wrote: > > > > On Wed, Nov 17, 2021 at 4:42 AM Gerd Hoffmann > wrote: > > > >Hi, > > > > > https://gitlab.com/jsnow/qemu.git < >

Re: [PATCH for-6.2] hw/nvme: fix buffer overrun in nvme_changed_nslist (CVE-2021-3947)

On 11/17/21 14:23, Klaus Jensen wrote: > From: Klaus Jensen > > Fix missing offset verification. > > Cc: qemu-sta...@nongnu.org > Cc: Philippe Mathieu-Daudé > Reported-by: Qiuhao Li > Fixes: f432fdfa121 ("support changed namespace asynchronous event") > Signed-off-by: Klaus Jensen

Re: [PULL 0/5] Python patches

17.11.2021 20:56, John Snow wrote: On Wed, Nov 17, 2021 at 4:42 AM Gerd Hoffmann mailto:kra...@redhat.com>> wrote:   Hi, > https://gitlab.com/jsnow/qemu.git tags/python-pull-request What is the status of the plan to upload this to pypi

Re: [PULL 0/5] Python patches

17.11.2021 22:07, John Snow wrote: On Wed, Nov 17, 2021 at 1:20 PM Vladimir Sementsov-Ogievskiy mailto:vsement...@virtuozzo.com>> wrote: 17.11.2021 20:56, John Snow wrote: > > On Wed, Nov 17, 2021 at 4:42 AM Gerd Hoffmann mailto:kra...@redhat.com>

Re: [PATCH for-6.2 1/2] nbd/server: Don't complain on certain client disconnects

On Wed, Nov 17, 2021 at 08:57:35PM +0300, Vladimir Sementsov-Ogievskiy wrote: > 17.11.2021 20:02, Eric Blake wrote: > > This patch fixes things to avoid uninitialized memory, and in general > > avoids warning about a client that does a hard shutdown when not in > > the middle of a packet. A

Re: [PATCH for-6.2? 2/2] nbd/server: Simplify zero and trim

On Wed, Nov 17, 2021 at 09:04:34PM +0300, Vladimir Sementsov-Ogievskiy wrote: > 17.11.2021 20:02, Eric Blake wrote: > > Now that the block layer supports 64-bit operations, we no longer have > > to self-fragment requests larger than 2G, reverting the workaround > > added in 890cbccb08 (nbd: Fix

Re: Failing QEMU iotests

On Wed, Nov 17, 2021 at 5:07 AM Thomas Huth wrote: > > Hi! > > I think it has been working fine for me a couple of weeks ago, > but when I now run: > > make check SPEED=slow > > I'm getting a couple of failing iotests... not sure whether > these are known issues already, so I thought I'd

Re: Failing QEMU iotests

On Wed, Nov 17, 2021 at 2:45 PM Thomas Huth wrote: > On 17/11/2021 19.13, John Snow wrote: > > > > > > On Wed, Nov 17, 2021 at 5:07 AM Thomas Huth > > wrote: > > > > > >Hi! > > > > I think it has been working fine for me a couple of weeks ago, > > but

Re: [PATCH for-6.2 1/2] nbd/server: Don't complain on certain client disconnects

17.11.2021 20:02, Eric Blake wrote: When a client disconnects abruptly, but did not have any pending requests (for example, when using nbdsh without calling h.shutdown), we used to output the following message: $ qemu-nbd -f raw file $ nbdsh -u 'nbd://localhost:10809' -c 'h.trim(1,0)' qemu-nbd:

Re: Failing QEMU iotests

On Wed, Nov 17, 2021 at 7:50 AM Thomas Huth wrote: > On 17/11/2021 11.59, Hanna Reitz wrote: > > On 17.11.21 11:07, Thomas Huth wrote: > > >> +++ 297.out.bad > >> @@ -1,2 +1,21 @@ > >> === pylint === > >> +* Module image-fleecing > >> +tests/image-fleecing:34:24: C0326: Exactly one

Re: [PATCH v2 01/13] hw/sd/ssi-sd: Do not create SD card within controller's realize

Hi Markus, Peter, On 11/17/21 17:33, Markus Armbruster wrote: > ssi_sd_realize() creates an "sd-card" device. This is inappropriate, > and marked FIXME. > > Move it to the boards that create these devices. Prior art: commit > eb4f566bbb for device "generic-sdhci", and commit 26c607b86b for >

Re: Failing QEMU iotests

On 17/11/2021 19.13, John Snow wrote: On Wed, Nov 17, 2021 at 5:07 AM Thomas Huth > wrote:   Hi! I think it has been working fine for me a couple of weeks ago, but when I now run:   make check SPEED=slow I'm getting a couple of failing

Re: [PATCH for-6.2? 2/2] nbd/server: Simplify zero and trim

17.11.2021 23:49, Eric Blake wrote: On Wed, Nov 17, 2021 at 09:04:34PM +0300, Vladimir Sementsov-Ogievskiy wrote: 17.11.2021 20:02, Eric Blake wrote: Now that the block layer supports 64-bit operations, we no longer have to self-fragment requests larger than 2G, reverting the workaround added

Re: [PATCH 2/2] iotests/149: Skip on unsupported ciphers

On 17.11.21 16:01, Hanna Reitz wrote: Whenever qemu-img or qemu-io report that some cipher is unsupported, skip the whole test, because that is probably because qemu has been configured with the gnutls crypto backend. We could taylor the algorithm list to what gnutls supports, but this is a

[PATCH v2 00/13] Eliminate drive_get_next()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH v2 05/13] hw/arm/imx25_pdk: Replace drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH v2 02/13] hw: Replace trivial drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH for-6.2 1/2] nbd/server: Don't complain on certain client disconnects

When a client disconnects abruptly, but did not have any pending requests (for example, when using nbdsh without calling h.shutdown), we used to output the following message: $ qemu-nbd -f raw file $ nbdsh -u 'nbd://localhost:10809' -c 'h.trim(1,0)' qemu-nbd: Disconnect client, due to: Failed to

Re: [PATCH v2 03/13] hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get()

On Wed, Nov 17, 2021 at 8:34 AM Markus Armbruster wrote: > > drive_get_next() is basically a bad idea. It returns the "next" block > backend of a certain interface type. "Next" means bus=0,unit=N, where > subsequent calls count N up from zero, per interface type. > > This lets you define unit

Re: Failing QEMU iotests

On Wed, Nov 17, 2021 at 01:50:12PM +0100, Thomas Huth wrote: > On 17/11/2021 11.59, Hanna Reitz wrote: > > On 17.11.21 11:07, Thomas Huth wrote: > > > > > >  Hi! > > > > > > I think it has been working fine for me a couple of weeks ago, > > > but when I now run: > > > > > >  make check

[PATCH v2 1/2] iotests: Use aes-128-cbc

Our gnutls crypto backend (which is the default as of 8bd0931f6) supports neither twofish-128 nor the CTR mode. CBC and aes-128 are supported by all of our backends (as far as I can tell), so use aes-128-cbc in our iotests. (We could also use e.g. aes-256-cbc, but the different key sizes would

[PATCH v2 03/13] hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH v2 10/13] hw/arm/xlnx-zcu102: Replace drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH v2 01/13] hw/sd/ssi-sd: Do not create SD card within controller's realize

ssi_sd_realize() creates an "sd-card" device. This is inappropriate, and marked FIXME. Move it to the boards that create these devices. Prior art: commit eb4f566bbb for device "generic-sdhci", and commit 26c607b86b for device "pl181". The device remains not user-creatable, because its users

[PATCH 0/2] iotests: Fix crypto algorithm failures

Hi, iotests 149, 206, and 210 fail when qemu uses the gnutls crypto backend (which is the default as of 8bd0931f6) because they try to use algorithms that this backend does not support. Have 206 and 210 use different algorithms instead (patch 1), and let 149 be skipped when it encounters an

[PATCH v2 2/2] iotests/149: Skip on unsupported ciphers

Whenever qemu-img or qemu-io report that some cipher is unsupported, skip the whole test, because that is probably because qemu has been configured with the gnutls crypto backend. We could taylor the algorithm list to what gnutls supports, but this is a test that is run rather rarely anyway

Re: [PATCH v2 2/2] iotests/149: Skip on unsupported ciphers

On Wed, Nov 17, 2021 at 04:17:07PM +0100, Hanna Reitz wrote: > Whenever qemu-img or qemu-io report that some cipher is unsupported, > skip the whole test, because that is probably because qemu has been > configured with the gnutls crypto backend. > > We could taylor the algorithm list to what

Re: [PATCH v2 1/2] iotests: Use aes-128-cbc

On Wed, Nov 17, 2021 at 04:17:06PM +0100, Hanna Reitz wrote: > Our gnutls crypto backend (which is the default as of 8bd0931f6) > supports neither twofish-128 nor the CTR mode. CBC and aes-128 are > supported by all of our backends (as far as I can tell), so use > aes-128-cbc in our iotests.

Re: [PATCH v2] nbd/server: Suppress Broken pipe errors on abrupt disconnection

Revisiting an older thread On Mon, Sep 13, 2021 at 04:19:36PM +0100, Richard W.M. Jones wrote: > $ rm -f /tmp/sock /tmp/pid > $ qemu-img create -f qcow2 /tmp/disk.qcow2 1M > $ qemu-nbd -t --format=qcow2 --socket=/tmp/sock --pid-file=/tmp/pid > /tmp/disk.qcow2 & > $ nbdsh -u

[PATCH v2 04/13] hw/arm/versatilepb hw/arm/vexpress: Replace drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH v2 12/13] hw/arm/aspeed: Replace drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH for-6.2 0/2] NBD 6.2-rc fixes

Back in September, Rich proposed a patch to silence an EPIPE message from qemu-nbd when used with Unix sockets: https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg03359.html But investigating that further, I found that we had a different message with TCP sockets, and that we regressed in

[PATCH for-6.2? 2/2] nbd/server: Simplify zero and trim

Now that the block layer supports 64-bit operations, we no longer have to self-fragment requests larger than 2G, reverting the workaround added in 890cbccb08 (nbd: Fix large trim/zero requests). Signed-off-by: Eric Blake --- nbd/server.c | 23 +++ 1 file changed, 3

[PATCH v2 0/2] iotests: Fix crypto algorithm failures

Hi, iotests 149, 206, and 210 fail when qemu uses the gnutls crypto backend (which is the default as of 8bd0931f6) because they try to use algorithms that this backend does not support. Have 206 and 210 use different algorithms instead (patch 1), and let 149 be skipped when it encounters an

[PATCH v2 06/13] hw/arm/mcimx6ul-evk: Replace drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH v2 07/13] hw/arm/mcimx7d-sabre: Replace drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH 2/2] iotests/149: Skip on unsupported ciphers

Whenever qemu-img or qemu-io report that some cipher is unsupported, skip the whole test, because that is probably because qemu has been configured with the gnutls crypto backend. We could taylor the algorithm list to what gnutls supports, but this is a test that is run rather rarely anyway

[PATCH 1/2] iotests: Use aes-128-cbc

Our gnutls crypto backend (which is the default as of 8bd0931f6) supports neither twofish-128 nor the CTR mode. CBC and aes-128 are supported by all of our backends (as far as I can tell), so use aes-128-cbc in our iotests. (We could also use e.g. aes-256-cbc, but the different key sizes would

[PATCH v2 08/13] hw/arm/xlnx-versal-virt: Replace drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH v2 11/13] hw/arm/xilinx_zynq: Replace drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH v2 09/13] hw/microblaze: Replace drive_get_next() by drive_get()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

[PATCH v2 13/13] blockdev: Drop unused drive_get_next()

drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new

RE: [PATCH 1/2] block:hdev: support BLKSECDISCARD

> What is the use case for exposing secure erase in qemu? The whole concept for > a LBA based secure erase is generally not a very smart idea for flash based > media.. Hi, Christoph We got a user requirement: support BLKSECDISCARD in VM. Which is: ioctl(BLKSECDISCARD) in guest -> qemu backend

Re: Failing QEMU iotests

On 17/11/2021 20.59, John Snow wrote: On Wed, Nov 17, 2021 at 2:45 PM Thomas Huth > wrote: On 17/11/2021 19.13, John Snow wrote: > > > On Wed, Nov 17, 2021 at 5:07 AM Thomas Huth mailto:th...@redhat.com> >

Re: Failing QEMU iotests

On Wed, Nov 17, 2021 at 4:33 PM Thomas Huth wrote: > On 17/11/2021 20.59, John Snow wrote: > > > > > > On Wed, Nov 17, 2021 at 2:45 PM Thomas Huth > > wrote: > > > > On 17/11/2021 19.13, John Snow wrote: > > > > > > > > > On Wed, Nov 17, 2021 at 5:07

[PATCH-for-6.2 v2 2/2] tests/qtest/fdc-test: Add a regression test for CVE-2021-20196

From: Alexander Bulekov When running 'make check-qtest-i386' with QEMU configured with '--enable-sanitizers' we get: AddressSanitizer:DEADLYSIGNAL = ==287878==ERROR: AddressSanitizer: SEGV on unknown address 0x0344

[PATCH-for-6.2 v2 1/2] hw/block/fdc: Kludge missing floppy drive to fix CVE-2021-20196

Guest might select another drive on the bus by setting the DRIVE_SEL bit of the DIGITAL OUTPUT REGISTER (DOR). The current controller model doesn't expect a BlockBackend to be NULL. A simple way to fix CVE-2021-20196 is to create an empty BlockBackend when it is missing. All further accesses will

[PATCH-for-6.2 v2 0/2] hw/block/fdc: Fix CVE-2021-20196

I'm not sure what happened to v1 from Prasad, so since we are at rc2 I took a simpler approach to fix this CVE: create an empty drive to satisfy the BlockBackend API calls. Added Alexander's reproducer along. v1: https://lore.kernel.org/qemu-devel/20210123100345.642933-1-ppan...@redhat.com/

Re: [PATCH v2 03/13] hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get()

Havard Skinnemoen writes: > On Wed, Nov 17, 2021 at 8:34 AM Markus Armbruster wrote: >> >> drive_get_next() is basically a bad idea. It returns the "next" block >> backend of a certain interface type. "Next" means bus=0,unit=N, where >> subsequent calls count N up from zero, per interface

Re: [PULL 0/5] Python patches

Hi, > - Split python/qemu/qmp out into its own repository and begin uploading it > to PyPI, as a test. (Do not delete python/qemu/qmp yet at this phase.) I think you can do that as two separate steps. pip can install from vcs too, i.e. when splitted to a separate repo but not yet uploaded to