Displaying 20 results from an estimated 1000 matches similar to: "[PATCH v2] AMD/intremap: Prevent use of per-device vector maps until irq logic is fixed"
2013 Mar 19
7
[PATCH 0/3] IOMMU errata treatment adjustments
1: IOMMU: properly check whether interrupt remapping is enabled
2: AMD IOMMU: only disable when certain IVRS consistency checks fail
3: VT-d: deal with 5500/5520/X58 errata
Patch 1 and 2 are version 2 of a previously submitted, then
withdrawn patch following up after XSA-36. Patch 3 is version 3 of
a patch previously sent by Malcolm and Andrew.
Signed-off-by: Jan Beulich
2013 Jan 25
3
[PATCH] xenguest: Add xsa-25 decompression limit prototypes
To allow xenguest consumers to also make use of the extra protection added as
a result of xsa-25.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
diff -r 5af4f2ab06f3 -r daec50a41570 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -177,6 +177,13 @@ int xc_dom_linux_build(xc_interface *xch
unsigned int console_evtchn,
unsigned
2017 May 04
3
Bug#861660: Xen package security updates for jessie 4.4, XSA-213, XSA-214
Moritz Muehlenhoff writes ("Re: Xen package security updates for jessie 4.4, XSA-213, XSA-214"):
> On Thu, May 04, 2017 at 05:06:07PM +0100, Ian Jackson wrote:
> > I have fixed these in stretch but the jessie package remains unfixed.
> > I think I may be able to find some backports somewhere. Would that be
> > useful ? Is anyone else working on this ?
>
>
2013 Jan 15
14
[PATCH] VTD/Intremap: Disable Intremap on Chipset 5500/5520/X58 due to errata
http://www.intel.com/content/www/us/en/chipsets/5520-and-5500-chipset-ioh-specification-update.html
Stepping B-3 has two errata (#47 and #53) related to Interrupt
remapping, to which the workaround is for the BIOS to completely disable
interrupt remapping. These errata are fixed in stepping C-2.
Unfortunately this chipset is very common and many BIOSes are not
disabling remapping. We can
2011 Sep 07
10
[PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs
Also, rename to MOVE_CLEANUP_VECTOR to be in line with the other IPI
names.
This requires bumping LAST_HIPRIORITY_VECTOR, but does mean that the
range FIRST-LAST_HIPRIORITY_VECTORs are free once again.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
diff -r 0268e7380953 -r c7884dbb6f7d xen/arch/x86/apic.c
--- a/xen/arch/x86/apic.c Mon Sep 05 15:10:28 2011 +0100
+++
2013 Oct 10
10
[PATCH 0/4] x86: XSA-67 follow-up
1: correct LDT checks
2: add address validity check to guest_map_l1e()
3: use {rd,wr}{fs,gs}base when available
4: check for canonical address before doing page walks
Signed-off-by: Jan Beulich <jbeulich@suse.com>
2013 Oct 30
3
[PATCH 4/4] XSA-60 security hole: flush cache when vmentry back to UC guest
From 159251a04afcdcd8ca08e9f2bdfae279b2aa5471 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Thu, 31 Oct 2013 06:38:15 +0800
Subject: [PATCH 4/4] XSA-60 security hole: flush cache when vmentry back to UC guest
This patch flush cache when vmentry back to UC guest, to prevent
cache polluted by hypervisor access guest memory during UC mode.
The elegant way to do this
2017 May 04
4
Xen package security updates for jessie 4.4, XSA-213, XSA-214
Moritz Muehlenhoff writes ("Re: Xen package security updates for jessie 4.4, XSA-213, XSA-214"):
> Yes, the distribution line should be jessie-security, but please send
> a debdiff to team at security.debian.org for a quick review before
> uploading (I have no idea whether dgit supports security-master).
Here is the proposed debdiff (actually, a git diff) for xen in jessie.
My
2013 Nov 25
14
[PATCH] VMX: wbinvd when vmentry under UC
From e2d47e2f75bac6876b7c2eaecfe946966bf27516 Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Tue, 26 Nov 2013 04:53:17 +0800
Subject: [PATCH] VMX: wbinvd when vmentry under UC
This patch flush cache when vmentry back to UC guest, to prevent
cache polluted by hypervisor access guest memory during UC mode.
However, wbinvd is a _very_ time consuming operation, so
1.
2011 Sep 06
9
AMD IOMMU intremap tables and IOAPICs
Wei,
Quick question: Am I reading the code correctly, that even with
per-device interrupt remap tables, that GSIs are accounted to the
intremap table of the corresponding IOAPIC, presumably because the
IOMMU sees interrupts generated as GSIs as coming from the IOAPIC? In
that case, then we need all devices sharing the same IOAPIC must not
have any vector collisions. Is that correct?
-George
2011 Sep 20
0
[PATCH 4/4] x86: split MSI IRQ chip
With the .end() accessor having become optional and noting that
several of the accessors'' behavior really depends on the result of
msi_maskable_irq(), the splits the MSI IRQ chip type into two - one
for the maskable ones, and the other for the (MSI only) non-maskable
ones.
At once the implementation of those methods gets moved from io_apic.c
to msi.c.
Signed-off-by: Jan Beulich
2013 May 21
12
[PATCH] fix XSA-46 regression with xend/xm
The hypervisor side changes for XSA-46 require the tool stack to now
always map the guest pIRQ before granting access permission to the
underlying host IRQ (GSI). This in particular requires that pciif.py
no longer can skip this step (assuming qemu would do it) for HVM
guests.
This in turn exposes, however, an inconsistency between xend and qemu:
The former wants to always establish 1:1 mappings
2013 Sep 27
19
preparing for 4.3.1
Aiming at a release later in October (before Xen Summit I would
hope), I''d like to cut RC1 next week.
Please indicate any bug fixes that so far may have been missed
in the backports already done.
Jan
2013 Feb 14
2
[PATCH] x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS.
Jan, any reason why this patch isn't in Linus's tree already, and why it
wasn't marked for inclusion in a -stable kernel release?
thanks,
greg k-h
On Thu, Jan 24, 2013 at 01:11:10PM +0000, Jan Beulich wrote:
> This fixes CVE-2013-0228 / XSA-42
>
> Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
> in 32bit PV guest can use to crash the
2013 Feb 14
2
[PATCH] x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS.
Jan, any reason why this patch isn't in Linus's tree already, and why it
wasn't marked for inclusion in a -stable kernel release?
thanks,
greg k-h
On Thu, Jan 24, 2013 at 01:11:10PM +0000, Jan Beulich wrote:
> This fixes CVE-2013-0228 / XSA-42
>
> Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
> in 32bit PV guest can use to crash the
2018 Aug 15
6
Xen Security Update - XSA-{268,269,272,273}
Dear Security Team,
I have prepared a new upload addressing a number of open security
issues in Xen.
Due to the complexity of the patches that address XSA-273 [0] the
packages have been built from upstream's staging-4.8 / staging-4.10
branch again as recommended in that advisory. Commits on those branches
are restricted to those that address the following XSAs (cf. [1]):
- XSA-273
2019 Jun 25
2
Are XSA-289, XSA-274/CVE-2018-14678 fixed ?
Hello,
Are XSA-289 and XSA-274/CVE-2018-14678 fixed with Xen recent 4.8, 4.10 and kernel 4.9.177 packages ?
Thank you
2017 May 04
2
Xen package security updates for jessie 4.4, XSA-213, XSA-214
Ian Jackson writes ("64bit PV guest breakout [XSA-213]"):
> Source: xen
> Version: 4.4.1-9
> Severity: important
> Tags: security upstream fixed-upstream
>
> See
> https://xenbits.xen.org/xsa/advisory-213.html
Ian Jackson writes ("grant transfer allows PV guest to elevate privileges [XSA-214]"):
> Source: xen
> Version: 4.4.1-9
> Severity:
2017 Sep 13
2
Updated Xen packages for XSA 216..225
Moritz M?hlenhoff writes ("Re: Updated Xen packages for XSA 216..225"):
> Since the queue was already quite big and this update was ready
> I went ahead and released what we had for now.
Yes, sorry, I should have been explicit that that's what I expected
you to do...
Ian.
2017 Nov 28
2
4.4.4-26 with XSA-226, 227, 230 in centos-virt-testing
Kevin has been rolling back the security updates to the 4.4 branch. He
has been working with some of the other distros (debian for sure, and
some others on the xen security list).
I think it is his intention to continue this for as long as he is able
to. (Kevin, chime in if you have a schedule lifetime or EOL in mind)
As long as Kevin (or anyone else) maintains the tree, I am happy to
build