qemu/qapi, branch master

docs: Fix some typos (found by typos) and grammar issues

2024-08-16T13:12:59Z

Fix the misspellings of "overriden" also in code comments. Signed-off-by: Stefan Weil Reviewed-by: Peter Maydell Message-Id: <20240813125638.395461-1-sw@weilnetz.de> Reviewed-by: Peter Xu Reviewed-by: Eric Auger Signed-off-by: Alex Bennée Message-Id: <20240813202329.1237572-20-alex.bennee@linaro.org>

nbd/server: CVE-2024-7409: Cap default max-connections to 100

2024-08-08T21:02:23Z

Allowing an unlimited number of clients to any web service is a recipe for a rudimentary denial of service attack: the client merely needs to open lots of sockets without closing them, until qemu no longer has any more fds available to allocate. For qemu-nbd, we default to allowing only 1 connection unless more are explicitly asked for (-e or --shared); this was historically picked as a nice default (without an explicit -t, a non-persistent qemu-nbd goes away after a client disconnects, without needing any additional follow-up commands), and we are not going to change that interface now (besides, someday we want to point people towards qemu-storage-daemon instead of qemu-nbd). But for qemu proper, and the newer qemu-storage-daemon, the QMP nbd-server-start command has historically had a default of unlimited number of connections, in part because unlike qemu-nbd it is inherently persistent until nbd-server-stop. Allowing multiple client sockets is particularly useful for clients that can take advantage of MULTI_CONN (creating parallel sockets to increase throughput), although known clients that do so (such as libnbd's nbdcopy) typically use only 8 or 16 connections (the benefits of scaling diminish once more sockets are competing for kernel attention). Picking a number large enough for typical use cases, but not unlimited, makes it slightly harder for a malicious client to perform a denial of service merely by opening lots of connections withot progressing through the handshake. This change does not eliminate CVE-2024-7409 on its own, but reduces the chance for fd exhaustion or unlimited memory usage as an attack surface. On the other hand, by itself, it makes it more obvious that with a finite limit, we have the problem of an unauthenticated client holding 100 fds opened as a way to block out a legitimate client from being able to connect; thus, later patches will further add timeouts to reject clients that are not making progress. This is an INTENTIONAL change in behavior, and will break any client of nbd-server-start that was not passing an explicit max-connections parameter, yet expects more than 100 simultaneous connections. We are not aware of any such client (as stated above, most clients aware of MULTI_CONN get by just fine on 8 or 16 connections, and probably cope with later connections failing by relying on the earlier connections; libvirt has not yet been passing max-connections, but generally creates NBD servers with the intent for a single client for the sake of live storage migration; meanwhile, the KubeSAN project anticipates a large cluster sharing multiple clients [up to 8 per node, and up to 100 nodes in a cluster], but it currently uses qemu-nbd with an explicit --shared=0 rather than qemu-storage-daemon with nbd-server-start). We considered using a deprecation period (declare that omitting max-parameters is deprecated, and make it mandatory in 3 releases - then we don't need to pick an arbitrary default); that has zero risk of breaking any apps that accidentally depended on more than 100 connections, and where such breakage might not be noticed under unit testing but only under the larger loads of production usage. But it does not close the denial-of-service hole until far into the future, and requires all apps to change to add the parameter even if 100 was good enough. It also has a drawback that any app (like libvirt) that is accidentally relying on an unlimited default should seriously consider their own CVE now, at which point they are going to change to pass explicit max-connections sooner than waiting for 3 qemu releases. Finally, if our changed default breaks an app, that app can always pass in an explicit max-parameters with a larger value. It is also intentional that the HMP interface to nbd-server-start is not changed to expose max-connections (any client needing to fine-tune things should be using QMP). Suggested-by: Daniel P. Berrangé Signed-off-by: Eric Blake Message-ID: <20240807174943.771624-12-eblake@redhat.com> Reviewed-by: Daniel P. Berrangé [ericb: Expand commit message to summarize Dan's argument for why we break corner-case back-compat behavior without a deprecation period] Signed-off-by: Eric Blake

qapi-block-core: Clean up blockdev-snapshot-internal-sync doc

2024-08-06T18:12:39Z

BlockdevSnapshotInternal is the arguments type of command blockdev-snapshot-internal-sync. Its doc comment contains this note: # .. note:: In a transaction, if @name is empty or any snapshot matching # @name exists, the operation will fail. Only some image formats # support it; for example, qcow2, and rbd. "In a transaction" is misleading, and "if @name is empty or any snapshot matching @name exists, the operation will fail" is redundant with the command's Errors documentation. Drop. The remainder is fine. Move it to the command's doc comment, where it is more prominently visible, with a slight rephrasing for clarity. Signed-off-by: Markus Armbruster Message-ID: <20240718123609.3063055-1-armbru@redhat.com> Reviewed-by: Kevin Wolf Signed-off-by: Kevin Wolf

qmp: Fix higher half vaddrs for [p]memsave

2024-08-05T07:34:34Z

Fixes higher-half address parsing for QMP commands `[p]memsave`. Signed-off-by: Josh Junon Message-ID: <20240802140704.13591-1-junon@oro.sh> Reviewed-by: Markus Armbruster [Subject tweaked, and one PRId64 updated to PRIu64] Signed-off-by: Markus Armbruster

qapi: Refill doc comments to conform to conventions

2024-08-05T07:31:51Z

Sweep the entire documentation again. Last done in commit 209e64d9edf (qapi: Refill doc comments to conform to current conventions). To check the generated documentation does not change, I compared the generated HTML before and after this commit with "wdiff -3". Finds no differences. Comparing with diff is not useful, as the reflown paragraphs are visible there. Signed-off-by: Markus Armbruster Message-ID: <20240729065220.860163-1-armbru@redhat.com> [Straightforward conflict with commit 442110bc6f3 resolved]

Merge tag 's390x-20240730' of https://github.com/davidhildenbrand/qemu into staging

2024-07-30T09:21:58Z

s390x updates: - fixup for a s390x-only query-cpu-model-expansion extension # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAmaonmkRHGRhdmlkQHJl # ZGhhdC5jb20ACgkQTd4Q9wD/g1pCQBAAiHHoKssyl5xdEWid92OnpEK499xngBBS # zRJAZVmidnuTRbaAd0bB4rfwO13KKCwvWwKCjFG9tkH4QFTdXKnDzoLWTjy9Ytg3 # jB6L91sbMgySPBlXEqVkFh8WIkpVhcd9FVfSddw4QTnunyGAxTVNIhZFgBdVLXH3 # 2MLOd33FgkwiK+9gBKPccI/VBTmE2UX2EYrJ7gJOdB3AA5dSQxgQ4dxJEHaN/CcV # jHXLJ6Mcu6sz/qBxiiFcQvbepLSG3odBcuETL/pKcrk/H2YPKT6hIiWPNGFcVD0H # P36+rYo5Sr5KWOFbK4p8PPPnyDqYoOzmhwKTf+uO7sEHSSwiPexYJp6um6onTD3m # MNXl+5jahTePWdKXlJ6+j1DG0uKJnFobaj6P1HM3f37Douq/7fyxrcDuySLEdrSD # CutaQkdhr55WAlVPtmO3EuUc8eYxEGN4aEWSwtw9KWewF/vgq63Zos+p02Fi1mfN # gP8Fmz29gLAMkq57Y85zyMM2rYjfmE9Nt8Zzmnod2O9xuohwg7liqvVDfLo88g7X # czHSG0+O8TwXaanWIGAA4jgpfsNjxu7Qkx+jiB1uqLafj/wok/dOu5Teq3WU5t+i # vEHyI3CCfCH5q+ifNwe5vPQi4b1rZ0sT/cnYBpOhIs4Jroys1D3XXc0pHMJFJ7mz # CKka4wDf6aM= # =wSbp # -----END PGP SIGNATURE----- # gpg: Signature made Tue 30 Jul 2024 06:03:53 PM AEST # gpg: using RSA key 1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A # gpg: issuer "david@redhat.com" # gpg: Good signature from "David Hildenbrand " [undefined] # gpg: aka "David Hildenbrand " [full] # gpg: aka "David Hildenbrand " [unknown] # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 1BD9 CAAD 735C 4C3A 460D FCCA 4DDE 10F7 00FF 835A * tag 's390x-20240730' of https://github.com/davidhildenbrand/qemu: target/s390x: move @deprecated-props to CpuModelExpansion Info Signed-off-by: Richard Henderson

target/s390x: move @deprecated-props to CpuModelExpansion Info

2024-07-29T19:47:16Z

CpuModelInfo is used both as command argument and in command returns. Its @deprecated-props array does not make any sense in arguments, and is silently ignored. We actually want it only as return value of query-cpu-model-expansion. Move it from CpuModelInfo to CpuModelExpansionType, and document its dependence on expansion type property. This was identified late during review [1] and we have to fix it up while it's not part of an official QEMU release yet. [1] https://lore.kernel.org/qemu-devel/20240719181741.35146-1-walling@linux.ibm.com/ Message-ID: <20240726203646.20279-1-walling@linux.ibm.com> Fixes: eed0e8ffa38f ("target/s390x: filter deprecated properties based on model expansion type") Signed-off-by: Collin Walling [ david: - add "Fixes", adjust description, reference v3 instead - make property s390x-only and non-optional - fixup "populate" vs. "populated" ] Signed-off-by: David Hildenbrand

qapi/machine: Belatedly document target loongarch64 is since 7.1

2024-07-29T05:29:47Z

Fixes: a8a506c39070 (hw/loongarch: Add support loongson3 virt machine type.) Signed-off-by: Markus Armbruster Message-ID: <20240718141001.3077709-1-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Song Gao

qapi/qom: make some QOM properties depend on the build settings

2024-07-29T05:29:47Z

Some QOM properties are associated with ObjectTypes that already depend on CONFIG_* switches. So to avoid generating dead code, let's also make the definition of those properties dependent on the corresponding CONFIG_*. Suggested-by: Markus Armbruster Signed-off-by: Stefano Garzarella Message-ID: <20240604135931.311709-1-sgarzare@redhat.com> Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Markus Armbruster [Make SecretKeyringProperties conditional, too] Signed-off-by: Markus Armbruster

qapi: drop unused QCryptoBlockCreateOptionsLUKS.detached-header

2024-07-24T09:39:10Z

The 'detached-header' field in QCryptoBlockCreateOptionsLUKS was left over from earlier patch iterations. Acked-by: Markus Armbruster Signed-off-by: Daniel P. Berrangé