From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F30AC43461 for ; Sat, 5 Sep 2020 15:47:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 339E72078E for ; Sat, 5 Sep 2020 15:47:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="IPcOeu/n"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="mke0N8Gm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726582AbgIEPqw (ORCPT ); Sat, 5 Sep 2020 11:46:52 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:46572 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726261AbgIEPqk (ORCPT ); Sat, 5 Sep 2020 11:46:40 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 1F5638EE112; Sat, 5 Sep 2020 08:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1599320799; bh=uuZwcuWqye3Jc50GpB/RasDOKF7Bok/BlMWQ3nC8shA=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=IPcOeu/nD8EEaTOanrSjdimEprZPoxMXq+HbxBPlWLjLXBUHVzSjaXACgrHe+4Jy+ aEA8fhvxKFQjuoWylT7lwvB4zCsht2sCqNnw4bvED9g5hxODMpsg6k6iUFJm9jkS/4 5M0Ug4oKqKBSUPmoEbfMV2wu4jr7PzXO8iFTOkD0= Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRcJOAM4hkOC; Sat, 5 Sep 2020 08:46:38 -0700 (PDT) Received: from [153.66.254.174] (c-73-35-198-56.hsd1.wa.comcast.net [73.35.198.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id C87418EE100; Sat, 5 Sep 2020 08:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1599320798; bh=uuZwcuWqye3Jc50GpB/RasDOKF7Bok/BlMWQ3nC8shA=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=mke0N8GmVsaGqDCnDo1Xevave0JV+Ok2cWL6w8idVDY1Ot0Fj/AbNErCQQRg3ESYs 3jgSfrtRZagN7f0a8PfMR2oRtAz3nSfMt+fuXzkKruqdGOJlDSNW72Stg7HclqO/N+ JuyCutuhMmqqeGaf7bkGnnUGnkZe/XQ336n3uKRs= Message-ID: <1599320796.11726.5.camel@HansenPartnership.com> Subject: Re: [PATCH] dma-direct: zero out DMA_ATTR_NO_KERNEL_MAPPING buf From: James Bottomley To: Hillf Danton Cc: Christoph Hellwig , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Kees Cook , Matthew Wilcox , Marek Szyprowski , linux-arch@vger.kernel.come Date: Sat, 05 Sep 2020 08:46:36 -0700 In-Reply-To: <20200905073528.9464-1-hdanton@sina.com> References: <20200904152550.17964-1-hdanton@sina.com> <20200905073528.9464-1-hdanton@sina.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > > Cc: Matthew Wilcox > > > Cc: Marek Szyprowski > > > Cc: James Bottomley > > > Signed-off-by: Hillf Danton > > > --- > > > > > > --- 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. > > 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. James