[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 5/7] x86/iommu: the code addressing CVE-2011-1898 is VT-d specific
- To: Xenia Ragiadakou <burzalodowa@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Tue, 20 Dec 2022 11:09:27 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Z0FkCiCsOFFuToE+3vYNKkCy8RMf3fGNsQ3NJ2FMVc8=; b=DsA8cv+NfmDxRYxB0XC59ovo51bQpcvn13HzL513cKC/GKSON9lPeBMYC51cdwDGZgDimpYHa1cRbPQYJmCO26AkvgkKR42yeIC1hhepVsQF5uxpi9YoDfH6fqgrLEfXJUgcJzEI2neBJkhnuPVEWui0Rp7fPmcybrShSJkiWPg78YSkCbQcad4HYqW6GX3FaPlvUxjkdsbcQCYsv4XqH6kFGqU/pjRzrZBcf+Qzb5bFASHBg/1thFzm96hn6lXpvk0PocV9+ZV2vc6zKJn2HURyMK0RAHI9u68kejEP3OGcixODFJurQCpAQCNd0uLxTO3wE2GmMI1Tn5oXFZIu9w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X4qN8wZWhU0H8WQIcihaJ3lGHZGAxYSysCHYzvI7ISgMQr+vT3bxIUvcSDEeOhmAybsuALF8OpT8mMB0cnCOLw3UxlzvBE9DgQRgcIDZqKHbIdkAweUQphLh7Wx/abYBJ7oVxi58o1OjFFEGT005v7fPYV5zmMPCcr8TBgr81xS5WIqXzcK1xyBsOfJHtSMf+yQIpeW60i9j7w72Orzyt2VEdGB8TTW7ok6AR1FQSliyJG4fT7T9cAdzQagZqLttAIbOZuXTPz8RhUJRr5thghYV4oWovU/PJpd7WW1+GI8jA5bk3TF+I/D7rhrNP3YOoOD0+pRk8A1Qn6VHRourvg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Tue, 20 Dec 2022 11:09:46 +0000
- Ironport-data: A9a23:PGuv7KCWTLprqhVW/xHiw5YqxClBgxIJ4kV8jS/XYbTApGgmhDVSy 2tMCmiGPKqLMGH2eNojPoTnpkkPuZSAzIAxQQY4rX1jcSlH+JHPbTi7wuUcHAvJd5GeExg3h yk6QoOdRCzhZiaE/n9BCpC48T8nk/nNHuCnYAL9EngZbRd+Tys8gg5Ulec8g4p56fC0GArIs t7pyyHlEAbNNwVcbyRFtcpvlDs15K6o4WlC5gRkDRx2lAS2e0c9Xcp3yZ6ZdxMUcqEMdsamS uDKyq2O/2+x13/B3fv8z94X2mVTKlLjFVDmZkh+AsBOsTAbzsAG6Y4pNeJ0VKtio27hc+ada jl6ncfYpQ8BZsUgkQmGOvVSO3kW0aZuoNcrLZUj2CA6IoKvn3bEmp1T4E8K0YIw/PZ2Aj927 cYkFm4ucBK9g8myzIy4Y7w57igjBJGD0II3nFhFlGucKMl8BJfJTuPN+MNS2yo2ioZWB/HCa sEFaD1pKhPdfxlIPVRRA5U79AuqriCnL3sE9xTL++xrswA/zyQouFTpGPPTdsaHWoN+mUGAq 3id12/4HgsbJJqUzj/tHneE1r6VwnOqB9N6+LuQ+cRwgwyU7TAoSyJNBQehhOHgj1e5VIcKQ 6AT0m90xUQoz2ShU8PvVhm/rHmbtzYTXtNRF6sx7wTl4rrZ5UOVC3YJShZFacc6r4kmSDoyz FiLktj1Qzt1v9W9S3iQ67OVpjOaIjUOICkJYipsZRQBy8nupsc0lB2nczp4OKu8j9mwHC6qx TmP9XI6n+9L0Z5N0Lin91fahT7qvoLOUgM++gTQWCSi8x99Y4mmIYev7DA38Mp9EWpQdXHZ1 FBspiRUxLtm4U2l/MBVfNgwIQ==
- Ironport-hdrordr: A9a23:SAYlWa0UjH7fcCiwQEB54gqjBEQkLtp133Aq2lEZdPU0SKGlfg 6V/MjztCWE7gr5PUtLpTnuAsa9qB/nm6KdpLNhX4tKPzOW31dATrsSjrcKqgeIc0HDH6xmpM JdmsBFY+EYZmIK6foSjjPYLz4hquP3j5xBh43lvglQpdcBUdAQ0+97YDzrYnGfXGN9dOME/A L33Ls7m9KnE05nFviTNz0+cMXogcbEr57iaQ5uPW9a1OHf5QnYk4ITCnKjr20jbw8=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZE3QhgtEjjj3o3UG9yEmVkUBhi652oCIA
- Thread-topic: [RFC 5/7] x86/iommu: the code addressing CVE-2011-1898 is VT-d specific
On 19/12/2022 6:34 am, Xenia Ragiadakou wrote:
> The variable untrusted_msi indicates whether the system is vulnerable to
> CVE-2011-1898. This vulnerablity is VT-d specific.
> Place the code that addresses the issue under CONFIG_INTEL_VTD.
>
> No functional change intended.
>
> Signed-off-by: Xenia Ragiadakou <burzalodowa@xxxxxxxxx>
Actually, this variable is pretty bogus. I think I'd like to delete it
entirely.
There are systems with no IOMMU at all, and we certainly used to let PV
Passthrough go ahead. (Not sure we do any more.)
There are systems with DMA remapping only, but no interrupt remapping.
These are known insecure. I'm honestly not convinced that an ISR read
and crash is useful when the user has already constructed an
known-unsafe configuration, because a malicious guest in that case can
still fully mess with dom0 by sending vectors other than 0x80 and 0x82.
In particular, this option does not get activated on AMD when the user
elects to disable interrupt remapping, and I'm disinclined to wire it up
in that case too.
~Andrew
P.S. It occurs to me that FRED obsoletes the need for this anyway,
seeing as it does properly distinguish the source of an event.
|
