[PATCH 1/2] irqchip/gic-v3-its: Share ITS tables with a non-trusted hypervisor

Steven Price steven.price at arm.com
Wed Oct 2 06:59:35 PDT 2024


On 02/10/2024 14:43, Thomas Gleixner wrote:
> On Mon, Sep 09 2024 at 03:47, Michael Kelley wrote:
>>> +	ret = set_memory_decrypted((unsigned long)page_address(page),
>>> +				   1 << order);
>>> +	if (WARN_ON(ret))
>>
>> On the x86 side, the WARN is done in the implementation of
>> set_memory_decrypted()/encrypted() so that each call site doesn't
>> need to do the WARN. Each call site must only leak the memory
>> if the return value indicates other than success. There are call sites
>> in architecture neutral code (such as for swiotlb and DMA direct)
>> that expect the WARN is in set_memory_decrypted()/encrypted().
>> To recap a previous discussion, we want the WARN for notification,
>> but also so the most security-conscious users can set
>> kernel.panic_on_warn=1 to stop further processing if there are
>> problems in the decryption/encryption operation.
> 
> What's the resolution of this?

Sorry, I should have replied.

Moving the WARN into set_memory_decrypted/encrypted() makes sense, and
I'll make that change when I post the next version of the Arm CCA patches.

I'll post an updated version of this series with the WARN_ONs removed
shortly.

Thanks,
Steve



More information about the linux-arm-kernel mailing list