Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #81207 > unrolled thread
| Started by | Bastian Blank <waldi@debian.org> |
|---|---|
| First post | 2023-12-13 23:10 +0100 |
| Last post | 2023-12-14 16:10 +0100 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.debian.kernel
[arm64] secure boot breach via VFIO_NOIOMMU Bastian Blank <waldi@debian.org> - 2023-12-13 23:10 +0100
Re: [arm64] secure boot breach via VFIO_NOIOMMU Salvatore Bonaccorso <carnil@debian.org> - 2023-12-14 09:30 +0100
Re: [arm64] secure boot breach via VFIO_NOIOMMU Steve McIntyre <steve@einval.com> - 2023-12-14 16:10 +0100
| From | Bastian Blank <waldi@debian.org> |
|---|---|
| Date | 2023-12-13 23:10 +0100 |
| Subject | [arm64] secure boot breach via VFIO_NOIOMMU |
| Message-ID | <HKFAu-do4X-5@gated-at.bofh.it> |
Hi Over six years ago, support for VFIO without IOMMU was enabled for arm64. This is a breach of the integrity lockdown requirement of secure boot. VFIO is a framework for handle devices in userspace. To make this safe, an IOMMU is required by default. Without it, user space can write everywhere in memory. The code is still not conditional on lockdown, even if a patch was proposed. I intend to disable this option for all supported kernels. Regards, Bastian -- Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
[toc] | [next] | [standalone]
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2023-12-14 09:30 +0100 |
| Message-ID | <HKPgt-dtPi-1@gated-at.bofh.it> |
| In reply to | #81207 |
Hi, On Wed, Dec 13, 2023 at 10:45:01PM +0100, Bastian Blank wrote: > Hi > > Over six years ago, support for VFIO without IOMMU was enabled for > arm64. This is a breach of the integrity lockdown requirement of secure > boot. > > VFIO is a framework for handle devices in userspace. To make > this safe, an IOMMU is required by default. Without it, user space can > write everywhere in memory. The code is still not conditional on > lockdown, even if a patch was proposed. > > I intend to disable this option for all supported kernels. Agreed. For the readers reading this along, this was raised in context of https://salsa.debian.org/kernel-team/linux/-/merge_requests/925#note_446730 and https://salsa.debian.org/kernel-team/linux/-/merge_requests/502#note_315464 The proposed patch felt probably trough the cracks. Regards, Salvatore
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2023-12-14 16:10 +0100 |
| Message-ID | <HKVvz-dyh4-5@gated-at.bofh.it> |
| In reply to | #81209 |
On Thu, Dec 14, 2023 at 09:26:09AM +0100, Salvatore Bonaccorso wrote: >Hi, > >On Wed, Dec 13, 2023 at 10:45:01PM +0100, Bastian Blank wrote: >> Hi >> >> Over six years ago, support for VFIO without IOMMU was enabled for >> arm64. This is a breach of the integrity lockdown requirement of secure >> boot. >> >> VFIO is a framework for handle devices in userspace. To make >> this safe, an IOMMU is required by default. Without it, user space can >> write everywhere in memory. The code is still not conditional on >> lockdown, even if a patch was proposed. >> >> I intend to disable this option for all supported kernels. Definitely. >Agreed. > >For the readers reading this along, this was raised in context of >https://salsa.debian.org/kernel-team/linux/-/merge_requests/925#note_446730 >and https://salsa.debian.org/kernel-team/linux/-/merge_requests/502#note_315464 > >The proposed patch felt probably trough the cracks. Nod. -- Steve McIntyre, Cambridge, UK. steve@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web