Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
Hi On 07-06-2019 20:46, Salvatore Bonaccorso wrote: > I just have uploaded 1:3.1+dfsg-8~deb10u1 for buster to get that > sorted out. Could you please accept it for buster? Unblocked, thanks. Paul signature.asc Description: OpenPGP digital signature
Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
Hi Paul, Michael, Jonathan, On Tue, Jun 04, 2019 at 09:27:55PM +0200, Paul Gevers wrote: > Hi Michael, Jonathan, > > On Tue, 4 Jun 2019 14:11:23 +0100 Jonathan Wiltshire wrote: > > On Mon, May 27, 2019 at 08:23:09AM +0300, Michael Tokarev wrote: > > > I've prepared next release of the qemu debian package, with > > > a few bugfixes, and am asking if it's okay to upload these > > > changes to unstable (targetting buster). The change includes > > > 3 security fixes which should go anyway, and 2 "other" fixes > > > which are questionable, hence the pre-approval bugreport/question. > > > > Unblocked; thanks. > > qemus migration is blocked by gcc-8, which nobody unblocked so far, so > that is probably not going to happen. I think this should be fixed via tpu. I just have uploaded 1:3.1+dfsg-8~deb10u1 for buster to get that sorted out. Could you please accept it for buster? Regards, Salvatore diff -Nru qemu-3.1+dfsg/debian/changelog qemu-3.1+dfsg/debian/changelog --- qemu-3.1+dfsg/debian/changelog 2019-05-27 06:49:25.0 +0200 +++ qemu-3.1+dfsg/debian/changelog 2019-06-07 20:42:24.0 +0200 @@ -1,3 +1,10 @@ +qemu (1:3.1+dfsg-8~deb10u1) buster; urgency=medium + + * Non-maintainer upload. + * Rebuild for buster (Cf. #929607) + + -- Salvatore Bonaccorso Fri, 07 Jun 2019 20:42:24 +0200 + qemu (1:3.1+dfsg-8) unstable; urgency=high * sun4u-add-power_mem_read-routine-CVE-2019-5008.patch
Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
> "Moritz" == Moritz Mühlenhoff writes: Moritz> There's an existing unblock request for gcc-8 at #928188 What's going on here? Did you believe Paul was unaware of that request?
Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
> "Moritz" == Moritz Mühlenhoff writes: Moritz> On Tue, Jun 04, 2019 at 09:27:55PM +0200, Paul Gevers wrote: >> Hi Michael, Jonathan, >> >> On Tue, 4 Jun 2019 14:11:23 +0100 Jonathan Wiltshire wrote: >> > On Mon, May 27, 2019 at 08:23:09AM +0300, Michael Tokarev wrote: >> > > I've prepared next release of the qemu debian package, with > >> > a few bugfixes, and am asking if it's okay to upload these > > >> changes to unstable (targetting buster). The change includes > > >> 3 security fixes which should go anyway, and 2 "other" fixes > > >> which are questionable, hence the pre-approval >> bugreport/question. >> > >> > Unblocked; thanks. >> >> qemus migration is blocked by gcc-8, which nobody unblocked so >> far, so that is probably not going to happen. I think this should >> be fixed via tpu. Moritz> There's an existing unblock request for gcc-8 at #928188 I think Paul is aware of that request. I know from other mail that the release team is quite aware. If you compare that request to requests that have been approved, you will seeit is more consistent with requests that get turned down or that time out than those that get approved.
Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
On Tue, Jun 04, 2019 at 09:27:55PM +0200, Paul Gevers wrote: > Hi Michael, Jonathan, > > On Tue, 4 Jun 2019 14:11:23 +0100 Jonathan Wiltshire wrote: > > On Mon, May 27, 2019 at 08:23:09AM +0300, Michael Tokarev wrote: > > > I've prepared next release of the qemu debian package, with > > > a few bugfixes, and am asking if it's okay to upload these > > > changes to unstable (targetting buster). The change includes > > > 3 security fixes which should go anyway, and 2 "other" fixes > > > which are questionable, hence the pre-approval bugreport/question. > > > > Unblocked; thanks. > > qemus migration is blocked by gcc-8, which nobody unblocked so far, so > that is probably not going to happen. I think this should be fixed via tpu. There's an existing unblock request for gcc-8 at #928188 Cheers, Moritz
Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
Hi Michael, Jonathan, On Tue, 4 Jun 2019 14:11:23 +0100 Jonathan Wiltshire wrote: > On Mon, May 27, 2019 at 08:23:09AM +0300, Michael Tokarev wrote: > > I've prepared next release of the qemu debian package, with > > a few bugfixes, and am asking if it's okay to upload these > > changes to unstable (targetting buster). The change includes > > 3 security fixes which should go anyway, and 2 "other" fixes > > which are questionable, hence the pre-approval bugreport/question. > > Unblocked; thanks. qemus migration is blocked by gcc-8, which nobody unblocked so far, so that is probably not going to happen. I think this should be fixed via tpu. Paul signature.asc Description: OpenPGP digital signature
Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
Control: tags -1 moreinfo confirmed Michael Tokarev: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Hi! > I've prepared next release of the qemu debian package, with > a few bugfixes, and am asking if it's okay to upload these > changes to unstable (targetting buster). The change includes > 3 security fixes which should go anyway, and 2 "other" fixes > which are questionable, hence the pre-approval bugreport/question. > > All changes are "easy" ones, and are mostly one-liners and are > easy for review. All bugfixes has been appied upstream too. > > Is it okay for the changes to go to buster? > > Thanks, > > /mjt > > [...] > + > unblock qemu/1:3.1+dfsg-8 > > [...] > Please go ahead with the upload and remove the moreinfo tag once it is ready to be unblocked. Thanks, ~Niels
Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi!
I've prepared next release of the qemu debian package, with
a few bugfixes, and am asking if it's okay to upload these
changes to unstable (targetting buster). The change includes
3 security fixes which should go anyway, and 2 "other" fixes
which are questionable, hence the pre-approval bugreport/question.
All changes are "easy" ones, and are mostly one-liners and are
easy for review. All bugfixes has been appied upstream too.
Is it okay for the changes to go to buster?
Thanks,
/mjt
diff -Nru qemu-3.1+dfsg/debian/changelog qemu-3.1+dfsg/debian/changelog
--- qemu-3.1+dfsg/debian/changelog 2019-03-27 14:24:06.0 +0300
+++ qemu-3.1+dfsg/debian/changelog 2019-05-27 07:49:25.0 +0300
@@ -1,3 +1,23 @@
+qemu (1:3.1+dfsg-8) unstable; urgency=high
+
+ * sun4u-add-power_mem_read-routine-CVE-2019-5008.patch
+fixes a null-pointer dereference in sparc/sun4u emulated hw
+Closes: #927439, CVE-2019-5008
+ * enable-md-no.patch & enable-md-clear.patch
+mitigation for MDS (Microarchitectural Data Sampling) issues
+Closes: #929067,
+CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091
+ * qxl-check-release-info-object-CVE-2019-12155.patch
+fixes null-pointer deref in qxl cleanup code
+Closes: #929353, CVE-2019-12155
+ * aarch32-exception-return-to-switch-from-hyp-mon.patch
+fixes booting U-Boot in UEFI mode on aarch32
+Closes: #927763
+ * stop qemu-system-common pre-depending on adduser
+Closes: #929261
+
+ -- Michael Tokarev Mon, 27 May 2019 07:49:25 +0300
+
qemu (1:3.1+dfsg-7) unstable; urgency=high
[ Michael Tokarev ]
diff -Nru qemu-3.1+dfsg/debian/control qemu-3.1+dfsg/debian/control
--- qemu-3.1+dfsg/debian/control2019-03-11 14:35:35.0 +0300
+++ qemu-3.1+dfsg/debian/control2019-05-27 07:49:25.0 +0300
@@ -191,7 +191,6 @@
Package: qemu-system-common
Architecture: amd64 arm arm64 armel armhf i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el
s390x sparc sparc64 x32
Multi-Arch: foreign
-Pre-Depends: adduser
Replaces: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
Breaks: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
Depends: ${misc:Depends}, ${shlibs:Depends},
diff -Nru qemu-3.1+dfsg/debian/control-in qemu-3.1+dfsg/debian/control-in
--- qemu-3.1+dfsg/debian/control-in 2019-03-11 14:19:34.0 +0300
+++ qemu-3.1+dfsg/debian/control-in 2019-05-27 07:49:25.0 +0300
@@ -196,7 +196,6 @@
Package: qemu-system-common
Architecture: amd64 arm arm64 armel armhf i386 ia64 kfreebsd-amd64
kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el
s390x sparc sparc64 x32
Multi-Arch: foreign
-Pre-Depends: adduser
Replaces: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
Breaks: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
Depends: ${misc:Depends}, ${shlibs:Depends},
diff -Nru
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
---
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
1970-01-01 03:00:00.0 +0300
+++
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
2019-05-27 07:46:35.0 +0300
@@ -0,0 +1,56 @@
+From: Alexander Graf
+Date: Mon, 21 Jan 2019 10:23:11 +
+Subject: target/arm: Allow Aarch32 exception return to switch from Mon->Hyp
+Commit-Id: 2d2a4549cc29850aab891495685a7b31f5254b12
+Bug-Debian: http://bugs.debian.org/927763
+
+In U-boot, we switch from S-SVC -> Mon -> Hyp mode when we want to
+enter Hyp mode. The change into Hyp mode is done by doing an
+exception return from Mon. This doesn't work with current QEMU.
+
+The problem is that in bad_mode_switch() we refuse to allow
+the change of mode.
+
+Note that bad_mode_switch() is used to do validation for two situations:
+
+ (1) changes to mode by instructions writing to CPSR.M
+ (ie not exception take/return) -- this corresponds to the
+ Armv8 Arm ARM pseudocode Arch32.WriteModeByInstr
+ (2) changes to mode by exception return
+
+Attempting to enter or leave Hyp mode via case (1) is forbidden in
+v8 and UNPREDICTABLE in v7, and QEMU is correct to disallow it
+there. However, we're already doing that check at the top of the
+bad_mode_switch() function, so if that passes then we should allow
+the case (2) exception return mode changes to switch into Hyp mode.
+
+We want to test whether we're trying to return to the nonexistent
+"secure Hyp" mode, so we need to look at arm_is_secure_below_el3()
+rather than arm_is_secure(), since the latter is always true if
+we're in Mon (EL3).
+
+Signed-off-by: Alexander Graf
+Reviewed-by: Peter Maydell
+Message-id:
