linux-kernel - Re: [PATCH] dma-direct: zero out DMA_ATTR_NO_KERNEL

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1eb4a2b0-2fd4-9f3c-e610-c8f856027181@samsung.com>
Date:   Mon, 7 Sep 2020 09:02:34 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>,
        Hillf Danton <hdanton@...a.com>
Cc:     Christoph Hellwig <hch@....de>, linux-nvme@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
        Matthew Wilcox <willy@...radead.org>,
        linux-arch@...r.kernel.org
Subject: Re: [PATCH] dma-direct: zero out DMA_ATTR_NO_KERNEL_MAPPING buf

Hi James,

On 05.09.2020 17:50, James Bottomley wrote:
> [resend with correct linux-arch address]
> On Sat, 2020-09-05 at 15:35 +0800, Hillf Danton wrote:
>> On Fri, 04 Sep 2020 08:34:39 -0700 James Bottomley wrote:
>>> On Fri, 2020-09-04 at 23:25 +0800, Hillf Danton wrote:
>>>> The DMA buffer allocated is always cleared in DMA core and this
>>>> is making DMA_ATTR_NO_KERNEL_MAPPING non-special.
>>>>
>>>> Fixes: d98849aff879 ("dma-direct: handle
>>>> DMA_ATTR_NO_KERNEL_MAPPING
>>>> in common code")
>>>> Cc: Kees Cook <keescook@...omium.org>
>>>> Cc: Matthew Wilcox <willy@...radead.org>
>>>> Cc: Marek Szyprowski <m.szyprowski@...sung.com>
>>>> Cc: James Bottomley <James.Bottomley@...senPartnership.com>
>>>> Signed-off-by: Hillf Danton <hdanton@...a.com>
>>>> ---
>>>>
>>>> --- a/kernel/dma/direct.c
>>>> +++ b/kernel/dma/direct.c
>>>> @@ -178,9 +178,17 @@ void *dma_direct_alloc_pages(struct devi
>>>>   
>>>>   	if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
>>>>   	    !force_dma_unencrypted(dev)) {
>>>> +		int i;
>>>> +
>>>>   		/* remove any dirty cache lines on the kernel
>>>> alias
>>>> */
>>>>   		if (!PageHighMem(page))
>>>>   			arch_dma_prep_coherent(page, size);
>>>> +
>>>> +		for (i = 0; i < size/PAGE_SIZE; i++) {
>>>> +			ret = kmap_atomic(page + i);
>>>> +			memset(ret, 0, PAGE_SIZE);
>>>> +			kunmap_atomic(ret);
>> Hi James
>>> This is massively expensive on PARISC and likely other VIPT/VIVT
>>> architectures.
>> Correct.
>>
>>> What's the reason for clearing it?  This could also be
>> 	/* we always manually zero the memory once we are done: */
>> 	gfp &= ~__GFP_ZERO;
>> 	gfp |= dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
>> 					   &phys_limit);
> That's not a reason ... that comment was put in for coherent mappings.
> What is the reason we should incur all this expense for clearing pages
> which aren't unmapped in the kernel, because we can update the comment?
>   The usual rationale for kernel mapped pages is security, because they
> may leak information but unmapped pages shouldn't have this problem.

Any dma_alloc_attrs() buffer might be mmaped to userspace, so the 
security reason is still valid. Possible lack if kernel mapping was only 
a hint that driver doesn't need it, so it might be skipped on some 
architectures, where creating it requires significant resources (i.e. 
vmalloc area).

>>> really inefficient even on PIPT architectures if the memory is
>>> device remote.
>>>
>>> If we really have to do this, it should likely be done in the arch
>>> or driver hooks because there are potentially more efficient ways
>>> we can do this knowing how the architecture behaves.
>> I'm open to any vintage ideas in your mind wrt clearing dma buf e.g
>> on platforms like PARISC. Or feel free to offload me the work if it
>> makes sense to you who are rich of PARISC knowledge.
> OK, I've cc'd linux-arch because this is a problem for more than just
> parisc.  However, not having to do it is the best solution ... sort of
> the doctor, doctor it hurts when I do this answer.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland