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

Package: xen Version: 4.0.1-5.11 Severity: important Tags: security, patch, fixed-upstream http://www.openwall.com/lists/oss-security/2013/11/21/2 Description: An inverted boolean parameter resulted in TLB flushes not happening upon clearing of a present translation table entry. Retaining stale TLB entries could allow guests access to memory that ought to have been revoked, or grant greater

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:

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,

When a domain''s VT-d table is changed, only the iommus under which the domain has assigned devices need to be flushed. Signed-off-by: Yang, Xiaowei <xiaowei.yang@intel.com> Thanks, Xiaowei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

-----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

On map: only flush when old PTE was valid or invalid PTE may be cached. On unmap: always flush old entry, but skip flush for unaffected IOMMUs. Signed-off-by: Espen Skoglund <espen.skoglund@netronome.com> -- iommu.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) -- diff -r 8187fd8113f9 xen/drivers/passthrough/vtd/iommu.c ---

Hi, i visited your homepage http://syslinux.zytor.com/iso.php and tried to find a downloadable Version of isolinux, but couldnt find it... I need it for mindi/mondo. So here is my question: where can I get it? with best regards Mario Caspari Salo Holding AG Spaldingstrasse 57-59 20097 HAMBURG fon: +49(040)23916-136 fax: +49(040)23916-228 mail: mariocaspari at salo-ag.de web: www.salo-ag.de

From: Joerg Roedel <jroedel at suse.de> The Intel VT-d driver already has a matching function to determine the default domain type for a device. Wire it up in intel_iommu_ops. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- drivers/iommu/intel-iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index

From: Joerg Roedel <jroedel at suse.de> Convert the Intel IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- drivers/iommu/intel-iommu.c | 67 ++++--------------------------------- 1 file changed, 6 insertions(+), 61 deletions(-) diff

diff -r e6266fc76d08 -r 6feac926cf80 xen/drivers/passthrough/vtd/iommu.c --- a/xen/drivers/passthrough/vtd/iommu.c Fri Jul 27 12:22:13 2012 +0200 +++ b/xen/drivers/passthrough/vtd/iommu.c Mon Jul 30 15:35:16 2012 -0700 @@ -2137,6 +2137,15 @@ int __init intel_vtd_setup(void) { iommu = drhd->iommu; + printk("Intel VT-d supported page sizes: 4kB"); + if

Remove all IOVA handling code from the non-dma_ops path in the intel iommu driver. There's no need for the non-dma_ops path to keep track of IOVAs. The whole point of the non-dma_ops path is that it allows the IOVAs to be handled separately. The IOVA handling code removed in this patch is pointless. Signed-off-by: Tom Murphy <murphyt7 at tcd.ie> --- drivers/iommu/intel-iommu.c | 89

We should only assign intel_dma_ops to devices which will actually use the iommu and let the default fall back dma_direct_* functions handle all other devices. This won't change any behaviour but will just use the generic implementations for direct mapped devices rather than intel specific ones. Signed-off-by: Tom Murphy <murphyt7 at tcd.ie> --- drivers/iommu/intel-iommu.c | 52

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

> On Jun 25, 2019, at 8:36 PM, Andy Lutomirski <luto at kernel.org> wrote: > > On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit <namit at vmware.com> wrote: >> To improve TLB shootdown performance, flush the remote and local TLBs >> concurrently. Introduce flush_tlb_multi() that does so. The current >> flush_tlb_others() interface is kept, since paravirtual

On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit <namit at vmware.com> wrote: > > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. The current > flush_tlb_others() interface is kept, since paravirtual interfaces need > to be adapted first before it can be removed. This is left for future > work. In

Hi, Patch below is needed to make my system work stable in PAE mode. Havn''t seen problems without PAE, not sure whenever thats just pure luck or whenever there is a bug in my PAE xenlinux kernel. To me it looks like a generic bug though. I''ve actually trapped into problems with unpin only: A process exits, somewhere in exit_mm() the page tables are unpinned, shortly thereafter

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

> On Jul 22, 2019, at 12:14 PM, Peter Zijlstra <peterz at infradead.org> wrote: > > On Thu, Jul 18, 2019 at 05:58:32PM -0700, Nadav Amit wrote: >> @@ -709,8 +716,9 @@ void native_flush_tlb_others(const struct cpumask *cpumask, >> * doing a speculative memory access. >> */ >> if (info->freed_tables) { >> - smp_call_function_many(cpumask,

On 25/05/2019 10:22, Nadav Amit wrote: > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. The current > flush_tlb_others() interface is kept, since paravirtual interfaces need > to be adapted first before it can be removed. This is left for future > work. In such PV environments, TLB flushes are not