Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp992796pxb; Wed, 6 Apr 2022 06:13:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpvJ7WY84D46f/DD0U6NyheR780y/q1jmMZmsCqygNtpdo47d1Ryf+d7HY1NCiBEyoArwn X-Received: by 2002:a17:902:9043:b0:14f:aa08:8497 with SMTP id w3-20020a170902904300b0014faa088497mr8538038plz.109.1649250823622; Wed, 06 Apr 2022 06:13:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649250823; cv=none; d=google.com; s=arc-20160816; b=pQeARBHtKG5R0Uu6HVjxRM8pLsSYvqDovZyRF+cQhGURjwTRVtO0jwobYAIbWTuhsQ 0pZqDLrxPNSmn4YC3UiKIL6PtY5osmfK2NHsDMNNKmN+oLCYTqDPu5MQqfI5x1nlApPa gGojDnIqe2SUP3UGlhXSHgSTmZq06SLvwQb5OgOt8p1iU7oxTF9SVsWq7gaDcT8YHGPv MbSCq48cPp/fzJopGmV+XI8McY5WtOOjG0kWN/2Rqbc1c6+IUyvC5EB4z1x66lEqpJGD l+rF6BT+6R6ijKqiWnEab78CVzx65hmxgwwd52EH7UKlfSzLuCCEBjq+JPvh3qaAPtj6 fkow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=ZfF416q2zlitXyRdRn572WpwOLvAOfD5on68YYwUS4U=; b=ru/n1tf668ssyYNAyNzy281QBAw5IisDAHKfqJSf9NpZLALsdmGU9vTgNkNEKULQ30 PpLNxvdtVFovkonpuKuFtqnl6gGFZdSudlQayBwgTy1tAmjR5GvV5cm5hrLz5SibxdfK mYLuI3i/audtzgh0yBoYLSrvyoPOQ9bPCbgy5UwUP/8njB48WLKCmmvJsJT04ggRd/qE 7xPypUPXdoteFw2MW5u7JPEKahscCfkYiKGmZP6uPIo0Z36LW9BkuibsHV+98SaLMU2L 2dIkBrWbE6kV+yfdt58xdd23lEntNNiTEUY73ovyIjye+T/rtuN8vrmcS5OZ6XYgtFkl FtdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=X84JRmiE; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id b14-20020a056a000cce00b004fa3a8e001bsi17008563pfv.210.2022.04.06.06.13.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 06:13:43 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=X84JRmiE; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A033C4FA783; Wed, 6 Apr 2022 03:41:15 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1843755AbiDFBl6 (ORCPT + 99 others); Tue, 5 Apr 2022 21:41:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45148 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354451AbiDEKOQ (ORCPT ); Tue, 5 Apr 2022 06:14:16 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD4BA69CFE; Tue, 5 Apr 2022 03:00:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 854FBB81C98; Tue, 5 Apr 2022 10:00:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D30C1C385A2; Tue, 5 Apr 2022 10:00:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649152803; bh=csoXg8xfP54KyRaAROKfOyTrSMX5tlMmyn9Qsmva0YE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X84JRmiEiSGR+s+s9QW/aU+fsP89brgJJh7xSk8AUq5YDEndiCU288tyIuFNXjqRJ 8r52WAyiu5cXxSchjTAo2O47srO4J25exFOONChXQJGePzt55mXe5PNoFOQM0pp9G9 08OS2VxyYu0CDUUA/ZZVoA7qnWvV6kS17cDb/6Ks= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Halil Pasic , Oleksandr Natalenko , Christoph Hellwig , Linus Torvalds Subject: [PATCH 5.15 869/913] Reinstate some of "swiotlb: rework "fix info leak with DMA_FROM_DEVICE"" Date: Tue, 5 Apr 2022 09:32:11 +0200 Message-Id: <20220405070405.872766400@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070339.801210740@linuxfoundation.org> References: <20220405070339.801210740@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Linus Torvalds commit 901c7280ca0d5e2b4a8929fbe0bfb007ac2a6544 upstream. Halil Pasic points out [1] that the full revert of that commit (revert in bddac7c1e02b), and that a partial revert that only reverts the problematic case, but still keeps some of the cleanups is probably better.  And that partial revert [2] had already been verified by Oleksandr Natalenko to also fix the issue, I had just missed that in the long discussion. So let's reinstate the cleanups from commit aa6f8dcbab47 ("swiotlb: rework "fix info leak with DMA_FROM_DEVICE""), and effectively only revert the part that caused problems. Link: https://lore.kernel.org/all/20220328013731.017ae3e3.pasic@linux.ibm.com/ [1] Link: https://lore.kernel.org/all/20220324055732.GB12078@lst.de/ [2] Link: https://lore.kernel.org/all/4386660.LvFx2qVVIh@natalenko.name/ [3] Suggested-by: Halil Pasic Tested-by: Oleksandr Natalenko Cc: Christoph Hellwig Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- Documentation/core-api/dma-attributes.rst | 8 -------- include/linux/dma-mapping.h | 8 -------- kernel/dma/swiotlb.c | 12 ++++++++---- 3 files changed, 8 insertions(+), 20 deletions(-) --- a/Documentation/core-api/dma-attributes.rst +++ b/Documentation/core-api/dma-attributes.rst @@ -130,11 +130,3 @@ accesses to DMA buffers in both privileg subsystem that the buffer is fully accessible at the elevated privilege level (and ideally inaccessible or at least read-only at the lesser-privileged levels). - -DMA_ATTR_OVERWRITE ------------------- - -This is a hint to the DMA-mapping subsystem that the device is expected to -overwrite the entire mapped size, thus the caller does not require any of the -previous buffer contents to be preserved. This allows bounce-buffering -implementations to optimise DMA_FROM_DEVICE transfers. --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -62,14 +62,6 @@ #define DMA_ATTR_PRIVILEGED (1UL << 9) /* - * This is a hint to the DMA-mapping subsystem that the device is expected - * to overwrite the entire mapped size, thus the caller does not require any - * of the previous buffer contents to be preserved. This allows - * bounce-buffering implementations to optimise DMA_FROM_DEVICE transfers. - */ -#define DMA_ATTR_OVERWRITE (1UL << 10) - -/* * A dma_addr_t can hold any valid DMA or bus address for the platform. It can * be given to a device to use as a DMA source or target. It is specific to a * given device and there may be a translation between the CPU physical address --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -578,10 +578,14 @@ phys_addr_t swiotlb_tbl_map_single(struc for (i = 0; i < nr_slots(alloc_size + offset); i++) mem->slots[index + i].orig_addr = slot_addr(orig_addr, i); tlb_addr = slot_addr(mem->start, index) + offset; - if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) && - (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE || - dir == DMA_BIDIRECTIONAL)) - swiotlb_bounce(dev, tlb_addr, mapping_size, DMA_TO_DEVICE); + /* + * When dir == DMA_FROM_DEVICE we could omit the copy from the orig + * to the tlb buffer, if we knew for sure the device will + * overwirte the entire current content. But we don't. Thus + * unconditional bounce may prevent leaking swiotlb content (i.e. + * kernel memory) to user-space. + */ + swiotlb_bounce(dev, tlb_addr, mapping_size, DMA_TO_DEVICE); return tlb_addr; }