linux-kernel - Re: [PATCH] dma-direct: Don't over-decrypt memory

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: <22439fa1-5f9b-1e54-3f39-649b116574e@google.com>
Date:   Sun, 22 May 2022 18:04:51 -0700 (PDT)
From:   David Rientjes <rientjes@...gle.com>
To:     Robin Murphy <robin.murphy@....com>
cc:     hch@....de, m.szyprowski@...sung.com,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
        thomas.lendacky@....com, stable@...r.kernel.org
Subject: Re: [PATCH] dma-direct: Don't over-decrypt memory

On Fri, 20 May 2022, Robin Murphy wrote:

> The original x86 sev_alloc() only called set_memory_decrypted() on
> memory returned by alloc_pages_node(), so the page order calculation
> fell out of that logic. However, the common dma-direct code has several
> potential allocators, not all of which are guaranteed to round up the
> underlying allocation to a power-of-two size, so carrying over that
> calculation for the encryption/decryption size was a mistake. Fix it by
> rounding to a *number* of pages, rather than an order.
> 
> Until recently there was an even worse interaction with DMA_DIRECT_REMAP
> where we could have ended up decrypting part of the next adjacent
> vmalloc area, only averted by no architecture actually supporting both
> configs at once. Don't ask how I found that one out...
> 
> CC: stable@...r.kernel.org
> Fixes: c10f07aa27da ("dma/direct: Handle force decryption for DMA coherent buffers in common code")
> Signed-off-by: Robin Murphy <robin.murphy@....com>

Acked-by: David Rientjes <rientjes@...gle.com>