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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9b7e5e81-622e-4726-b8c0-3171f48d2639@arm.com>
Date: Wed, 2 Oct 2024 14:59:35 +0100
From: Steven Price <steven.price@....com>
To: Thomas Gleixner <tglx@...utronix.de>,
 Michael Kelley <mhklinux@...look.com>, Marc Zyngier <maz@...nel.org>
Cc: "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Will Deacon <will@...nel.org>, Suzuki K Poulose <suzuki.poulose@....com>
Subject: Re: [PATCH 1/2] irqchip/gic-v3-its: Share ITS tables with a
 non-trusted hypervisor

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