info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[arm64] secure boot breach via VFIO_NOIOMMU
6 views
Skip to first unread message
Bastian Blank
Dec 13, 2023, 5:10:04 PM12/13/23
to
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.
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.
Salvatore Bonaccorso
Dec 14, 2023, 3:30:05 AM12/14/23
to
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
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.
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
Steve McIntyre
Dec 14, 2023, 10:10:04 AM12/14/23
to
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.
>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.
--
Steve McIntyre, Cambridge, UK. st...@einval.com
The two hard things in computing:
* naming things
* cache invalidation
* off-by-one errors -- Stig Sandbeck Mathisen
0 new messages