Branch: refs/heads/staging-9.2
  Home:   https://github.com/qemu/qemu
  Commit: 361f29fe1bc6c847b108442d573fcd2690d6db4b
      
https://github.com/qemu/qemu/commit/361f29fe1bc6c847b108442d573fcd2690d6db4b
  Author: Christian Schoenebeck <[email protected]>
  Date:   2024-12-13 (Fri, 13 Dec 2024)

  Changed paths:
    M hw/9pfs/9p-util.h

  Log Message:
  -----------
  9pfs: fix regression regarding CVE-2023-2861

The released fix for this CVE:

  f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)")

caused a regression with security_model=passthrough. When handling a
'Tmknod' request there was a side effect that 'Tmknod' request could fail
as 9p server was trying to adjust permissions:

  #6  close_if_special_file (fd=30) at ../hw/9pfs/9p-util.h:140
  #7  openat_file (mode=<optimized out>, flags=2228224,
      name=<optimized out>, dirfd=<optimized out>) at
      ../hw/9pfs/9p-util.h:181
  #8  fchmodat_nofollow (dirfd=dirfd@entry=31,
      name=name@entry=0x5555577ea6e0 "mysocket", mode=493) at
      ../hw/9pfs/9p-local.c:360
  #9  local_set_cred_passthrough (credp=0x7ffbbc4ace10, name=0x5555577ea6e0
      "mysocket", dirfd=31, fs_ctx=0x55555811f528) at
      ../hw/9pfs/9p-local.c:457
  #10 local_mknod (fs_ctx=0x55555811f528, dir_path=<optimized out>,
      name=0x5555577ea6e0 "mysocket", credp=0x7ffbbc4ace10) at
      ../hw/9pfs/9p-local.c:702
  #11 v9fs_co_mknod (pdu=pdu@entry=0x555558121140,
      fidp=fidp@entry=0x5555574c46c0, name=name@entry=0x7ffbbc4aced0,
      uid=1000, gid=1000, dev=<optimized out>, mode=49645,
      stbuf=0x7ffbbc4acef0) at ../hw/9pfs/cofs.c:205
  #12 v9fs_mknod (opaque=0x555558121140) at ../hw/9pfs/9p.c:3711

That's because server was opening the special file to adjust permissions,
however it was using O_PATH and it would have not returned the file
descriptor to guest. So the call to close_if_special_file() on that branch
was incorrect.

Let's lift the restriction introduced by f6b0de53fb8 such that it would
allow to open special files on host if O_PATH flag is supplied, not only
for 9p server's own operations as described above, but also for any client
'Topen' request.

It is safe to allow opening special files with O_PATH on host, because
O_PATH only allows path based operations on the resulting file descriptor
and prevents I/O such as read() and write() on that file descriptor.

Fixes: f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2337
Reported-by: Dirk Herrendorfer <[email protected]>
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Tested-by: Dirk Herrendorfer <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit d06a9d843fb65351e0e4dc42ba0c404f01ea92b3)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: f838a7e3659b1066e5b39be09b499d637d084758
      
https://github.com/qemu/qemu/commit/f838a7e3659b1066e5b39be09b499d637d084758
  Author: Richard Henderson <[email protected]>
  Date:   2024-12-13 (Fri, 13 Dec 2024)

  Changed paths:
    M accel/tcg/plugin-gen.c
    M include/tcg/tcg-temp-internal.h
    M tcg/tcg.c

  Log Message:
  -----------
  tcg: Reset free_temps before tcg_optimize

When allocating new temps during tcg_optmize, do not re-use
any EBB temps that were used within the TB.  We do not have
any idea what span of the TB in which the temp was live.

Introduce tcg_temp_ebb_reset_freed and use before tcg_optimize,
as well as replacing the equivalent in plugin_gen_inject and
tcg_func_start.

Cc: [email protected]
Fixes: fb04ab7ddd8 ("tcg/optimize: Lower TCG_COND_TST{EQ,NE} if unsupported")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2711
Reported-by: wannacu <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 04e006ab36a8565b92d4e21dd346367fbade7d74)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 242376e87245daf9e8811c8a161549c019f5933c
      
https://github.com/qemu/qemu/commit/242376e87245daf9e8811c8a161549c019f5933c
  Author: Roman Artemev <[email protected]>
  Date:   2024-12-13 (Fri, 13 Dec 2024)

  Changed paths:
    M tcg/riscv/tcg-target.c.inc

  Log Message:
  -----------
  tcg/riscv: Fix StoreStore barrier generation

On RISC-V to StoreStore barrier corresponds
`fence w, w` not `fence r, r`

Cc: [email protected]
Fixes: efbea94c76b ("tcg/riscv: Add slowpath load and store instructions")
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Denis Tomashev <[email protected]>
Signed-off-by: Roman Artemev <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit b438362a142527b97b638b7f0f35ebe11911a8d5)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 05e984c200a21a9f63d6c4f88b197d5d80b0a8fb
      
https://github.com/qemu/qemu/commit/05e984c200a21a9f63d6c4f88b197d5d80b0a8fb
  Author: Gerd Hoffmann <[email protected]>
  Date:   2024-12-17 (Tue, 17 Dec 2024)

  Changed paths:
    M hw/i386/x86-common.c

  Log Message:
  -----------
  x86/loader: only patch linux kernels

If the binary loaded via -kernel is *not* a linux kernel (in which
case protocol == 0), do not patch the linux kernel header fields.

It's (a) pointless and (b) might break binaries by random patching
and (c) changes the binary hash which in turn breaks secure boot
verification.

Background: OVMF happily loads and runs not only linux kernels but
any efi binary via direct kernel boot.

Note: Breaking the secure boot verification is a problem for linux
kernels too, but fixed that is left for another day ...

Signed-off-by: Gerd Hoffmann <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 57e2cc9abf5da38f600354fe920ff20e719607b4)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 83daae51ee6afbd2b0d79ae5e6924d6c7a840eb4
      
https://github.com/qemu/qemu/commit/83daae51ee6afbd2b0d79ae5e6924d6c7a840eb4
  Author: Gerd Hoffmann <[email protected]>
  Date:   2024-12-17 (Tue, 17 Dec 2024)

  Changed paths:
    M roms/Makefile

  Log Message:
  -----------
  roms: re-add edk2-basetools target

Needed to build ipxe nic roms.

Reported-by: Liu Jaloo <[email protected]>
Fixes: 22e11539e167 ("edk2: replace build scripts")
Signed-off-by: Gerd Hoffmann <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 0f5715e4b5706b31b3550d8e6b88871e029c7823)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: fa232044a5b21da5721dd89c1d60509f7c9b109a
      
https://github.com/qemu/qemu/commit/fa232044a5b21da5721dd89c1d60509f7c9b109a
  Author: Heinrich Schuchardt <[email protected]>
  Date:   2024-12-17 (Tue, 17 Dec 2024)

  Changed paths:
    A pc-bios/descriptors/60-edk2-riscv64.json
    M pc-bios/descriptors/meson.build

  Log Message:
  -----------
  pc-bios: add missing riscv64 descriptor

Without descriptor libvirt cannot discover the EDK II binaries via
the qemu:///system connection.

Signed-off-by: Heinrich Schuchardt <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Gerd Hoffmann <[email protected]>
(cherry picked from commit 74dc38d0c6c15fd57a5dee94125d13ac5b00491d)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: ad06bb324d3a87582e8d5a6b1cd420714cf6c681
      
https://github.com/qemu/qemu/commit/ad06bb324d3a87582e8d5a6b1cd420714cf6c681
  Author: Peter Maydell <[email protected]>
  Date:   2024-12-19 (Thu, 19 Dec 2024)

  Changed paths:
    M hw/intc/arm_gicv3_its.c

  Log Message:
  -----------
  hw/intc/arm_gicv3_its: Zero initialize local DTEntry etc structs

In the GICv3 ITS model, we have a common coding pattern which has a
local C struct like "DTEntry dte", which is a C representation of an
in-guest-memory data structure, and we call a function such as
get_dte() to read guest memory and fill in the C struct.  These
functions to read in the struct sometimes have cases where they will
leave early and not fill in the whole struct (for instance get_dte()
will set "dte->valid = false" and nothing else for the case where it
is passed an entry_addr implying that there is no L2 table entry for
the DTE).  This then causes potential use of uninitialized memory
later, for instance when we call a trace event which prints all the
fields of the struct.  Sufficiently advanced compilers may produce
-Wmaybe-uninitialized warnings about this, especially if LTO is
enabled.

Rather than trying to carefully separate out these trace events into
"only the 'valid' field is initialized" and "all fields can be
printed", zero-init all the structs when we define them. None of
these structs are large (the biggest is 24 bytes) and having
consistent behaviour is less likely to be buggy.

Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2718
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit 9678b9c505725732353baefedb88b53c2eb8a184)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 42490ac98088a744113589aa75400d9db714776d
      
https://github.com/qemu/qemu/commit/42490ac98088a744113589aa75400d9db714776d
  Author: Thomas Huth <[email protected]>
  Date:   2024-12-20 (Fri, 20 Dec 2024)

  Changed paths:
    M meson.build

  Log Message:
  -----------
  meson.build: Disallow libnfs v6 to fix the broken macOS build

The macOS builds in our CI (and possibly other very recent distros)
are currently broken since the update to libnfs version 6 there.
That version apparently comes with a big API breakage. v5.0.3 was
the final release of the old API (see the libnfs commit here:
https://github.com/sahlberg/libnfs/commit/4379837 ).

Disallow version 6.x for now to get the broken CI job working
again. Once somebody had enough time to adapt our code in
block/nfs.c, we can revert this change again.

Message-ID: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit e2d98f257138b83b6a492d1da5847a7fe0930d10)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 2dc652961d6a9508d5db140765a0b22238165d88
      
https://github.com/qemu/qemu/commit/2dc652961d6a9508d5db140765a0b22238165d88
  Author: Maciej S. Szmigiero <[email protected]>
  Date:   2024-12-22 (Sun, 22 Dec 2024)

  Changed paths:
    M accel/kvm/kvm-all.c
    M configs/targets/i386-softmmu.mak
    M configs/targets/x86_64-softmmu.mak
    M include/sysemu/kvm.h
    M target/i386/kvm/kvm.c

  Log Message:
  -----------
  target/i386: Reset TSCs of parked vCPUs too on VM reset

Since commit 5286c3662294 ("target/i386: properly reset TSC on reset")
QEMU writes the special value of "1" to each online vCPU TSC on VM reset
to reset it.

However parked vCPUs don't get that handling and due to that their TSCs
get desynchronized when the VM gets reset.
This in turn causes KVM to turn off PVCLOCK_TSC_STABLE_BIT in its exported
PV clock.
Note that KVM has no understanding of vCPU being currently parked.

Without PVCLOCK_TSC_STABLE_BIT the sched clock is marked unstable in
the guest's kvm_sched_clock_init().
This causes a performance regressions to show in some tests.

Fix this issue by writing the special value of "1" also to TSCs of parked
vCPUs on VM reset.

Reproducing the issue:
1) Boot a VM with "-smp 2,maxcpus=3" or similar

2) device_add 
host-x86_64-cpu,id=vcpu,node-id=0,socket-id=0,core-id=2,thread-id=0

3) Wait a few seconds

4) device_del vcpu

5) Inside the VM run:
# echo "t" >/proc/sysrq-trigger; dmesg | grep sched_clock_stable
Observe the sched_clock_stable() value is 1.

6) Reboot the VM

7) Once the VM boots once again run inside it:
# echo "t" >/proc/sysrq-trigger; dmesg | grep sched_clock_stable
Observe the sched_clock_stable() value is now 0.

Fixes: 5286c3662294 ("target/i386: properly reset TSC on reset")
Signed-off-by: Maciej S. Szmigiero <[email protected]>
Link: 
https://lore.kernel.org/r/5a605a88e9a231386dc803c60f5fed9b48108139.1734014926.git.maciej.szmigi...@oracle.com
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 3f2a05b31ee9ce2ddb6c75a9bc3f5e7f7af9a76f)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 19484ed99afb6f475000a4d54b9a7aa8c45778d7
      
https://github.com/qemu/qemu/commit/19484ed99afb6f475000a4d54b9a7aa8c45778d7
  Author: Yong-Xuan Wang <[email protected]>
  Date:   2024-12-22 (Sun, 22 Dec 2024)

  Changed paths:
    M hw/intc/riscv_aplic.c

  Log Message:
  -----------
  hw/intc/riscv_aplic: Fix APLIC in_clrip and clripnum write emulation

In the section "4.7 Precise effects on interrupt-pending bits"
of the RISC-V AIA specification defines that:

"If the source mode is Level1 or Level0 and the interrupt domain
is configured in MSI delivery mode (domaincfg.DM = 1):
The pending bit is cleared whenever the rectified input value is
low, when the interrupt is forwarded by MSI, or by a relevant
write to an in_clrip register or to clripnum."

Update the riscv_aplic_set_pending() to match the spec.

Fixes: bf31cf06eb ("hw/intc/riscv_aplic: Fix setipnum_le write emulation for 
APLIC MSI-mode")
Signed-off-by: Yong-Xuan Wang <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 0d0141fadc9063e527865ee420b2baf34e306093)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 9d913e012b4328dab3c6b4e07907f3b87675fede
      
https://github.com/qemu/qemu/commit/9d913e012b4328dab3c6b4e07907f3b87675fede
  Author: David Hildenbrand <[email protected]>
  Date:   2024-12-24 (Tue, 24 Dec 2024)

  Changed paths:
    M hw/s390x/s390-virtio-ccw.c

  Log Message:
  -----------
  s390x/s390-virtio-ccw: don't crash on weird RAM sizes

KVM is not happy when starting a VM with weird RAM sizes:

  # qemu-system-s390x --enable-kvm --nographic -m 1234K
  qemu-system-s390x: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION
    failed, slot=0, start=0x0, size=0x244000: Invalid argument
  kvm_set_phys_mem: error registering slot: Invalid argument
  Aborted (core dumped)

Let's handle that in a better way by rejecting such weird RAM sizes
right from the start:

  # qemu-system-s390x --enable-kvm --nographic -m 1234K
  qemu-system-s390x: ram size must be multiples of 1 MiB

Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Eric Farman <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Acked-by: Janosch Frank <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
(cherry picked from commit 14e568ab4836347481af2e334009c385f456a734)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 15eedfd2ff08e34fe19d86dd41d0ee646fa7774d
      
https://github.com/qemu/qemu/commit/15eedfd2ff08e34fe19d86dd41d0ee646fa7774d
  Author: Bibo Mao <[email protected]>
  Date:   2024-12-29 (Sun, 29 Dec 2024)

  Changed paths:
    M target/loongarch/tcg/insn_trans/trans_vec.c.inc

  Log Message:
  -----------
  target/loongarch: Use actual operand size with vbsrl check

Hardcoded 32 bytes is used for vbsrl emulation check, there is
problem when options lsx=on,lasx=off is used for vbsrl.v instruction
in TCG mode. It injects LASX exception rather LSX exception.

Here actual operand size is used.

Cc: [email protected]
Fixes: df97f338076 ("target/loongarch: Implement xvreplve xvinsve0 xvpickve")
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit d41989e7548397b469ec9c7be4cee699321a317e)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: ad09b3df7e885428ba1d814dae7d2e3fcfac2c39
      
https://github.com/qemu/qemu/commit/ad09b3df7e885428ba1d814dae7d2e3fcfac2c39
  Author: Philippe Mathieu-Daudé <[email protected]>
  Date:   2024-12-29 (Sun, 29 Dec 2024)

  Changed paths:
    M docs/about/deprecated.rst
    M docs/about/removed-features.rst

  Log Message:
  -----------
  docs: Correct '-runas' and '-fsdev/-virtfs proxy' indentation

Use the same style for deprecated / removed commands.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 916f50172baa91ddf0e669a9d6d2747055c0e610)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 64092b346494bae2c366de15d32f83b4fae0594d
      
https://github.com/qemu/qemu/commit/64092b346494bae2c366de15d32f83b4fae0594d
  Author: Philippe Mathieu-Daudé <[email protected]>
  Date:   2024-12-29 (Sun, 29 Dec 2024)

  Changed paths:
    M docs/about/removed-features.rst

  Log Message:
  -----------
  docs: Correct release of TCG trace-events removal

TCG trace-events were deprecated before the v6.2 release,
and removed for v7.0.

Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit b4859e8f33a7d9c793a60395f792c10190cb4f78)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 9bbaadbf9cfb5ae60e3ecff00ef56283e21fbfb7
      
https://github.com/qemu/qemu/commit/9bbaadbf9cfb5ae60e3ecff00ef56283e21fbfb7
  Author: Han Han <[email protected]>
  Date:   2024-12-29 (Sun, 29 Dec 2024)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  target/i386/cpu: Fix notes for CPU models

Fixes: 644e3c5d812 ("missing vmx features for Skylake-Server and 
Cascadelake-Server")
Signed-off-by: Han Han <[email protected]>
Reviewed-by: Chenyi Qiang <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 93dcc9390e5ad0696ae7e9b7b3a5b08c2d1b6de6)
Signed-off-by: Michael Tokarev <[email protected]>


Compare: https://github.com/qemu/qemu/compare/ae35f033b874...9bbaadbf9cfb

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications

Reply via email to