* Re: Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory
@ 2015-12-21 23:10 Eric Shelton
2015-12-22 12:24 ` Stefano Stabellini
0 siblings, 1 reply; 9+ messages in thread
From: Eric Shelton @ 2015-12-21 23:10 UTC (permalink / raw)
To: xen-devel@lists.xen.org, Stefano Stabellini, Samuel Thibault,
security
[-- Attachment #1.1: Type: text/plain, Size: 8792 bytes --]
Seeing as "All OSes providing PV backends are susceptible," doesn't this
include MiniOS for QEMU stubdom as well? Are there patches available for
mini-os/blkfront.c, mini-os/netfront.c, and mini-os/pcifront.c? I didn't
see anything for this.
Best,
Eric
On Thu, Dec 17, 2015 at 1:36 PM, Xen.org security team <security@xen.org>
wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Xen Security Advisory CVE-2015-8550 / XSA-155
> version 6
>
> paravirtualized drivers incautious about shared memory contents
>
> UPDATES IN VERSION 6
> ====================
>
> Correct CREDITS section.
>
> ISSUE DESCRIPTION
> =================
>
> The compiler can emit optimizations in the PV backend drivers which
> can lead to double fetch vulnerabilities. Specifically the shared
> memory between the frontend and backend can be fetched twice (during
> which time the frontend can alter the contents) possibly leading to
> arbitrary code execution in backend.
>
> IMPACT
> ======
>
> Malicious guest administrators can cause denial of service. If driver
> domains are not in use, the impact can be a host crash, or privilege
> escalation.
>
> VULNERABLE SYSTEMS
> ==================
>
> Systems running PV or HVM guests are vulnerable.
>
> ARM and x86 systems are vulnerable.
>
> All OSes providing PV backends are susceptible, this includes
> Linux and NetBSD. By default the Linux distributions compile kernels
> with optimizations.
>
> MITIGATION
> ==========
>
> There is no mitigation.
>
> CREDITS
> =======
>
> This issue was discovered by Felix Wilhelm (ERNW Research, KIT /
> Operating Systems Group).
>
> RESOLUTION
> ==========
>
> Applying the appropriate attached patches should fix the problem for
> PV backends. Note only that PV backends are fixed; PV frontend
> patches will be developed and released (publicly) after the embargo
> date.
>
> Please note that there is a bug in some versions of gcc,
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 which can cause the
> construct used in RING_COPY_REQUEST() to be ineffective in some
> circumstances. We have determined that this is only the case when the
> structure being copied consists purely of bitfields. The Xen PV
> protocols updated here do not use bitfields in this way and therefore
> these patches are not subject to that bug. However authors of third
> party PV protocols should take this into consideration.
>
> Linux v4.4:
> xsa155-linux-xsa155-0001-xen-Add-RING_COPY_REQUEST.patch
>
> xsa155-linux-xsa155-0002-xen-netback-don-t-use-last-request-to-determine-mini.patch
> xsa155-linux-xsa155-0003-xen-netback-use-RING_COPY_REQUEST-throughout.patch
>
> xsa155-linux-xsa155-0004-xen-blkback-only-read-request-operation-from-shared-.patch
>
> xsa155-linux-xsa155-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch
> xsa155-linux-xsa155-0006-xen-scsiback-safely-copy-requests.patch
>
> xsa155-linux-xsa155-0007-xen-pciback-Save-xen_pci_op-commands-before-processi.patch
> Linux v4.[0,1,2,3]
> All the above patches except #5 will apply, please use:
>
> xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch
> Linux v3.19:
> All the above patches except #5 and #6 will apply, please use:
>
> xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch
> xsa155-linux319-0006-xen-scsiback-safely-copy-requests.patch
>
> qemu-xen:
> xsa155-qemu-qdisk-double-access.patch
> xsa155-qemu-xenfb.patch
>
> qemu-traditional:
> xsa155-qemut-qdisk-double-access.patch
> xsa155-qemut-xenfb.patch
>
> NetBSD 7.0:
> xsa155-netbsd-xsa155-0001-netbsd-xen-Add-RING_COPY_REQUEST.patch
>
> xsa155-netbsd-xsa155-0002-netbsd-netback-Use-RING_COPY_REQUEST-instead-of-RING.patch
>
> xsa155-netbsd-xsa155-0003-netbsd-ring-Add-barrier-to-provide-an-compiler-barri.patch
>
> xsa155-netbsd-xsa155-0004-netbsd-block-only-read-request-operation-from-shared.patch
>
> xsa155-netbsd-xsa155-0005-netbsd-pciback-Operate-on-local-version-of-xen_pci_o.patch
>
> xen:
> xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch
> xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch
> xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch
>
> xen 4.4:
> All patches except #3 will apply, please use:
> xsa155-xen44-0003-libvchan-Read-prod-cons-only-once.patch
>
> $ sha256sum xsa155*
> d9fbc104ab2ae797971e351ee0e04e7b7e9c7c33385309bb406c7941dc9a33b4
> xsa155-linux319-xsa155-0006-xen-scsiback-safely-copy-requests.patch
> 590656d83ad7b6052b54659eccb3469658b3942c0dc1366423a66f2f5ac643e1
> xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch
> 2bd18632178e09394c5cd06aded2c14bcc6b6e360ad6e81827d24860fe3e8ca4
> xsa155-linux-xsa155-0001-xen-Add-RING_COPY_REQUEST.patch
> cecdeccb8e2551252c81fc5f164a8298005df714a574a7ba18b84e8ed5f2bb70
> xsa155-linux-xsa155-0002-xen-netback-don-t-use-last-request-to-determine-mini.patch
> 3916b847243047f0e1053233ade742c14a7f29243584e60bf5db4842a8068855
> xsa155-linux-xsa155-0003-xen-netback-use-RING_COPY_REQUEST-throughout.patch
> 746c8eb0aeb200d76156c88dfbbd49db79f567b88b07eda70f7c7d095721f05a
> xsa155-linux-xsa155-0004-xen-blkback-only-read-request-operation-from-shared-.patch
> 18517a184a02f7441065b8d3423086320ec4c2345c00d551231f7976381767f5
> xsa155-linux-xsa155-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch
> 2e6d556d25b1cc16e71afde665ae3908f4fa8eab7e0d96283fc78400301baf92
> xsa155-linux-xsa155-0006-xen-scsiback-safely-copy-requests.patch
> 5e130d8b61906015c6a94f8edd3cce97b172f96a265d97ecf370e7b45125b73d
> xsa155-linux-xsa155-0007-xen-pciback-Save-xen_pci_op-commands-before-processi.patch
> 08c2d0f95dcc215165afbce623b6972b81dd45b091b5f40017579b00c8612e03
> xsa155-netbsd-xsa155-0001-netbsd-xen-Add-RING_COPY_REQUEST.patch
> 0a66010f736092f91f70bb0fd220685e4395efef1db6d23a3d1eace31d144f51
> xsa155-netbsd-xsa155-0002-netbsd-netback-Use-RING_COPY_REQUEST-instead-of-RING.patch
> 5e913a8427cab6b4d384d1246e05116afc301eb117edd838101eb53a82c2f2ff
> xsa155-netbsd-xsa155-0003-netbsd-ring-Add-barrier-to-provide-an-compiler-barri.patch
> 3b8f14eafaed3a7bc66245753a37af4249acf8129fbedb70653192252dc47dc9
> xsa155-netbsd-xsa155-0004-netbsd-block-only-read-request-operation-from-shared.patch
> 81ae5fa998243a78dad749fc561be647dc1dc1be799e8f18484fdf0989469705
> xsa155-netbsd-xsa155-0005-netbsd-pciback-Operate-on-local-version-of-xen_pci_o.patch
> 044ff74fa048df820d528f64f2791ec9cb3940bd313c1179020bd49a6cde2ca3
> xsa155-qemu-qdisk-double-access.patch
> 1150504589eb7bfa108c80ce63395e57d0e627b12d9201219d968fdd026919a6
> xsa155-qemut-qdisk-double-access.patch
> 63186246ab6913b54bfef5f09f33e815935ac40ff821c27a3efda62339bbbd5f
> xsa155-qemut-xenfb.patch
> e53b4ac298648cde79344192d5a58ca8d8724344f5105bec7c09eef095c668f6
> xsa155-qemu-xenfb.patch
> e52467fcec73bcc86d3e96d06f8ca8085ae56a83d2c42a30c16bc3dc630d8f8a
> xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch
> eae34c8ccc096ad93a74190506b3d55020a88afb0cc504a3a514590e9fd746fd
> xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch
> 42780265014085a4221ad32b026214693d751789eb5219e2e83862c0006c66f4
> xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch
> dfcaddb8a908a4fc1b048a43187e885117e67dc566f5c841037ee366dcd437d1
> xsa155-xen44-0003-libvchan-Read-prod-cons-only-once.patch
> $
>
> DEPLOYMENT DURING EMBARGO
> =========================
>
> Deployment of the patches and/or mitigations described above (or
> others which are substantially similar) is permitted during the
> embargo, even on public-facing systems with untrusted guest users and
> administrators.
>
> But: Distribution of updated software is prohibited (except to other
> members of the predisclosure list).
>
> Predisclosure list members who wish to deploy significantly different
> patches and/or mitigations, please contact the Xen Project Security
> Team.
>
> (Note: this during-embargo deployment notice is retained in
> post-embargo publicly released Xen Project advisories, even though it
> is then no longer applicable. This is to enable the community to have
> oversight of the Xen Project Security Team's decisionmaking.)
>
> For more information about permissible uses of embargoed information,
> consult the Xen Project community's agreed Security Policy:
> http://www.xenproject.org/security-policy.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQEcBAEBAgAGBQJWcrpdAAoJEIP+FMlX6CvZ9soIALqQ/GHP6bZn2LqJTD9DIzsm
> zVB4yCPiVfDqHSOq9QNCzBzqpvOX+RhKTzRH1jsZczr8CSnkePxaCrmZgH8SAygB
> hFcF9xJGlJDjs647sgpQmYs++3mgD/57uml7IW/8NX46tXUelVByW7muNgUN2xlm
> kjeD8auJEs+jK1iwpt/hOmYe4moRx3+3ujfgqMCNAWtqZz9D9wM5tao+p6yKYlhM
> u8hSi1V3b7sAbf92mwzpzfpbwdgg25xeHtZ/oJxp/ZY0FhqDEsTxV+h8HjD/Eink
> GwqPS19O77tMmz9fUUTyJDSsU7ayFRI0HyYmXju4eJktJkhXagjAdCSyGky9z5g=
> =FlX2
> -----END PGP SIGNATURE-----
>
[-- Attachment #1.2: Type: text/html, Size: 9922 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory 2015-12-21 23:10 Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory Eric Shelton @ 2015-12-22 12:24 ` Stefano Stabellini 2015-12-22 13:19 ` Samuel Thibault 2015-12-22 15:06 ` Eric Shelton 0 siblings, 2 replies; 9+ messages in thread From: Stefano Stabellini @ 2015-12-22 12:24 UTC (permalink / raw) To: Eric Shelton Cc: Samuel Thibault, Stefano Stabellini, security, xen-devel@lists.xen.org [-- Attachment #1: Type: text/plain, Size: 10439 bytes --] MiniOS for QEMU stubdom has frontends, such as mini-os/blkfront.c and mini-os/netfront.c, not backends. Cheers, Stefano On Mon, 21 Dec 2015, Eric Shelton wrote: > Seeing as "All OSes providing PV backends are susceptible," doesn't this include MiniOS for QEMU stubdom as well? > Are there patches available for mini-os/blkfront.c, mini-os/netfront.c, and mini-os/pcifront.c? I didn't see > anything for this. > Best, > Eric > > On Thu, Dec 17, 2015 at 1:36 PM, Xen.org security team <security@xen.org> wrote: > > ----- Topal: Output generated on Tue Dec 22 12:23:44 GMT 2015 ----- Topal: GPG output starts ----- gpg: > no valid OpenPGP data found. gpg: processing message failed: eof ----- Topal: GPG output ends ----- > ----- Topal: Original message starts ----- -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Xen Security Advisory CVE-2015-8550 / XSA-155 > version 6 > > paravirtualized drivers incautious about shared memory contents > > UPDATES IN VERSION 6 > ==================== > > Correct CREDITS section. > > ISSUE DESCRIPTION > ================= > > The compiler can emit optimizations in the PV backend drivers which > can lead to double fetch vulnerabilities. Specifically the shared > memory between the frontend and backend can be fetched twice (during > which time the frontend can alter the contents) possibly leading to > arbitrary code execution in backend. > > IMPACT > ====== > > Malicious guest administrators can cause denial of service. If driver > domains are not in use, the impact can be a host crash, or privilege escalation. > > VULNERABLE SYSTEMS > ================== > > Systems running PV or HVM guests are vulnerable. > > ARM and x86 systems are vulnerable. > > All OSes providing PV backends are susceptible, this includes > Linux and NetBSD. By default the Linux distributions compile kernels > with optimizations. > > MITIGATION > ========== > > There is no mitigation. > > CREDITS > ======= > > This issue was discovered by Felix Wilhelm (ERNW Research, KIT / > Operating Systems Group). > > RESOLUTION > ========== > > Applying the appropriate attached patches should fix the problem for > PV backends. Note only that PV backends are fixed; PV frontend > patches will be developed and released (publicly) after the embargo > date. > > Please note that there is a bug in some versions of gcc, > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 which can cause the > construct used in RING_COPY_REQUEST() to be ineffective in some > circumstances. We have determined that this is only the case when the > structure being copied consists purely of bitfields. The Xen PV > protocols updated here do not use bitfields in this way and therefore > these patches are not subject to that bug. However authors of third > party PV protocols should take this into consideration. > > Linux v4.4: > xsa155-linux-xsa155-0001-xen-Add-RING_COPY_REQUEST.patch > xsa155-linux-xsa155-0002-xen-netback-don-t-use-last-request-to-determine-mini.patch > xsa155-linux-xsa155-0003-xen-netback-use-RING_COPY_REQUEST-throughout.patch > xsa155-linux-xsa155-0004-xen-blkback-only-read-request-operation-from-shared-.patch > xsa155-linux-xsa155-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch > xsa155-linux-xsa155-0006-xen-scsiback-safely-copy-requests.patch > xsa155-linux-xsa155-0007-xen-pciback-Save-xen_pci_op-commands-before-processi.patch > Linux v4.[0,1,2,3] > All the above patches except #5 will apply, please use: > xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch > Linux v3.19: > All the above patches except #5 and #6 will apply, please use: > xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch > xsa155-linux319-0006-xen-scsiback-safely-copy-requests.patch > > qemu-xen: > xsa155-qemu-qdisk-double-access.patch > xsa155-qemu-xenfb.patch > > qemu-traditional: > xsa155-qemut-qdisk-double-access.patch > xsa155-qemut-xenfb.patch > > NetBSD 7.0: > xsa155-netbsd-xsa155-0001-netbsd-xen-Add-RING_COPY_REQUEST.patch > xsa155-netbsd-xsa155-0002-netbsd-netback-Use-RING_COPY_REQUEST-instead-of-RING.patch > xsa155-netbsd-xsa155-0003-netbsd-ring-Add-barrier-to-provide-an-compiler-barri.patch > xsa155-netbsd-xsa155-0004-netbsd-block-only-read-request-operation-from-shared.patch > xsa155-netbsd-xsa155-0005-netbsd-pciback-Operate-on-local-version-of-xen_pci_o.patch > > xen: > xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch > xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch > xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch > > xen 4.4: > All patches except #3 will apply, please use: > xsa155-xen44-0003-libvchan-Read-prod-cons-only-once.patch > > $ sha256sum xsa155* > d9fbc104ab2ae797971e351ee0e04e7b7e9c7c33385309bb406c7941dc9a33b4 > xsa155-linux319-xsa155-0006-xen-scsiback-safely-copy-requests.patch > 590656d83ad7b6052b54659eccb3469658b3942c0dc1366423a66f2f5ac643e1 > xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch > 2bd18632178e09394c5cd06aded2c14bcc6b6e360ad6e81827d24860fe3e8ca4 > xsa155-linux-xsa155-0001-xen-Add-RING_COPY_REQUEST.patch > cecdeccb8e2551252c81fc5f164a8298005df714a574a7ba18b84e8ed5f2bb70 > xsa155-linux-xsa155-0002-xen-netback-don-t-use-last-request-to-determine-mini.patch > 3916b847243047f0e1053233ade742c14a7f29243584e60bf5db4842a8068855 > xsa155-linux-xsa155-0003-xen-netback-use-RING_COPY_REQUEST-throughout.patch > 746c8eb0aeb200d76156c88dfbbd49db79f567b88b07eda70f7c7d095721f05a > xsa155-linux-xsa155-0004-xen-blkback-only-read-request-operation-from-shared-.patch > 18517a184a02f7441065b8d3423086320ec4c2345c00d551231f7976381767f5 > xsa155-linux-xsa155-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch > 2e6d556d25b1cc16e71afde665ae3908f4fa8eab7e0d96283fc78400301baf92 > xsa155-linux-xsa155-0006-xen-scsiback-safely-copy-requests.patch > 5e130d8b61906015c6a94f8edd3cce97b172f96a265d97ecf370e7b45125b73d > xsa155-linux-xsa155-0007-xen-pciback-Save-xen_pci_op-commands-before-processi.patch > 08c2d0f95dcc215165afbce623b6972b81dd45b091b5f40017579b00c8612e03 > xsa155-netbsd-xsa155-0001-netbsd-xen-Add-RING_COPY_REQUEST.patch > 0a66010f736092f91f70bb0fd220685e4395efef1db6d23a3d1eace31d144f51 > xsa155-netbsd-xsa155-0002-netbsd-netback-Use-RING_COPY_REQUEST-instead-of-RING.patch > 5e913a8427cab6b4d384d1246e05116afc301eb117edd838101eb53a82c2f2ff > xsa155-netbsd-xsa155-0003-netbsd-ring-Add-barrier-to-provide-an-compiler-barri.patch > 3b8f14eafaed3a7bc66245753a37af4249acf8129fbedb70653192252dc47dc9 > xsa155-netbsd-xsa155-0004-netbsd-block-only-read-request-operation-from-shared.patch > 81ae5fa998243a78dad749fc561be647dc1dc1be799e8f18484fdf0989469705 > xsa155-netbsd-xsa155-0005-netbsd-pciback-Operate-on-local-version-of-xen_pci_o.patch > 044ff74fa048df820d528f64f2791ec9cb3940bd313c1179020bd49a6cde2ca3 xsa155-qemu-qdisk-double-access.patch > 1150504589eb7bfa108c80ce63395e57d0e627b12d9201219d968fdd026919a6 > xsa155-qemut-qdisk-double-access.patch > 63186246ab6913b54bfef5f09f33e815935ac40ff821c27a3efda62339bbbd5f xsa155-qemut-xenfb.patch > e53b4ac298648cde79344192d5a58ca8d8724344f5105bec7c09eef095c668f6 xsa155-qemu-xenfb.patch > e52467fcec73bcc86d3e96d06f8ca8085ae56a83d2c42a30c16bc3dc630d8f8a > xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch > eae34c8ccc096ad93a74190506b3d55020a88afb0cc504a3a514590e9fd746fd > xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch > 42780265014085a4221ad32b026214693d751789eb5219e2e83862c0006c66f4 > xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch > dfcaddb8a908a4fc1b048a43187e885117e67dc566f5c841037ee366dcd437d1 > xsa155-xen44-0003-libvchan-Read-prod-cons-only-once.patch > $ > > DEPLOYMENT DURING EMBARGO > ========================= > > Deployment of the patches and/or mitigations described above (or > others which are substantially similar) is permitted during the > embargo, even on public-facing systems with untrusted guest users and > administrators. > > But: Distribution of updated software is prohibited (except to other > members of the predisclosure list). > > Predisclosure list members who wish to deploy significantly different > patches and/or mitigations, please contact the Xen Project Security > Team. > > (Note: this during-embargo deployment notice is retained in > post-embargo publicly released Xen Project advisories, even though it > is then no longer applicable. This is to enable the community to have > oversight of the Xen Project Security Team's decisionmaking.) > > For more information about permissible uses of embargoed information, > consult the Xen Project community's agreed Security Policy: > http://www.xenproject.org/security-policy.html > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQEcBAEBAgAGBQJWcrpdAAoJEIP+FMlX6CvZ9soIALqQ/GHP6bZn2LqJTD9DIzsm > zVB4yCPiVfDqHSOq9QNCzBzqpvOX+RhKTzRH1jsZczr8CSnkePxaCrmZgH8SAygB > hFcF9xJGlJDjs647sgpQmYs++3mgD/57uml7IW/8NX46tXUelVByW7muNgUN2xlm > kjeD8auJEs+jK1iwpt/hOmYe4moRx3+3ujfgqMCNAWtqZz9D9wM5tao+p6yKYlhM > u8hSi1V3b7sAbf92mwzpzfpbwdgg25xeHtZ/oJxp/ZY0FhqDEsTxV+h8HjD/Eink > GwqPS19O77tMmz9fUUTyJDSsU7ayFRI0HyYmXju4eJktJkhXagjAdCSyGky9z5g= > =FlX2 > -----END PGP SIGNATURE----- > > ----- Topal: Original message ends ----- > [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory 2015-12-22 12:24 ` Stefano Stabellini @ 2015-12-22 13:19 ` Samuel Thibault 2015-12-22 15:06 ` Eric Shelton 1 sibling, 0 replies; 9+ messages in thread From: Samuel Thibault @ 2015-12-22 13:19 UTC (permalink / raw) To: Stefano Stabellini; +Cc: xen-devel@lists.xen.org, security, Eric Shelton Stefano Stabellini, on Tue 22 Dec 2015 12:24:35 +0000, wrote: > MiniOS for QEMU stubdom has frontends, such as mini-os/blkfront.c and > mini-os/netfront.c, not backends. There is one backend, tpmback. It however doesn't use a ring. Samuel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory 2015-12-22 12:24 ` Stefano Stabellini 2015-12-22 13:19 ` Samuel Thibault @ 2015-12-22 15:06 ` Eric Shelton 2016-01-04 13:06 ` Marek Marczykowski-Górecki 1 sibling, 1 reply; 9+ messages in thread From: Eric Shelton @ 2015-12-22 15:06 UTC (permalink / raw) To: Stefano Stabellini Cc: minios-devel, Samuel Thibault, security, xen-devel@lists.xen.org The XSA mentions that "PV frontend patches will be developed and released (publicly) after the embargo date." Has anything been done towards this that should also be incorporated into MiniOS? On a system utilizing a "driver domain," where a backend is running on a domain that is considered unprivileged and untrusted (such as the example described in http://wiki.xenproject.org/wiki/Driver_Domain), it seems XSA-155-style double fetch vulnerabilities in the frontends are also a potential security concern, and should be eliminated. However, perhaps that does not include pcifront, since pciback would always be running in dom0. Eric On Tue, Dec 22, 2015 at 7:24 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote: > MiniOS for QEMU stubdom has frontends, such as mini-os/blkfront.c and > mini-os/netfront.c, not backends. > > Cheers, > > Stefano > > > On Mon, 21 Dec 2015, Eric Shelton wrote: >> Seeing as "All OSes providing PV backends are susceptible," doesn't this include MiniOS for QEMU stubdom as well? >> Are there patches available for mini-os/blkfront.c, mini-os/netfront.c, and mini-os/pcifront.c? I didn't see >> anything for this. >> Best, >> Eric >> >> On Thu, Dec 17, 2015 at 1:36 PM, Xen.org security team <security@xen.org> wrote: >> >> ----- Topal: Output generated on Tue Dec 22 12:23:44 GMT 2015 ----- Topal: GPG output starts ----- gpg: >> no valid OpenPGP data found. gpg: processing message failed: eof ----- Topal: GPG output ends ----- >> ----- Topal: Original message starts ----- -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Xen Security Advisory CVE-2015-8550 / XSA-155 >> version 6 >> >> paravirtualized drivers incautious about shared memory contents >> >> UPDATES IN VERSION 6 >> ==================== >> >> Correct CREDITS section. >> >> ISSUE DESCRIPTION >> ================= >> >> The compiler can emit optimizations in the PV backend drivers which >> can lead to double fetch vulnerabilities. Specifically the shared >> memory between the frontend and backend can be fetched twice (during >> which time the frontend can alter the contents) possibly leading to >> arbitrary code execution in backend. >> >> IMPACT >> ====== >> >> Malicious guest administrators can cause denial of service. If driver >> domains are not in use, the impact can be a host crash, or privilege escalation. >> >> VULNERABLE SYSTEMS >> ================== >> >> Systems running PV or HVM guests are vulnerable. >> >> ARM and x86 systems are vulnerable. >> >> All OSes providing PV backends are susceptible, this includes >> Linux and NetBSD. By default the Linux distributions compile kernels >> with optimizations. >> >> MITIGATION >> ========== >> >> There is no mitigation. >> >> CREDITS >> ======= >> >> This issue was discovered by Felix Wilhelm (ERNW Research, KIT / >> Operating Systems Group). >> >> RESOLUTION >> ========== >> >> Applying the appropriate attached patches should fix the problem for >> PV backends. Note only that PV backends are fixed; PV frontend >> patches will be developed and released (publicly) after the embargo >> date. >> >> Please note that there is a bug in some versions of gcc, >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 which can cause the >> construct used in RING_COPY_REQUEST() to be ineffective in some >> circumstances. We have determined that this is only the case when the >> structure being copied consists purely of bitfields. The Xen PV >> protocols updated here do not use bitfields in this way and therefore >> these patches are not subject to that bug. However authors of third >> party PV protocols should take this into consideration. >> >> Linux v4.4: >> xsa155-linux-xsa155-0001-xen-Add-RING_COPY_REQUEST.patch >> xsa155-linux-xsa155-0002-xen-netback-don-t-use-last-request-to-determine-mini.patch >> xsa155-linux-xsa155-0003-xen-netback-use-RING_COPY_REQUEST-throughout.patch >> xsa155-linux-xsa155-0004-xen-blkback-only-read-request-operation-from-shared-.patch >> xsa155-linux-xsa155-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch >> xsa155-linux-xsa155-0006-xen-scsiback-safely-copy-requests.patch >> xsa155-linux-xsa155-0007-xen-pciback-Save-xen_pci_op-commands-before-processi.patch >> Linux v4.[0,1,2,3] >> All the above patches except #5 will apply, please use: >> xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch >> Linux v3.19: >> All the above patches except #5 and #6 will apply, please use: >> xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch >> xsa155-linux319-0006-xen-scsiback-safely-copy-requests.patch >> >> qemu-xen: >> xsa155-qemu-qdisk-double-access.patch >> xsa155-qemu-xenfb.patch >> >> qemu-traditional: >> xsa155-qemut-qdisk-double-access.patch >> xsa155-qemut-xenfb.patch >> >> NetBSD 7.0: >> xsa155-netbsd-xsa155-0001-netbsd-xen-Add-RING_COPY_REQUEST.patch >> xsa155-netbsd-xsa155-0002-netbsd-netback-Use-RING_COPY_REQUEST-instead-of-RING.patch >> xsa155-netbsd-xsa155-0003-netbsd-ring-Add-barrier-to-provide-an-compiler-barri.patch >> xsa155-netbsd-xsa155-0004-netbsd-block-only-read-request-operation-from-shared.patch >> xsa155-netbsd-xsa155-0005-netbsd-pciback-Operate-on-local-version-of-xen_pci_o.patch >> >> xen: >> xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch >> xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch >> xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch >> >> xen 4.4: >> All patches except #3 will apply, please use: >> xsa155-xen44-0003-libvchan-Read-prod-cons-only-once.patch >> >> $ sha256sum xsa155* >> d9fbc104ab2ae797971e351ee0e04e7b7e9c7c33385309bb406c7941dc9a33b4 >> xsa155-linux319-xsa155-0006-xen-scsiback-safely-copy-requests.patch >> 590656d83ad7b6052b54659eccb3469658b3942c0dc1366423a66f2f5ac643e1 >> xsa155-linux43-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch >> 2bd18632178e09394c5cd06aded2c14bcc6b6e360ad6e81827d24860fe3e8ca4 >> xsa155-linux-xsa155-0001-xen-Add-RING_COPY_REQUEST.patch >> cecdeccb8e2551252c81fc5f164a8298005df714a574a7ba18b84e8ed5f2bb70 >> xsa155-linux-xsa155-0002-xen-netback-don-t-use-last-request-to-determine-mini.patch >> 3916b847243047f0e1053233ade742c14a7f29243584e60bf5db4842a8068855 >> xsa155-linux-xsa155-0003-xen-netback-use-RING_COPY_REQUEST-throughout.patch >> 746c8eb0aeb200d76156c88dfbbd49db79f567b88b07eda70f7c7d095721f05a >> xsa155-linux-xsa155-0004-xen-blkback-only-read-request-operation-from-shared-.patch >> 18517a184a02f7441065b8d3423086320ec4c2345c00d551231f7976381767f5 >> xsa155-linux-xsa155-0005-xen-blkback-read-from-indirect-descriptors-only-once.patch >> 2e6d556d25b1cc16e71afde665ae3908f4fa8eab7e0d96283fc78400301baf92 >> xsa155-linux-xsa155-0006-xen-scsiback-safely-copy-requests.patch >> 5e130d8b61906015c6a94f8edd3cce97b172f96a265d97ecf370e7b45125b73d >> xsa155-linux-xsa155-0007-xen-pciback-Save-xen_pci_op-commands-before-processi.patch >> 08c2d0f95dcc215165afbce623b6972b81dd45b091b5f40017579b00c8612e03 >> xsa155-netbsd-xsa155-0001-netbsd-xen-Add-RING_COPY_REQUEST.patch >> 0a66010f736092f91f70bb0fd220685e4395efef1db6d23a3d1eace31d144f51 >> xsa155-netbsd-xsa155-0002-netbsd-netback-Use-RING_COPY_REQUEST-instead-of-RING.patch >> 5e913a8427cab6b4d384d1246e05116afc301eb117edd838101eb53a82c2f2ff >> xsa155-netbsd-xsa155-0003-netbsd-ring-Add-barrier-to-provide-an-compiler-barri.patch >> 3b8f14eafaed3a7bc66245753a37af4249acf8129fbedb70653192252dc47dc9 >> xsa155-netbsd-xsa155-0004-netbsd-block-only-read-request-operation-from-shared.patch >> 81ae5fa998243a78dad749fc561be647dc1dc1be799e8f18484fdf0989469705 >> xsa155-netbsd-xsa155-0005-netbsd-pciback-Operate-on-local-version-of-xen_pci_o.patch >> 044ff74fa048df820d528f64f2791ec9cb3940bd313c1179020bd49a6cde2ca3 xsa155-qemu-qdisk-double-access.patch >> 1150504589eb7bfa108c80ce63395e57d0e627b12d9201219d968fdd026919a6 >> xsa155-qemut-qdisk-double-access.patch >> 63186246ab6913b54bfef5f09f33e815935ac40ff821c27a3efda62339bbbd5f xsa155-qemut-xenfb.patch >> e53b4ac298648cde79344192d5a58ca8d8724344f5105bec7c09eef095c668f6 xsa155-qemu-xenfb.patch >> e52467fcec73bcc86d3e96d06f8ca8085ae56a83d2c42a30c16bc3dc630d8f8a >> xsa155-xen-0001-xen-Add-RING_COPY_REQUEST.patch >> eae34c8ccc096ad93a74190506b3d55020a88afb0cc504a3a514590e9fd746fd >> xsa155-xen-0002-blktap2-Use-RING_COPY_REQUEST.patch >> 42780265014085a4221ad32b026214693d751789eb5219e2e83862c0006c66f4 >> xsa155-xen-0003-libvchan-Read-prod-cons-only-once.patch >> dfcaddb8a908a4fc1b048a43187e885117e67dc566f5c841037ee366dcd437d1 >> xsa155-xen44-0003-libvchan-Read-prod-cons-only-once.patch >> $ >> >> DEPLOYMENT DURING EMBARGO >> ========================= >> >> Deployment of the patches and/or mitigations described above (or >> others which are substantially similar) is permitted during the >> embargo, even on public-facing systems with untrusted guest users and >> administrators. >> >> But: Distribution of updated software is prohibited (except to other >> members of the predisclosure list). >> >> Predisclosure list members who wish to deploy significantly different >> patches and/or mitigations, please contact the Xen Project Security >> Team. >> >> (Note: this during-embargo deployment notice is retained in >> post-embargo publicly released Xen Project advisories, even though it >> is then no longer applicable. This is to enable the community to have >> oversight of the Xen Project Security Team's decisionmaking.) >> >> For more information about permissible uses of embargoed information, >> consult the Xen Project community's agreed Security Policy: >> http://www.xenproject.org/security-policy.html >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iQEcBAEBAgAGBQJWcrpdAAoJEIP+FMlX6CvZ9soIALqQ/GHP6bZn2LqJTD9DIzsm >> zVB4yCPiVfDqHSOq9QNCzBzqpvOX+RhKTzRH1jsZczr8CSnkePxaCrmZgH8SAygB >> hFcF9xJGlJDjs647sgpQmYs++3mgD/57uml7IW/8NX46tXUelVByW7muNgUN2xlm >> kjeD8auJEs+jK1iwpt/hOmYe4moRx3+3ujfgqMCNAWtqZz9D9wM5tao+p6yKYlhM >> u8hSi1V3b7sAbf92mwzpzfpbwdgg25xeHtZ/oJxp/ZY0FhqDEsTxV+h8HjD/Eink >> GwqPS19O77tMmz9fUUTyJDSsU7ayFRI0HyYmXju4eJktJkhXagjAdCSyGky9z5g= >> =FlX2 >> -----END PGP SIGNATURE----- >> >> ----- Topal: Original message ends ----- >> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory 2015-12-22 15:06 ` Eric Shelton @ 2016-01-04 13:06 ` Marek Marczykowski-Górecki 2016-01-04 15:00 ` Konrad Rzeszutek Wilk 2016-01-04 16:22 ` David Vrabel 0 siblings, 2 replies; 9+ messages in thread From: Marek Marczykowski-Górecki @ 2016-01-04 13:06 UTC (permalink / raw) To: Eric Shelton; +Cc: security, xen-devel@lists.xen.org, Stefano Stabellini [-- Attachment #1.1.1: Type: text/plain, Size: 1182 bytes --] On Tue, Dec 22, 2015 at 10:06:25AM -0500, Eric Shelton wrote: > The XSA mentions that "PV frontend patches will be developed and > released (publicly) after the embargo date." Has anything been done > towards this that should also be incorporated into MiniOS? On a > system utilizing a "driver domain," where a backend is running on a > domain that is considered unprivileged and untrusted (such as the > example described in http://wiki.xenproject.org/wiki/Driver_Domain), > it seems XSA-155-style double fetch vulnerabilities in the frontends > are also a potential security concern, and should be eliminated. > However, perhaps that does not include pcifront, since pciback would > always be running in dom0. And BTW the same applies to Linux frontends, for which also I haven't seen any public development. In attachment my email to xen-security-issues-discuss list (sent during embargo), with patches attached there. I haven't got any response. PS Dropping minios-devel -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? [-- Attachment #1.1.2: Type: message/rfc822, Size: 37548 bytes --] [-- Attachment #1.1.2.1.1.1.1: Type: text/plain, Size: 4038 bytes --] On Fri, Dec 11, 2015 at 11:52:17AM -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Dec 11, 2015 at 12:03:01PM +0100, Marek Marczykowski-Górecki wrote: > > Hi, > > > > In advisory it's said that PV frontend patches will be developed and > > released (publicly) after the embargo date. But in some cases (namely: > > if driver domains are in use), frontends may be more trusted/privileged > > than backends. So it would make sense to consider developing frontend > > patches before embargo end date. At least for the most common ones: > > network and block. > > > > Do you have some list of places that needs to be fixed? I can try to > > help with patches, but need some input on this... Patches (against 4.4) for netfront and blkfront attached. I don't have test case for actual XSA155, but at least it doesn't break normal usage. Below are some comments/questions. Sorry for the delay. > Any code where the shared page is being accessed. For example > blkif_interrupt. Added RING_COPY_RESPONSE here. Probably it would be enough to use just READ_ONCE(bret->operation), but blkif_response isn't that big, so safer option is better. The other places in block frontend are about preparing request - it should not reuse data already put into shared ring, because (malicious) backend might already changed it. Generally added local structure on the stack, filled there and only then put in on the ring. And save a copy to info->shadow[id].req (the original one, not the one from shared ring!). Maybe it would be better to use info->shadow[id].req in the first place (and then copy it to the shared ring)? Theoretically one memory copy less. Does it matter? > We probably should add another macro: RING_COPY_RESPONSE which > would replace the RING_GET_RESPONSE and copy the response to > an on stack variable and then operated on. > > Ditto with xennet_alloc_rx_buffers and the RING_GET_REQUEST. I'm not sure about this one - there is only write to that request, no reads. Or maybe I'm missing some obscure code there? > And > xennet_tx_buf_gc. Additionally added BUG_ON(id >= NET_TX_RING_SIZE). Not sure about the impact of backend giving out of range id, so make sure it's DoS in the _worst_ case. > There is also xennet_tx_setup_grant. It looks like the tx pointer outlive this function. So instead of changing it to local copy, made sure no data is read from that structure (only written). Similar in handling gso in xennet_start_xmit - it's only filled with data. Not sure about xennet_move_rx_slot, but I guess it's safe. > xen-pcifront looks to be safe - it memcopies the fields. However > as I've found out - doing 'memcpy' does not mean the compiler > will do that - it may convert that just to a pointer operation. > So an barrier() will have to be sprinkled in 'do_pci_op'. There is already wmb() after the first memcpy. Is it necessary to have another one before the memcpy in the other direction? $ shasum -a 256 *.patch f7b0c45dbd2c91bee5cc151b1c53b5b452e4e448991204ab6ac6aeb3b5811674 xsa155-linux-0008-xen-Add-RING_COPY_RESPONSE.patch a9f34c6b0b746bdd49594ddabab71ff18477b1cbad62d7cd380f3ca5dc9ff7e3 xsa155-linux-0009-xen-netfront-copy-response-out-of-shared-buffer-befo.patch e924fb7b344135e21c7df9ed6297165275646ea97b9d3072b9f1cc0152d88bec xsa155-linux-0010-xen-netfront-do-not-use-data-already-exposed-to-back.patch 03ac14dcbfb2ccd9e1c375e57e2c9184075d29ffadbaf696a8b015f7eb6bb2c0 xsa155-linux-0011-xen-netfront-add-range-check-for-Tx-response-id.patch e71bbd472b33af4424bee936019b11af2dfc1e3512d13d1aad9713fd8b337227 xsa155-linux-0012-xen-blkfront-make-local-copy-of-response-before-usin.patch 4c99b24ed5092e45c504c84312b619cb77c7ee1169b95002a9ea77fb96523d1d xsa155-linux-0013-xen-blkfront-prepare-request-locally-only-then-put-i.patch -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? [-- Attachment #1.1.2.1.1.1.2: xsa155-linux-0008-xen-Add-RING_COPY_RESPONSE.patch --] [-- Type: text/plain, Size: 2361 bytes --] From 8322f4eddaf1fe5a9bdf5252c8140daa8bad60fd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com> Date: Tue, 15 Dec 2015 21:35:14 +0100 Subject: [PATCH 08/13] xen: Add RING_COPY_RESPONSE() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Organization: Invisible Things Lab Cc: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly (i.e., by not considering that the other end may alter the data in the shared ring while it is being inspected). Safe usage of a response generally requires taking a local copy. Provide a RING_COPY_RESPONSE() macro to use instead of RING_GET_RESPONSE() and an open-coded memcpy(). This takes care of ensuring that the copy is done correctly regardless of any possible compiler optimizations. Use a volatile source to prevent the compiler from reordering or omitting the copy. This is part of XSA155. CC: stable@vger.kernel.org Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- include/xen/interface/io/ring.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h index 7dc685b..312415c 100644 --- a/include/xen/interface/io/ring.h +++ b/include/xen/interface/io/ring.h @@ -198,6 +198,20 @@ struct __name##_back_ring { \ #define RING_GET_RESPONSE(_r, _idx) \ (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].rsp)) +/* + * Get a local copy of a response. + * + * Use this in preference to RING_GET_RESPONSE() so all processing is + * done on a local copy that cannot be modified by the other end. + * + * Note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 may cause this + * to be ineffective where _rsp is a struct which consists of only bitfields. + */ +#define RING_COPY_RESPONSE(_r, _idx, _rsp) do { \ + /* Use volatile to force the copy into _rsp. */ \ + *(_rsp) = *(volatile typeof(_rsp))RING_GET_RESPONSE(_r, _idx); \ +} while (0) + /* Loop termination condition: Would the specified index overflow the ring? */ #define RING_REQUEST_CONS_OVERFLOW(_r, _cons) \ (((_cons) - (_r)->rsp_prod_pvt) >= RING_SIZE(_r)) -- 2.1.0 [-- Attachment #1.1.2.1.1.1.3: xsa155-linux-0009-xen-netfront-copy-response-out-of-shared-buffer-befo.patch --] [-- Type: text/plain, Size: 6318 bytes --] From 3a1006355114da4b8fc4b935a64928b7f6ae374f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com> Date: Wed, 16 Dec 2015 05:09:55 +0100 Subject: [PATCH 09/13] xen-netfront: copy response out of shared buffer before accessing it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Organization: Invisible Things Lab Cc: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Make local copy of the response, otherwise backend might modify it while frontend is already processing it - leading to time of check / time of use issue. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- drivers/net/xen-netfront.c | 51 +++++++++++++++++++++++----------------------- 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index d6abf19..2af5100 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -372,13 +372,13 @@ static void xennet_tx_buf_gc(struct netfront_queue *queue) rmb(); /* Ensure we see responses up to 'rp'. */ for (cons = queue->tx.rsp_cons; cons != prod; cons++) { - struct xen_netif_tx_response *txrsp; + struct xen_netif_tx_response txrsp; - txrsp = RING_GET_RESPONSE(&queue->tx, cons); - if (txrsp->status == XEN_NETIF_RSP_NULL) + RING_COPY_RESPONSE(&queue->tx, cons, &txrsp); + if (txrsp.status == XEN_NETIF_RSP_NULL) continue; - id = txrsp->id; + id = txrsp.id; skb = queue->tx_skbs[id].skb; if (unlikely(gnttab_query_foreign_access( queue->grant_tx_ref[id]) != 0)) { @@ -721,7 +721,7 @@ static int xennet_get_extras(struct netfront_queue *queue, RING_IDX rp) { - struct xen_netif_extra_info *extra; + struct xen_netif_extra_info extra; struct device *dev = &queue->info->netdev->dev; RING_IDX cons = queue->rx.rsp_cons; int err = 0; @@ -737,24 +737,23 @@ static int xennet_get_extras(struct netfront_queue *queue, break; } - extra = (struct xen_netif_extra_info *) - RING_GET_RESPONSE(&queue->rx, ++cons); + RING_COPY_RESPONSE(&queue->rx, ++cons, &extra); - if (unlikely(!extra->type || - extra->type >= XEN_NETIF_EXTRA_TYPE_MAX)) { + if (unlikely(!extra.type || + extra.type >= XEN_NETIF_EXTRA_TYPE_MAX)) { if (net_ratelimit()) dev_warn(dev, "Invalid extra type: %d\n", - extra->type); + extra.type); err = -EINVAL; } else { - memcpy(&extras[extra->type - 1], extra, - sizeof(*extra)); + memcpy(&extras[extra.type - 1], &extra, + sizeof(extra)); } skb = xennet_get_rx_skb(queue, cons); ref = xennet_get_rx_ref(queue, cons); xennet_move_rx_slot(queue, skb, ref); - } while (extra->flags & XEN_NETIF_EXTRA_FLAG_MORE); + } while (extra.flags & XEN_NETIF_EXTRA_FLAG_MORE); queue->rx.rsp_cons = cons; return err; @@ -764,28 +763,28 @@ static int xennet_get_responses(struct netfront_queue *queue, struct netfront_rx_info *rinfo, RING_IDX rp, struct sk_buff_head *list) { - struct xen_netif_rx_response *rx = &rinfo->rx; + struct xen_netif_rx_response rx = rinfo->rx; struct xen_netif_extra_info *extras = rinfo->extras; struct device *dev = &queue->info->netdev->dev; RING_IDX cons = queue->rx.rsp_cons; struct sk_buff *skb = xennet_get_rx_skb(queue, cons); grant_ref_t ref = xennet_get_rx_ref(queue, cons); - int max = MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD); + int max = MAX_SKB_FRAGS + (rx.status <= RX_COPY_THRESHOLD); int slots = 1; int err = 0; unsigned long ret; - if (rx->flags & XEN_NETRXF_extra_info) { + if (rx.flags & XEN_NETRXF_extra_info) { err = xennet_get_extras(queue, extras, rp); cons = queue->rx.rsp_cons; } for (;;) { - if (unlikely(rx->status < 0 || - rx->offset + rx->status > XEN_PAGE_SIZE)) { + if (unlikely(rx.status < 0 || + rx.offset + rx.status > XEN_PAGE_SIZE)) { if (net_ratelimit()) dev_warn(dev, "rx->offset: %u, size: %d\n", - rx->offset, rx->status); + rx.offset, rx.status); xennet_move_rx_slot(queue, skb, ref); err = -EINVAL; goto next; @@ -799,7 +798,7 @@ static int xennet_get_responses(struct netfront_queue *queue, if (ref == GRANT_INVALID_REF) { if (net_ratelimit()) dev_warn(dev, "Bad rx response id %d.\n", - rx->id); + rx.id); err = -EINVAL; goto next; } @@ -812,7 +811,7 @@ static int xennet_get_responses(struct netfront_queue *queue, __skb_queue_tail(list, skb); next: - if (!(rx->flags & XEN_NETRXF_more_data)) + if (!(rx.flags & XEN_NETRXF_more_data)) break; if (cons + slots == rp) { @@ -822,7 +821,7 @@ next: break; } - rx = RING_GET_RESPONSE(&queue->rx, cons + slots); + RING_COPY_RESPONSE(&queue->rx, cons + slots, &rx); skb = xennet_get_rx_skb(queue, cons + slots); ref = xennet_get_rx_ref(queue, cons + slots); slots++; @@ -878,9 +877,9 @@ static RING_IDX xennet_fill_frags(struct netfront_queue *queue, struct sk_buff *nskb; while ((nskb = __skb_dequeue(list))) { - struct xen_netif_rx_response *rx = - RING_GET_RESPONSE(&queue->rx, ++cons); + struct xen_netif_rx_response rx; skb_frag_t *nfrag = &skb_shinfo(nskb)->frags[0]; + RING_COPY_RESPONSE(&queue->rx, ++cons, &rx); if (shinfo->nr_frags == MAX_SKB_FRAGS) { unsigned int pull_to = NETFRONT_SKB_CB(skb)->pull_to; @@ -891,7 +890,7 @@ static RING_IDX xennet_fill_frags(struct netfront_queue *queue, BUG_ON(shinfo->nr_frags >= MAX_SKB_FRAGS); skb_add_rx_frag(skb, shinfo->nr_frags, skb_frag_page(nfrag), - rx->offset, rx->status, PAGE_SIZE); + rx.offset, rx.status, PAGE_SIZE); skb_shinfo(nskb)->nr_frags = 0; kfree_skb(nskb); @@ -987,7 +986,7 @@ static int xennet_poll(struct napi_struct *napi, int budget) i = queue->rx.rsp_cons; work_done = 0; while ((i != rp) && (work_done < budget)) { - memcpy(rx, RING_GET_RESPONSE(&queue->rx, i), sizeof(*rx)); + RING_COPY_RESPONSE(&queue->rx, i, rx); memset(extras, 0, sizeof(rinfo.extras)); err = xennet_get_responses(queue, &rinfo, rp, &tmpq); -- 2.1.0 [-- Attachment #1.1.2.1.1.1.4: xsa155-linux-0010-xen-netfront-do-not-use-data-already-exposed-to-back.patch --] [-- Type: text/plain, Size: 2937 bytes --] From 2adc557330dde5b474d885518d2663180d3c8f45 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com> Date: Wed, 16 Dec 2015 05:19:37 +0100 Subject: [PATCH 10/13] xen-netfront: do not use data already exposed to backend MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Organization: Invisible Things Lab Cc: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Backend may freely modify anything on shared page, so use data which was supposed to be written there, instead of reading it back from the shared page. This unfortunatelly require putting xennet_make_first_txreq inline into xennet_start_xmit (the only use), because we need info.size, which isn't available anywhere else (other than shared page). This is part of XSA155. CC: stable@vger.kernel.org Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- drivers/net/xen-netfront.c | 32 +++++++++++--------------------- 1 file changed, 11 insertions(+), 21 deletions(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 2af5100..959e479 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -453,23 +453,7 @@ static void xennet_tx_setup_grant(unsigned long gfn, unsigned int offset, tx->flags = 0; info->tx = tx; - info->size += tx->size; -} - -static struct xen_netif_tx_request *xennet_make_first_txreq( - struct netfront_queue *queue, struct sk_buff *skb, - struct page *page, unsigned int offset, unsigned int len) -{ - struct xennet_gnttab_make_txreq info = { - .queue = queue, - .skb = skb, - .page = page, - .size = 0, - }; - - gnttab_for_one_grant(page, offset, len, xennet_tx_setup_grant, &info); - - return info.tx; + info->size += len; } static void xennet_make_one_txreq(unsigned long gfn, unsigned int offset, @@ -564,6 +548,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev) struct netfront_info *np = netdev_priv(dev); struct netfront_stats *tx_stats = this_cpu_ptr(np->tx_stats); struct xen_netif_tx_request *tx, *first_tx; + struct xennet_gnttab_make_txreq info; unsigned int i; int notify; int slots; @@ -614,14 +599,19 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev) } /* First request for the linear area. */ - first_tx = tx = xennet_make_first_txreq(queue, skb, - page, offset, len); - offset += tx->size; + info.queue = queue; + info.skb = skb; + info.page = page; + info.size = 0; + gnttab_for_one_grant(page, offset, len, xennet_tx_setup_grant, &info); + + first_tx = tx = info.tx; + offset += info.size; if (offset == PAGE_SIZE) { page++; offset = 0; } - len -= tx->size; + len -= info.size; if (skb->ip_summed == CHECKSUM_PARTIAL) /* local packet? */ -- 2.1.0 [-- Attachment #1.1.2.1.1.1.5: xsa155-linux-0011-xen-netfront-add-range-check-for-Tx-response-id.patch --] [-- Type: text/plain, Size: 1248 bytes --] From 76a020d3b2023ca02961eab38318ef2d6f1338d9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com> Date: Wed, 16 Dec 2015 05:22:24 +0100 Subject: [PATCH 11/13] xen-netfront: add range check for Tx response id MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Organization: Invisible Things Lab Cc: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Tx response ID is fetched from shared page, so make sure it is sane before using it as an array index. This is part of XSA155. CC: stable@vger.kernel.org Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- drivers/net/xen-netfront.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 959e479..94309e6 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -379,6 +379,7 @@ static void xennet_tx_buf_gc(struct netfront_queue *queue) continue; id = txrsp.id; + BUG_ON(id >= NET_TX_RING_SIZE); skb = queue->tx_skbs[id].skb; if (unlikely(gnttab_query_foreign_access( queue->grant_tx_ref[id]) != 0)) { -- 2.1.0 [-- Attachment #1.1.2.1.1.1.6: xsa155-linux-0012-xen-blkfront-make-local-copy-of-response-before-usin.patch --] [-- Type: text/plain, Size: 4780 bytes --] From ef0d243bfeaf1da8854c26f89536dc1b69c56602 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com> Date: Wed, 16 Dec 2015 05:51:10 +0100 Subject: [PATCH 12/13] xen-blkfront: make local copy of response before using it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Organization: Invisible Things Lab Cc: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Data on the shared page can be changed at any time by the backend. Make a local copy, which is no longer controlled by the backend. And only then access it. This is part of XSA155. CC: stable@vger.kernel.org Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- drivers/block/xen-blkfront.c | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 2fee2ee..5d7eb04 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1296,7 +1296,7 @@ static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info, static irqreturn_t blkif_interrupt(int irq, void *dev_id) { struct request *req; - struct blkif_response *bret; + struct blkif_response bret; RING_IDX i, rp; unsigned long flags; struct blkfront_info *info = (struct blkfront_info *)dev_id; @@ -1316,8 +1316,8 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id) for (i = info->ring.rsp_cons; i != rp; i++) { unsigned long id; - bret = RING_GET_RESPONSE(&info->ring, i); - id = bret->id; + RING_COPY_RESPONSE(&info->ring, i, &bret); + id = bret.id; /* * The backend has messed up and given us an id that we would * never have given to it (we stamp it up to BLK_RING_SIZE - @@ -1325,29 +1325,29 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id) */ if (id >= BLK_RING_SIZE(info)) { WARN(1, "%s: response to %s has incorrect id (%ld)\n", - info->gd->disk_name, op_name(bret->operation), id); + info->gd->disk_name, op_name(bret.operation), id); /* We can't safely get the 'struct request' as * the id is busted. */ continue; } req = info->shadow[id].request; - if (bret->operation != BLKIF_OP_DISCARD) - blkif_completion(&info->shadow[id], info, bret); + if (bret.operation != BLKIF_OP_DISCARD) + blkif_completion(&info->shadow[id], info, &bret); if (add_id_to_freelist(info, id)) { WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n", - info->gd->disk_name, op_name(bret->operation), id); + info->gd->disk_name, op_name(bret.operation), id); continue; } - error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO; - switch (bret->operation) { + error = (bret.status == BLKIF_RSP_OKAY) ? 0 : -EIO; + switch (bret.operation) { case BLKIF_OP_DISCARD: - if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) { + if (unlikely(bret.status == BLKIF_RSP_EOPNOTSUPP)) { struct request_queue *rq = info->rq; printk(KERN_WARNING "blkfront: %s: %s op failed\n", - info->gd->disk_name, op_name(bret->operation)); + info->gd->disk_name, op_name(bret.operation)); error = -EOPNOTSUPP; info->feature_discard = 0; info->feature_secdiscard = 0; @@ -1358,15 +1358,15 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id) break; case BLKIF_OP_FLUSH_DISKCACHE: case BLKIF_OP_WRITE_BARRIER: - if (unlikely(bret->status == BLKIF_RSP_EOPNOTSUPP)) { + if (unlikely(bret.status == BLKIF_RSP_EOPNOTSUPP)) { printk(KERN_WARNING "blkfront: %s: %s op failed\n", - info->gd->disk_name, op_name(bret->operation)); + info->gd->disk_name, op_name(bret.operation)); error = -EOPNOTSUPP; } - if (unlikely(bret->status == BLKIF_RSP_ERROR && + if (unlikely(bret.status == BLKIF_RSP_ERROR && info->shadow[id].req.u.rw.nr_segments == 0)) { printk(KERN_WARNING "blkfront: %s: empty %s op failed\n", - info->gd->disk_name, op_name(bret->operation)); + info->gd->disk_name, op_name(bret.operation)); error = -EOPNOTSUPP; } if (unlikely(error)) { @@ -1378,9 +1378,9 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id) /* fall through */ case BLKIF_OP_READ: case BLKIF_OP_WRITE: - if (unlikely(bret->status != BLKIF_RSP_OKAY)) + if (unlikely(bret.status != BLKIF_RSP_OKAY)) dev_dbg(&info->xbdev->dev, "Bad return from blkdev data " - "request: %x\n", bret->status); + "request: %x\n", bret.status); blk_mq_complete_request(req, error); break; -- 2.1.0 [-- Attachment #1.1.2.1.1.1.7: xsa155-linux-0013-xen-blkfront-prepare-request-locally-only-then-put-i.patch --] [-- Type: text/plain, Size: 6093 bytes --] From 74aaa42e1f25309a163acd00083ecbbc186fbb47 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com> Date: Wed, 16 Dec 2015 06:07:14 +0100 Subject: [PATCH 13/13] xen-blkfront: prepare request locally, only then put it on the shared ring MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Organization: Invisible Things Lab Cc: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Do not reuse data which theoretically might be already modified by the backend. This is mostly about private copy of the request (info->shadow[id].req) - make sure the request saved there is really the one just filled. This is part of XSA155. CC: stable@vger.kernel.org Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- drivers/block/xen-blkfront.c | 56 ++++++++++++++++++++++++-------------------- 1 file changed, 30 insertions(+), 26 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 5d7eb04..514cf18 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -459,27 +459,29 @@ static int blkif_ioctl(struct block_device *bdev, fmode_t mode, static int blkif_queue_discard_req(struct request *req) { struct blkfront_info *info = req->rq_disk->private_data; - struct blkif_request *ring_req; + struct blkif_request ring_req; unsigned long id; /* Fill out a communications ring structure. */ - ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt); id = get_id_from_freelist(info); info->shadow[id].request = req; - ring_req->operation = BLKIF_OP_DISCARD; - ring_req->u.discard.nr_sectors = blk_rq_sectors(req); - ring_req->u.discard.id = id; - ring_req->u.discard.sector_number = (blkif_sector_t)blk_rq_pos(req); + ring_req.operation = BLKIF_OP_DISCARD; + ring_req.u.discard.nr_sectors = blk_rq_sectors(req); + ring_req.u.discard.id = id; + ring_req.u.discard.sector_number = (blkif_sector_t)blk_rq_pos(req); if ((req->cmd_flags & REQ_SECURE) && info->feature_secdiscard) - ring_req->u.discard.flag = BLKIF_DISCARD_SECURE; + ring_req.u.discard.flag = BLKIF_DISCARD_SECURE; else - ring_req->u.discard.flag = 0; + ring_req.u.discard.flag = 0; + /* make the request available to the backend */ + *RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt) = ring_req; + wmb(); info->ring.req_prod_pvt++; /* Keep a private copy so we can reissue requests when recovering. */ - info->shadow[id].req = *ring_req; + info->shadow[id].req = ring_req; return 0; } @@ -569,7 +571,7 @@ static void blkif_setup_rw_req_grant(unsigned long gfn, unsigned int offset, static int blkif_queue_rw_req(struct request *req) { struct blkfront_info *info = req->rq_disk->private_data; - struct blkif_request *ring_req; + struct blkif_request ring_req; unsigned long id; int i; struct setup_rw_req setup = { @@ -613,7 +615,6 @@ static int blkif_queue_rw_req(struct request *req) new_persistent_gnts = 0; /* Fill out a communications ring structure. */ - ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt); id = get_id_from_freelist(info); info->shadow[id].request = req; @@ -628,7 +629,7 @@ static int blkif_queue_rw_req(struct request *req) for_each_sg(info->shadow[id].sg, sg, num_sg, i) num_grant += gnttab_count_grant(sg->offset, sg->length); - ring_req->u.rw.id = id; + ring_req.u.rw.id = id; info->shadow[id].num_sg = num_sg; if (num_grant > BLKIF_MAX_SEGMENTS_PER_REQUEST) { /* @@ -636,16 +637,16 @@ static int blkif_queue_rw_req(struct request *req) * BLKIF_OP_WRITE */ BUG_ON(req->cmd_flags & (REQ_FLUSH | REQ_FUA)); - ring_req->operation = BLKIF_OP_INDIRECT; - ring_req->u.indirect.indirect_op = rq_data_dir(req) ? + ring_req.operation = BLKIF_OP_INDIRECT; + ring_req.u.indirect.indirect_op = rq_data_dir(req) ? BLKIF_OP_WRITE : BLKIF_OP_READ; - ring_req->u.indirect.sector_number = (blkif_sector_t)blk_rq_pos(req); - ring_req->u.indirect.handle = info->handle; - ring_req->u.indirect.nr_segments = num_grant; + ring_req.u.indirect.sector_number = (blkif_sector_t)blk_rq_pos(req); + ring_req.u.indirect.handle = info->handle; + ring_req.u.indirect.nr_segments = num_grant; } else { - ring_req->u.rw.sector_number = (blkif_sector_t)blk_rq_pos(req); - ring_req->u.rw.handle = info->handle; - ring_req->operation = rq_data_dir(req) ? + ring_req.u.rw.sector_number = (blkif_sector_t)blk_rq_pos(req); + ring_req.u.rw.handle = info->handle; + ring_req.operation = rq_data_dir(req) ? BLKIF_OP_WRITE : BLKIF_OP_READ; if (req->cmd_flags & (REQ_FLUSH | REQ_FUA)) { /* @@ -658,21 +659,21 @@ static int blkif_queue_rw_req(struct request *req) switch (info->feature_flush & ((REQ_FLUSH|REQ_FUA))) { case REQ_FLUSH|REQ_FUA: - ring_req->operation = + ring_req.operation = BLKIF_OP_WRITE_BARRIER; break; case REQ_FLUSH: - ring_req->operation = + ring_req.operation = BLKIF_OP_FLUSH_DISKCACHE; break; default: - ring_req->operation = 0; + ring_req.operation = 0; } } - ring_req->u.rw.nr_segments = num_grant; + ring_req.u.rw.nr_segments = num_grant; } - setup.ring_req = ring_req; + setup.ring_req = &ring_req; setup.id = id; for_each_sg(info->shadow[id].sg, sg, num_sg, i) { BUG_ON(sg->offset + sg->length > PAGE_SIZE); @@ -694,10 +695,13 @@ static int blkif_queue_rw_req(struct request *req) if (setup.segments) kunmap_atomic(setup.segments); + /* make the request available to the backend */ + *RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt) = ring_req; + wmb(); info->ring.req_prod_pvt++; /* Keep a private copy so we can reissue requests when recovering. */ - info->shadow[id].req = *ring_req; + info->shadow[id].req = ring_req; if (new_persistent_gnts) gnttab_free_grant_references(setup.gref_head); -- 2.1.0 [-- Attachment #1.1.2.1.1.2: Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #1.1.2.1.2: Type: text/plain, Size: 219 bytes --] _______________________________________________ Xen-security-issues-discuss mailing list Xen-security-issues-discuss@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/xen-security-issues-discuss [-- Attachment #1.2: Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory 2016-01-04 13:06 ` Marek Marczykowski-Górecki @ 2016-01-04 15:00 ` Konrad Rzeszutek Wilk 2016-01-04 16:22 ` David Vrabel 1 sibling, 0 replies; 9+ messages in thread From: Konrad Rzeszutek Wilk @ 2016-01-04 15:00 UTC (permalink / raw) To: Marek Marczykowski-Górecki Cc: security, xen-devel@lists.xen.org, Stefano Stabellini, Eric Shelton On Mon, Jan 04, 2016 at 02:06:32PM +0100, Marek Marczykowski-Górecki wrote: > On Tue, Dec 22, 2015 at 10:06:25AM -0500, Eric Shelton wrote: > > The XSA mentions that "PV frontend patches will be developed and > > released (publicly) after the embargo date." Has anything been done > > towards this that should also be incorporated into MiniOS? On a > > system utilizing a "driver domain," where a backend is running on a > > domain that is considered unprivileged and untrusted (such as the > > example described in http://wiki.xenproject.org/wiki/Driver_Domain), > > it seems XSA-155-style double fetch vulnerabilities in the frontends > > are also a potential security concern, and should be eliminated. > > However, perhaps that does not include pcifront, since pciback would > > always be running in dom0. > > And BTW the same applies to Linux frontends, for which also I haven't seen > any public development. In attachment my email to > xen-security-issues-discuss list (sent during embargo), with patches > attached there. I haven't got any response. Could you post it using git-send-email please? I took a quick glance at them but didn't get a chance to do an indepth look. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory 2016-01-04 13:06 ` Marek Marczykowski-Górecki 2016-01-04 15:00 ` Konrad Rzeszutek Wilk @ 2016-01-04 16:22 ` David Vrabel 2016-01-04 16:56 ` Marek Marczykowski-Górecki 1 sibling, 1 reply; 9+ messages in thread From: David Vrabel @ 2016-01-04 16:22 UTC (permalink / raw) To: Marek Marczykowski-Górecki, Eric Shelton Cc: xen-devel@lists.xen.org, Stefano Stabellini, security On 04/01/16 13:06, Marek Marczykowski-Górecki wrote: > On Tue, Dec 22, 2015 at 10:06:25AM -0500, Eric Shelton wrote: >> The XSA mentions that "PV frontend patches will be developed and >> released (publicly) after the embargo date." Has anything been done >> towards this that should also be incorporated into MiniOS? On a >> system utilizing a "driver domain," where a backend is running on a >> domain that is considered unprivileged and untrusted (such as the >> example described in http://wiki.xenproject.org/wiki/Driver_Domain), >> it seems XSA-155-style double fetch vulnerabilities in the frontends >> are also a potential security concern, and should be eliminated. >> However, perhaps that does not include pcifront, since pciback would >> always be running in dom0. > > And BTW the same applies to Linux frontends, for which also I haven't seen > any public development. In attachment my email to > xen-security-issues-discuss list (sent during embargo), with patches > attached there. I haven't got any response. There are no similar security concerns with frontends since they trust the backend. I note that you say: "But in some cases (namely: if driver domains are in use), frontends may be more trusted/privileged than backends." But this cannot be the case since the backend can always trivially DoS the frontend by (for example) not unmapping grant references when required by the protocol. David ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory 2016-01-04 16:22 ` David Vrabel @ 2016-01-04 16:56 ` Marek Marczykowski-Górecki 2016-01-04 17:37 ` David Vrabel 0 siblings, 1 reply; 9+ messages in thread From: Marek Marczykowski-Górecki @ 2016-01-04 16:56 UTC (permalink / raw) To: David Vrabel Cc: security, xen-devel@lists.xen.org, Stefano Stabellini, Eric Shelton [-- Attachment #1.1: Type: text/plain, Size: 1805 bytes --] On Mon, Jan 04, 2016 at 04:22:32PM +0000, David Vrabel wrote: > On 04/01/16 13:06, Marek Marczykowski-Górecki wrote: > > On Tue, Dec 22, 2015 at 10:06:25AM -0500, Eric Shelton wrote: > >> The XSA mentions that "PV frontend patches will be developed and > >> released (publicly) after the embargo date." Has anything been done > >> towards this that should also be incorporated into MiniOS? On a > >> system utilizing a "driver domain," where a backend is running on a > >> domain that is considered unprivileged and untrusted (such as the > >> example described in http://wiki.xenproject.org/wiki/Driver_Domain), > >> it seems XSA-155-style double fetch vulnerabilities in the frontends > >> are also a potential security concern, and should be eliminated. > >> However, perhaps that does not include pcifront, since pciback would > >> always be running in dom0. > > > > And BTW the same applies to Linux frontends, for which also I haven't seen > > any public development. In attachment my email to > > xen-security-issues-discuss list (sent during embargo), with patches > > attached there. I haven't got any response. > > There are no similar security concerns with frontends since they trust > the backend. > > I note that you say: > > "But in some cases (namely: if driver domains are in use), frontends > may be more trusted/privileged than backends." > > But this cannot be the case since the backend can always trivially DoS > the frontend by (for example) not unmapping grant references when > required by the protocol. DoS is one thing, code execution is another. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? [-- Attachment #1.2: Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory 2016-01-04 16:56 ` Marek Marczykowski-Górecki @ 2016-01-04 17:37 ` David Vrabel 0 siblings, 0 replies; 9+ messages in thread From: David Vrabel @ 2016-01-04 17:37 UTC (permalink / raw) To: Marek Marczykowski-Górecki Cc: security, xen-devel@lists.xen.org, Stefano Stabellini, Eric Shelton On 04/01/16 16:56, Marek Marczykowski-Górecki wrote: > On Mon, Jan 04, 2016 at 04:22:32PM +0000, David Vrabel wrote: >> On 04/01/16 13:06, Marek Marczykowski-Górecki wrote: >>> On Tue, Dec 22, 2015 at 10:06:25AM -0500, Eric Shelton wrote: >>>> The XSA mentions that "PV frontend patches will be developed and >>>> released (publicly) after the embargo date." Has anything been done >>>> towards this that should also be incorporated into MiniOS? On a >>>> system utilizing a "driver domain," where a backend is running on a >>>> domain that is considered unprivileged and untrusted (such as the >>>> example described in http://wiki.xenproject.org/wiki/Driver_Domain), >>>> it seems XSA-155-style double fetch vulnerabilities in the frontends >>>> are also a potential security concern, and should be eliminated. >>>> However, perhaps that does not include pcifront, since pciback would >>>> always be running in dom0. >>> >>> And BTW the same applies to Linux frontends, for which also I haven't seen >>> any public development. In attachment my email to >>> xen-security-issues-discuss list (sent during embargo), with patches >>> attached there. I haven't got any response. >> >> There are no similar security concerns with frontends since they trust >> the backend. >> >> I note that you say: >> >> "But in some cases (namely: if driver domains are in use), frontends >> may be more trusted/privileged than backends." >> >> But this cannot be the case since the backend can always trivially DoS >> the frontend by (for example) not unmapping grant references when >> required by the protocol. > > DoS is one thing, code execution is another. The DoS is a trivial and obvious example to illustrate that your suggestion that: "...frontends may be more trusted/privileged than backends." is ill-advised. Anyway, none of this means we won't consider your netfront patches. But you do need to post them to the correct lists (netdev and xen-devel). David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-01-04 17:37 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-12-21 23:10 Xen Security Advisory 155 (CVE-2015-8550) - paravirtualized drivers incautious about shared memory Eric Shelton 2015-12-22 12:24 ` Stefano Stabellini 2015-12-22 13:19 ` Samuel Thibault 2015-12-22 15:06 ` Eric Shelton 2016-01-04 13:06 ` Marek Marczykowski-Górecki 2016-01-04 15:00 ` Konrad Rzeszutek Wilk 2016-01-04 16:22 ` David Vrabel 2016-01-04 16:56 ` Marek Marczykowski-Górecki 2016-01-04 17:37 ` David Vrabel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).