* [Intel-wired-lan] Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX @ 2021-01-08 11:57 Radev, Martin 2021-01-08 15:31 ` Radev, Martin 2021-02-01 20:23 ` Ronak Doshi 0 siblings, 2 replies; 9+ messages in thread From: Radev, Martin @ 2021-01-08 11:57 UTC (permalink / raw) To: intel-wired-lan Hello everybody, tldr: Both drivers expose skb GVAs to untrusted devices which gives RIP control to a malicious e100 / vmxnet3 device implementation. This is an issue for AMD SEV (-SNP) [1] and likely Intel TDX [2]. Felicitas and Robert have started a project on fuzzing device drivers which may have negative security impact on solutions like AMD SEV Secure Nested Paging and Intel Trusted Domain Extensions. These solutions protect a VM from a malicious Hypervisor in various way. There are a couple of devices which carry security issues under the attacker models of SEV-SNP / Intel TDX, but here we're only discussing VMXNET3 and e100, because we have detailed PoCs for both. Maintainers of both vmxnet3 and e100 were added in this email because the discussion will likely be the same. The issues were already sent to AMD PSIRT, and Tom Lendacky and Brijesh Singh have volunteered to be part of the email communication with the maintainers. Both have been working on AMD SEV. Please check the two attached files: vmxnet3_report.txt and e100_report.txt. Both contain detailed information about what the issue is and how it can be exploited by a malicious HV or attacker who has access to the QEMU process. Fix: In an earlier discussion with AMD, there was the idea of making a list of allowed devices with SEV and forbidding everything else. This would avoid issues with other drivers whose implementation has not been yet scrutinized under the threat model of SEV-SNP and Intel Trusted Domain Extensions. Let us know what you think. Kind regards, Martin [1]: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf [2]: https://software.intel.com/content/www/us/en/develop/articles/intel-trust-domain-extensions.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20210108/032074e9/attachment-0001.html> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vmxnet3_report.txt URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20210108/032074e9/attachment-0002.txt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: e100_report.txt URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20210108/032074e9/attachment-0003.txt> ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Intel-wired-lan] Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX 2021-01-08 11:57 [Intel-wired-lan] Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX Radev, Martin @ 2021-01-08 15:31 ` Radev, Martin 2021-01-11 13:26 ` [Intel-wired-lan] " Kirill A. Shutemov 2021-02-01 20:23 ` Ronak Doshi 1 sibling, 1 reply; 9+ messages in thread From: Radev, Martin @ 2021-01-08 15:31 UTC (permalink / raw) To: intel-wired-lan Just noticed that Intel TDX already does the device filtering. Check: https://github.com/intel/tdx/commit/6789eee52aab8985e49b362379fab73aa3eecde2 CC-ing Kirill and Kuppuswamy from Intel in case they want to be part of the discussion. ________________________________ From: Radev, Martin Sent: Friday, January 8, 2021 12:57 PM To: netdev@vger.kernel.org <netdev@vger.kernel.org>; intel-wired-lan at lists.osuosl.org <intel-wired-lan@lists.osuosl.org> Cc: doshir at vmware.com <doshir@vmware.com>; jesse.brandeburg at intel.com <jesse.brandeburg@intel.com>; anthony.l.nguyen at intel.com <anthony.l.nguyen@intel.com>; Morbitzer, Mathias <mathias.morbitzer@aisec.fraunhofer.de>; Robert Buhren <robert.buhren@sect.tu-berlin.de>; file at sect.tu-berlin.de <file@sect.tu-berlin.de>; Banse, Christian <christian.banse@aisec.fraunhofer.de>; brijesh.singh at amd.com <brijesh.singh@amd.com>; Thomas.Lendacky at amd.com <Thomas.Lendacky@amd.com>; pv-drivers at vmware.com <pv-drivers@vmware.com>; martin.b.radev at gmail.com <martin.b.radev@gmail.com> Subject: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX Hello everybody, tldr: Both drivers expose skb GVAs to untrusted devices which gives RIP control to a malicious e100 / vmxnet3 device implementation. This is an issue for AMD SEV (-SNP) [1] and likely Intel TDX [2]. Felicitas and Robert have started a project on fuzzing device drivers which may have negative security impact on solutions like AMD SEV Secure Nested Paging and Intel Trusted Domain Extensions. These solutions protect a VM from a malicious Hypervisor in various way. There are a couple of devices which carry security issues under the attacker models of SEV-SNP / Intel TDX, but here we're only discussing VMXNET3 and e100, because we have detailed PoCs for both. Maintainers of both vmxnet3 and e100 were added in this email because the discussion will likely be the same. The issues were already sent to AMD PSIRT, and Tom Lendacky and Brijesh Singh have volunteered to be part of the email communication with the maintainers. Both have been working on AMD SEV. Please check the two attached files: vmxnet3_report.txt and e100_report.txt. Both contain detailed information about what the issue is and how it can be exploited by a malicious HV or attacker who has access to the QEMU process. Fix: In an earlier discussion with AMD, there was the idea of making a list of allowed devices with SEV and forbidding everything else. This would avoid issues with other drivers whose implementation has not been yet scrutinized under the threat model of SEV-SNP and Intel Trusted Domain Extensions. Let us know what you think. Kind regards, Martin [1]: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf [2]: https://software.intel.com/content/www/us/en/develop/articles/intel-trust-domain-extensions.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20210108/0976848d/attachment.html> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX 2021-01-08 15:31 ` Radev, Martin @ 2021-01-11 13:26 ` Kirill A. Shutemov 0 siblings, 0 replies; 9+ messages in thread From: Kirill A. Shutemov @ 2021-01-11 13:26 UTC (permalink / raw) To: Radev, Martin Cc: netdev, intel-wired-lan, doshir, jesse.brandeburg, anthony.l.nguyen, Morbitzer, Mathias, Robert Buhren, file, Banse, Christian, brijesh.singh, Thomas.Lendacky, pv-drivers, martin.b.radev, sathyanarayanan.kuppuswamy, Kleen, Andi On Fri, Jan 08, 2021 at 03:31:56PM +0000, Radev, Martin wrote: > Just noticed that Intel TDX already does the device filtering. Check: https://github.com/intel/tdx/commit/6789eee52aab8985e49b362379fab73aa3eecde2 > > CC-ing Kirill and Kuppuswamy from Intel in case they want to be part of the discussion. > ________________________________ > From: Radev, Martin > Sent: Friday, January 8, 2021 12:57 PM > To: netdev@vger.kernel.org <netdev@vger.kernel.org>; intel-wired-lan@lists.osuosl.org <intel-wired-lan@lists.osuosl.org> > Cc: doshir@vmware.com <doshir@vmware.com>; jesse.brandeburg@intel.com <jesse.brandeburg@intel.com>; anthony.l.nguyen@intel.com <anthony.l.nguyen@intel.com>; Morbitzer, Mathias <mathias.morbitzer@aisec.fraunhofer.de>; Robert Buhren <robert.buhren@sect.tu-berlin.de>; file@sect.tu-berlin.de <file@sect.tu-berlin.de>; Banse, Christian <christian.banse@aisec.fraunhofer.de>; brijesh.singh@amd.com <brijesh.singh@amd.com>; Thomas.Lendacky@amd.com <Thomas.Lendacky@amd.com>; pv-drivers@vmware.com <pv-drivers@vmware.com>; martin.b.radev@gmail.com <martin.b.radev@gmail.com> > Subject: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX > > Hello everybody, > > tldr: Both drivers expose skb GVAs to untrusted devices which gives RIP > control to a malicious e100 / vmxnet3 device implementation. This is > an issue for AMD SEV (-SNP) [1] and likely Intel TDX [2]. > > Felicitas and Robert have started a project on fuzzing device drivers which > may have negative security impact on solutions like AMD SEV Secure > Nested Paging and Intel Trusted Domain Extensions. These solutions protect > a VM from a malicious Hypervisor in various way. > > There are a couple of devices which carry security issues under the attacker > models of SEV-SNP / Intel TDX, but here we're only discussing VMXNET3 and > e100, because we have detailed PoCs for both. > > Maintainers of both vmxnet3 and e100 were added in this email because the > discussion will likely be the same. The issues were already sent to AMD PSIRT, > and Tom Lendacky and Brijesh Singh have volunteered to be part of the email > communication with the maintainers. Both have been working on AMD SEV. > > Please check the two attached files: vmxnet3_report.txt and e100_report.txt. > Both contain detailed information about what the issue is and how it can be > exploited by a malicious HV or attacker who has access to the QEMU process. > > Fix: > In an earlier discussion with AMD, there was the idea of making a list of > allowed devices with SEV and forbidding everything else. This would avoid > issues with other drivers whose implementation has not been yet scrutinized > under the threat model of SEV-SNP and Intel Trusted Domain Extensions. +Andi. Right. Our TDX guest enabling has white list of devices that allowed to be used. For now it's only VirtIO, but I believe it also requires hardening. We need to validate any VMM input. It might be beneficial to have coordination between Intel and AMD on what devices (and device drivers) considered to be safe for trusted computing. I think we can share burden of code audit and fuzzing. -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Intel-wired-lan] Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX @ 2021-01-11 13:26 ` Kirill A. Shutemov 0 siblings, 0 replies; 9+ messages in thread From: Kirill A. Shutemov @ 2021-01-11 13:26 UTC (permalink / raw) To: intel-wired-lan On Fri, Jan 08, 2021 at 03:31:56PM +0000, Radev, Martin wrote: > Just noticed that Intel TDX already does the device filtering. Check: https://github.com/intel/tdx/commit/6789eee52aab8985e49b362379fab73aa3eecde2 > > CC-ing Kirill and Kuppuswamy from Intel in case they want to be part of the discussion. > ________________________________ > From: Radev, Martin > Sent: Friday, January 8, 2021 12:57 PM > To: netdev at vger.kernel.org <netdev@vger.kernel.org>; intel-wired-lan at lists.osuosl.org <intel-wired-lan@lists.osuosl.org> > Cc: doshir at vmware.com <doshir@vmware.com>; jesse.brandeburg at intel.com <jesse.brandeburg@intel.com>; anthony.l.nguyen at intel.com <anthony.l.nguyen@intel.com>; Morbitzer, Mathias <mathias.morbitzer@aisec.fraunhofer.de>; Robert Buhren <robert.buhren@sect.tu-berlin.de>; file at sect.tu-berlin.de <file@sect.tu-berlin.de>; Banse, Christian <christian.banse@aisec.fraunhofer.de>; brijesh.singh at amd.com <brijesh.singh@amd.com>; Thomas.Lendacky at amd.com <Thomas.Lendacky@amd.com>; pv-drivers at vmware.com <pv-drivers@vmware.com>; martin.b.radev at gmail.com <martin.b.radev@gmail.com> > Subject: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX > > Hello everybody, > > tldr: Both drivers expose skb GVAs to untrusted devices which gives RIP > control to a malicious e100 / vmxnet3 device implementation. This is > an issue for AMD SEV (-SNP) [1] and likely Intel TDX [2]. > > Felicitas and Robert have started a project on fuzzing device drivers which > may have negative security impact on solutions like AMD SEV Secure > Nested Paging and Intel Trusted Domain Extensions. These solutions protect > a VM from a malicious Hypervisor in various way. > > There are a couple of devices which carry security issues under the attacker > models of SEV-SNP / Intel TDX, but here we're only discussing VMXNET3 and > e100, because we have detailed PoCs for both. > > Maintainers of both vmxnet3 and e100 were added in this email because the > discussion will likely be the same. The issues were already sent to AMD PSIRT, > and Tom Lendacky and Brijesh Singh have volunteered to be part of the email > communication with the maintainers. Both have been working on AMD SEV. > > Please check the two attached files: vmxnet3_report.txt and e100_report.txt. > Both contain detailed information about what the issue is and how it can be > exploited by a malicious HV or attacker who has access to the QEMU process. > > Fix: > In an earlier discussion with AMD, there was the idea of making a list of > allowed devices with SEV and forbidding everything else. This would avoid > issues with other drivers whose implementation has not been yet scrutinized > under the threat model of SEV-SNP and Intel Trusted Domain Extensions. +Andi. Right. Our TDX guest enabling has white list of devices that allowed to be used. For now it's only VirtIO, but I believe it also requires hardening. We need to validate any VMM input. It might be beneficial to have coordination between Intel and AMD on what devices (and device drivers) considered to be safe for trusted computing. I think we can share burden of code audit and fuzzing. -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX 2021-01-11 13:26 ` [Intel-wired-lan] " Kirill A. Shutemov @ 2021-01-11 13:56 ` Robert Buhren -1 siblings, 0 replies; 9+ messages in thread From: Robert Buhren @ 2021-01-11 13:56 UTC (permalink / raw) To: Kirill A. Shutemov, Radev, Martin Cc: netdev, intel-wired-lan, doshir, jesse.brandeburg, anthony.l.nguyen, Morbitzer, Mathias, file, Banse, Christian, brijesh.singh, Thomas.Lendacky, pv-drivers, martin.b.radev, sathyanarayanan.kuppuswamy, Kleen, Andi On 1/11/21 2:26 PM, Kirill A. Shutemov wrote: > On Fri, Jan 08, 2021 at 03:31:56PM +0000, Radev, Martin wrote: >> Just noticed that Intel TDX already does the device filtering. Check: https://github.com/intel/tdx/commit/6789eee52aab8985e49b362379fab73aa3eecde2 >> >> CC-ing Kirill and Kuppuswamy from Intel in case they want to be part of the discussion. >> ________________________________ >> From: Radev, Martin >> Sent: Friday, January 8, 2021 12:57 PM >> To: netdev@vger.kernel.org <netdev@vger.kernel.org>; intel-wired-lan@lists.osuosl.org <intel-wired-lan@lists.osuosl.org> >> Cc: doshir@vmware.com <doshir@vmware.com>; jesse.brandeburg@intel.com <jesse.brandeburg@intel.com>; anthony.l.nguyen@intel.com <anthony.l.nguyen@intel.com>; Morbitzer, Mathias <mathias.morbitzer@aisec.fraunhofer.de>; Robert Buhren <robert.buhren@sect.tu-berlin.de>; file@sect.tu-berlin.de <file@sect.tu-berlin.de>; Banse, Christian <christian.banse@aisec.fraunhofer.de>; brijesh.singh@amd.com <brijesh.singh@amd.com>; Thomas.Lendacky@amd.com <Thomas.Lendacky@amd.com>; pv-drivers@vmware.com <pv-drivers@vmware.com>; martin.b.radev@gmail.com <martin.b.radev@gmail.com> >> Subject: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX >> >> Hello everybody, >> >> tldr: Both drivers expose skb GVAs to untrusted devices which gives RIP >> control to a malicious e100 / vmxnet3 device implementation. This is >> an issue for AMD SEV (-SNP) [1] and likely Intel TDX [2]. >> >> Felicitas and Robert have started a project on fuzzing device drivers which >> may have negative security impact on solutions like AMD SEV Secure >> Nested Paging and Intel Trusted Domain Extensions. These solutions protect >> a VM from a malicious Hypervisor in various way. >> >> There are a couple of devices which carry security issues under the attacker >> models of SEV-SNP / Intel TDX, but here we're only discussing VMXNET3 and >> e100, because we have detailed PoCs for both. >> >> Maintainers of both vmxnet3 and e100 were added in this email because the >> discussion will likely be the same. The issues were already sent to AMD PSIRT, >> and Tom Lendacky and Brijesh Singh have volunteered to be part of the email >> communication with the maintainers. Both have been working on AMD SEV. >> >> Please check the two attached files: vmxnet3_report.txt and e100_report.txt. >> Both contain detailed information about what the issue is and how it can be >> exploited by a malicious HV or attacker who has access to the QEMU process. >> >> Fix: >> In an earlier discussion with AMD, there was the idea of making a list of >> allowed devices with SEV and forbidding everything else. This would avoid >> issues with other drivers whose implementation has not been yet scrutinized >> under the threat model of SEV-SNP and Intel Trusted Domain Extensions. > +Andi. > > Right. Our TDX guest enabling has white list of devices that allowed to be > used. For now it's only VirtIO, but I believe it also requires hardening. > We need to validate any VMM input. > > It might be beneficial to have coordination between Intel and AMD on what > devices (and device drivers) considered to be safe for trusted computing. > I think we can share burden of code audit and fuzzing. Let us know if you are interested in our fuzzing/static analysis setup. We're planning to submit a paper soon and we will publish the source code along with the paper. -- Robert Buhren <robert.buhren@sect.tu-berlin.de> Security in Telecommunications <https://sect.tu-berlin.de> TU Berlin / Telekom Innovation Laboratories Ernst-Reuter-Platz 7, Sekr TEL 16 / D - 10587 Berlin, Germany phone: +49 30 835358325 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Intel-wired-lan] Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX @ 2021-01-11 13:56 ` Robert Buhren 0 siblings, 0 replies; 9+ messages in thread From: Robert Buhren @ 2021-01-11 13:56 UTC (permalink / raw) To: intel-wired-lan On 1/11/21 2:26 PM, Kirill A. Shutemov wrote: > On Fri, Jan 08, 2021 at 03:31:56PM +0000, Radev, Martin wrote: >> Just noticed that Intel TDX already does the device filtering. Check: https://github.com/intel/tdx/commit/6789eee52aab8985e49b362379fab73aa3eecde2 >> >> CC-ing Kirill and Kuppuswamy from Intel in case they want to be part of the discussion. >> ________________________________ >> From: Radev, Martin >> Sent: Friday, January 8, 2021 12:57 PM >> To: netdev at vger.kernel.org <netdev@vger.kernel.org>; intel-wired-lan at lists.osuosl.org <intel-wired-lan@lists.osuosl.org> >> Cc: doshir at vmware.com <doshir@vmware.com>; jesse.brandeburg at intel.com <jesse.brandeburg@intel.com>; anthony.l.nguyen at intel.com <anthony.l.nguyen@intel.com>; Morbitzer, Mathias <mathias.morbitzer@aisec.fraunhofer.de>; Robert Buhren <robert.buhren@sect.tu-berlin.de>; file at sect.tu-berlin.de <file@sect.tu-berlin.de>; Banse, Christian <christian.banse@aisec.fraunhofer.de>; brijesh.singh at amd.com <brijesh.singh@amd.com>; Thomas.Lendacky at amd.com <Thomas.Lendacky@amd.com>; pv-drivers at vmware.com <pv-drivers@vmware.com>; martin.b.radev at gmail.com <martin.b.radev@gmail.com> >> Subject: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX >> >> Hello everybody, >> >> tldr: Both drivers expose skb GVAs to untrusted devices which gives RIP >> control to a malicious e100 / vmxnet3 device implementation. This is >> an issue for AMD SEV (-SNP) [1] and likely Intel TDX [2]. >> >> Felicitas and Robert have started a project on fuzzing device drivers which >> may have negative security impact on solutions like AMD SEV Secure >> Nested Paging and Intel Trusted Domain Extensions. These solutions protect >> a VM from a malicious Hypervisor in various way. >> >> There are a couple of devices which carry security issues under the attacker >> models of SEV-SNP / Intel TDX, but here we're only discussing VMXNET3 and >> e100, because we have detailed PoCs for both. >> >> Maintainers of both vmxnet3 and e100 were added in this email because the >> discussion will likely be the same. The issues were already sent to AMD PSIRT, >> and Tom Lendacky and Brijesh Singh have volunteered to be part of the email >> communication with the maintainers. Both have been working on AMD SEV. >> >> Please check the two attached files: vmxnet3_report.txt and e100_report.txt. >> Both contain detailed information about what the issue is and how it can be >> exploited by a malicious HV or attacker who has access to the QEMU process. >> >> Fix: >> In an earlier discussion with AMD, there was the idea of making a list of >> allowed devices with SEV and forbidding everything else. This would avoid >> issues with other drivers whose implementation has not been yet scrutinized >> under the threat model of SEV-SNP and Intel Trusted Domain Extensions. > +Andi. > > Right. Our TDX guest enabling has white list of devices that allowed to be > used. For now it's only VirtIO, but I believe it also requires hardening. > We need to validate any VMM input. > > It might be beneficial to have coordination between Intel and AMD on what > devices (and device drivers) considered to be safe for trusted computing. > I think we can share burden of code audit and fuzzing. Let us know if you are interested in our fuzzing/static analysis setup. We're planning to submit a paper soon and we will publish the source code along with the paper. -- Robert Buhren <robert.buhren@sect.tu-berlin.de> Security in Telecommunications <https://sect.tu-berlin.de> TU Berlin / Telekom Innovation Laboratories Ernst-Reuter-Platz 7, Sekr TEL 16 / D - 10587 Berlin, Germany phone: +49 30 835358325 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX 2021-01-11 13:56 ` [Intel-wired-lan] " Robert Buhren @ 2021-01-11 17:24 ` Kleen, Andi -1 siblings, 0 replies; 9+ messages in thread From: Kleen, Andi @ 2021-01-11 17:24 UTC (permalink / raw) To: Robert Buhren, Kirill A. Shutemov, Radev, Martin Cc: netdev, intel-wired-lan, doshir, Brandeburg, Jesse, Nguyen, Anthony L, Morbitzer, Mathias, file, Banse, Christian, brijesh.singh, Thomas.Lendacky, pv-drivers, martin.b.radev, sathyanarayanan.kuppuswamy >Let us know if you are interested in our fuzzing/static analysis setup. >We're planning to submit a paper soon and we will publish the source >code along with the paper. We already have an own static analysis/fuzzing frame work, but it's not released yet. -Andi ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Intel-wired-lan] Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX @ 2021-01-11 17:24 ` Kleen, Andi 0 siblings, 0 replies; 9+ messages in thread From: Kleen, Andi @ 2021-01-11 17:24 UTC (permalink / raw) To: intel-wired-lan >Let us know if you are interested in our fuzzing/static analysis setup. >We're planning to submit a paper soon and we will publish the source >code along with the paper. We already have an own static analysis/fuzzing frame work, but it's not released yet. -Andi ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Intel-wired-lan] Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX 2021-01-08 11:57 [Intel-wired-lan] Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX Radev, Martin 2021-01-08 15:31 ` Radev, Martin @ 2021-02-01 20:23 ` Ronak Doshi 1 sibling, 0 replies; 9+ messages in thread From: Ronak Doshi @ 2021-02-01 20:23 UTC (permalink / raw) To: intel-wired-lan Vmxnet3 patch has been committed to mainline Linux https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/drivers/net/vmxnet3?id=de1da8bcf40564a2adada2d5d5426e05355f66e8 Thanks, Ronak From: "Radev, Martin" <martin.radev@aisec.fraunhofer.de> Date: Friday, January 8, 2021 at 3:57 AM To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "intel-wired-lan at lists.osuosl.org" <intel-wired-lan@lists.osuosl.org> Cc: Ronak Doshi <doshir@vmware.com>, "jesse.brandeburg at intel.com" <jesse.brandeburg@intel.com>, "anthony.l.nguyen at intel.com" <anthony.l.nguyen@intel.com>, "Morbitzer, Mathias" <mathias.morbitzer@aisec.fraunhofer.de>, Robert Buhren <robert.buhren@sect.tu-berlin.de>, "file at sect.tu-berlin.de" <file@sect.tu-berlin.de>, "Banse, Christian" <christian.banse@aisec.fraunhofer.de>, "brijesh.singh at amd.com" <brijesh.singh@amd.com>, "Thomas.Lendacky at amd.com" <Thomas.Lendacky@amd.com>, Pv-drivers <Pv-drivers@vmware.com>, "martin.b.radev at gmail.com" <martin.b.radev@gmail.com> Subject: Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX Hello everybody, tldr: Both drivers expose skb GVAs to untrusted devices which gives RIP control to a malicious e100 / vmxnet3 device implementation. This is an issue for AMD SEV (-SNP) [1] and likely Intel TDX [2]. Felicitas and Robert have started a project on fuzzing device drivers which may have negative security impact on solutions like AMD SEV Secure Nested Paging and Intel Trusted Domain Extensions. These solutions protect a VM from a malicious Hypervisor in various way. There are a couple of devices which carry security issues under the attacker models of SEV-SNP / Intel TDX, but here we're only discussing VMXNET3 and e100, because we have detailed PoCs for both. Maintainers of both vmxnet3 and e100 were added in this email because the discussion will likely be the same. The issues were already sent to AMD PSIRT, and Tom Lendacky and Brijesh Singh have volunteered to be part of the email communication with the maintainers. Both have been working on AMD SEV. Please check the two attached files: vmxnet3_report.txt and e100_report.txt. Both contain detailed information about what the issue is and how it can be exploited by a malicious HV or attacker who has access to the QEMU process. Fix: In an earlier discussion with AMD, there was the idea of making a list of allowed devices with SEV and forbidding everything else. This would avoid issues with other drivers whose implementation has not been yet scrutinized under the threat model of SEV-SNP and Intel Trusted Domain Extensions. Let us know what you think. Kind regards, Martin [1]: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2FSEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf&data=04%7C01%7Cdoshir%40vmware.com%7C321954cba3ff43a816da08d8b3cc8c8e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637457038522201270%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BamituKoHDWFzZ%2FYVH5FQU93BblvsuNEcLWLBQIHaxQ%3D&reserved=0> [2]: https://software.intel.com/content/www/us/en/develop/articles/intel-trust-domain-extensions.html<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsoftware.intel.com%2Fcontent%2Fwww%2Fus%2Fen%2Fdevelop%2Farticles%2Fintel-trust-domain-extensions.html&data=04%7C01%7Cdoshir%40vmware.com%7C321954cba3ff43a816da08d8b3cc8c8e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637457038522211265%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DKfk6PXESru%2Fq4U3Ct3HkmqAn%2BwCHLnzVKL7lCDMiDI%3D&reserved=0> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20210201/5eb48d98/attachment-0001.html> ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-02-01 20:23 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-08 11:57 [Intel-wired-lan] Security issue with vmxnet3 and e100 for AMD SEV(-SNP) / Intel TDX Radev, Martin 2021-01-08 15:31 ` Radev, Martin 2021-01-11 13:26 ` Kirill A. Shutemov 2021-01-11 13:26 ` [Intel-wired-lan] " Kirill A. Shutemov 2021-01-11 13:56 ` Robert Buhren 2021-01-11 13:56 ` [Intel-wired-lan] " Robert Buhren 2021-01-11 17:24 ` Kleen, Andi 2021-01-11 17:24 ` [Intel-wired-lan] " Kleen, Andi 2021-02-01 20:23 ` Ronak Doshi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.