similar to: Bug#730254: xen: CVE-2013-6375: Insufficient TLB flushing in VT-d (iommu) code

Hello, Are you going to fix https://bugs.debian.org/730254 or what is the status? I would like to close old issues in case these are not going to get fixed. --- Henri Salo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL:

Package: xen-utils-common Version: 4.1.4-2 Severity: minor The syntax that the scripts use prevents one from creating a vif named "dev", for example. Attached is a patch for one script, but the syntax that skips using the "dev" keyword is present in other scripts, like vif-bridge. -------------- next part -------------- A non-text attachment was scrubbed... Name:

Package: xen-utils-common Version: 4.1.4-3+deb7u1 Severity: minor In the file /etc/xen/xl.conf there's a suggestion that vif scripts should be named relative to the /etc/xen/scripts directory, which is not the case, since absolute paths have to be used. The manual page xl.conf(5) is also missing. Relevant snippet: # default vif script #vifscript="vif-bridge"

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal pygrub looks for extlinux config files "/boot/isolinux/isolinux.cfg" and "/boot/extlinux.conf", but the default Debian installation uses the config file "/boot/extlinux/extlinux.conf". (See /usr/lib/xen-4.1/bin/pygrub lines 405-407.) ...Marvin -- System Information: Debian Release: 7.0 APT prefers testing

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal The function is_disk_image in /usr/lib/xen-4.1/bin/pygrub at line 45 distinguishes a partitioned disk from a partition by looking for 0xaa55 at offset 0x1fe in the image, but this is the bootsector signature, not the partition table signature. extlinux and other bootloaders put this signature there on bootable partitions (which don't

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal The grub.cfg created by a default Debian installation uses many configuration statements that pygrub does not recognize, and pygrub is unable to find any kernel to load. ...Marvin -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500,

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal pygrub does not recognize the include statement in extlinux.conf. The default Debian installation of extlinux creates a stub extlinux.conf which includes linux.cfg, where all the linux image entries are. This means that even if bugs 697407 and 697409 are fixed, pygrub still can't find the right kernel on a default Debian installation

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Switching to the xl toolstack I expected my configuration to work unmodified, but it doesn't, and I couldn't find any documentation regarding this, since xl.cfg(5) is missing. Original version, used with xm: vfb = ['type=vnc,vnclisten=0.0.0.0:6369,vncdisplay=6369,vncpasswd=x'] Working xl version: vnclisten="0.0.0.0:6369"

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Severity: important Tags: security patch When you use xl toolstack, you can't reboot domUs. When you switch back to xm toolstack, than reboot works again. I think the problem with the debian packaged version is the same as in this thread: http://lists.xen.org/archives/html/xen-devel/2011-09/msg01289.html I also think it's a security issue,

Hi, I wanted to know if its safe to FLUSH TLB with IRQ Enable. Basically If i call local_flush_tlb_all() with IRQ''s Enabled what is the consequence? How is it normally done in Linux/Xen. Warm Regards, Akshay

Signed-off-by: Kieran Mansley <kmansley@solarflare.com> Allow iomem permissions to be set up through grant table ops diff -r 749b60ccc177 xen/arch/x86/mm.c --- a/xen/arch/x86/mm.c Wed Jul 25 14:03:08 2007 +0100 +++ b/xen/arch/x86/mm.c Wed Jul 25 14:03:12 2007 +0100 @@ -594,6 +594,14 @@ get_##level##_linear_pagetable( return 1; \ } + +int iomem_page_test(unsigned long mfn,

Package: xen-utils-4.3 Version: 4.3.0-3 Severity: important Tags: upstream patch When using Xen compiled with seabios-1.7.4-1 (now in unstable/testing), HVMs fail immediately upon starting with a VCPU triple fault: (XEN) HVM1: Loading SeaBIOS ... (XEN) hvm.c:1253:d1 Triple fault on VCPU0 - invoking HVM shutdown action 1. This is because SeaBIOS can now be greater than 128k, which breaks an

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2013-3495 / XSA-59 version 4 Intel VT-d Interrupt Remapping engines can be evaded by native NMI interrupts UPDATES IN VERSION 4 ==================== Public release. Extensive changes to Description, Vulnerable Systems and Mitigation. Additional technical information has been

Package: xen Version: 4.0.1-5.11 Severity: important Tags: security, fixed-upstream Please see for details: http://www.openwall.com/lists/oss-security/2014/06/17/6 Patch: http://seclists.org/oss-sec/2014/q2/att-549/xsa100.patch --- Henri Salo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc:

blktap_poll is calling tlb_flush_all() in its main ring buffer polling loop. This seems to be superfluous: the hypervisor should be performing any necessary tlb flushes on grant table operations performed by the back-end. Even a simple memory barrier is unnecessary here as the RING_PUSH_REQUESTS() call performs a wmb() anyway. And tlb_flush_all() is not exported to modules, so this call

Hi everyone, I was wondering what to do to dig into this problem further.The kernel is several weeks old (nouveau tree), it's at commit 000463f13fba6b2f94a5bfcb0d615751ae9c34a0. As you can see from the mesages below the problem is reproducable to the point of getting exactly the same error. Nov 25 17:57:51 madman kernel: [548360.773743] nouveau E[ PGRAPH][0000:01:00.0] PGRAPH TLB flush idle

Hi all, I have what I think is a nouveau-related bug, but don't have all the information they as for on the support page, so thought I'd ask for help here first. My computer will hang after resuming from hibernate/suspend, sometimes showing a normal lock screen and other times just a white screen. I have some extracts from /var/log/messages, but no kernel logs since I cannot get anything

Try booting with `nouveau.nofbaccel=1` and see if that helps. Some many kernels ago, acceleration of the console on fb resume got fixed, and is now causing issues for you and a few others. This will turn off fbcon accel, which should hopefully sidestep the issue. On Sun, Jan 4, 2015 at 5:32 AM, Lukasz Stelmach <stlman at poczta.fm> wrote: > Hello, > > I'd like to bring to your

On 27/05/19 11:47, Peter Zijlstra wrote: > On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote: >> On 25/05/2019 10:22, Nadav Amit wrote: > >>> diff --git a/arch/x86/include/asm/paravirt_types.h b/arch/x86/include/asm/paravirt_types.h >>> index 946f8f1f1efc..3a156e63c57d 100644 >>> --- a/arch/x86/include/asm/paravirt_types.h >>> +++

On Mon, May 27, 2019 at 12:21:59PM +0200, Paolo Bonzini wrote: > On 27/05/19 11:47, Peter Zijlstra wrote: > > --- a/arch/x86/kernel/kvm.c > > +++ b/arch/x86/kernel/kvm.c > > @@ -580,7 +580,7 @@ static void __init kvm_apf_trap_init(voi > > > > static DEFINE_PER_CPU(cpumask_var_t, __pv_tlb_mask); > > > > -static void kvm_flush_tlb_others(const