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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3983C369A1 for ; Wed, 9 Apr 2025 12:49:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 848C028007E; Wed, 9 Apr 2025 08:49:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F6CE28007D; Wed, 9 Apr 2025 08:49:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BED428007E; Wed, 9 Apr 2025 08:49:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4D16328007D for ; Wed, 9 Apr 2025 08:49:56 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6265E120468 for ; Wed, 9 Apr 2025 12:49:56 +0000 (UTC) X-FDA: 83314487592.13.6D3F86D Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf01.hostedemail.com (Postfix) with ESMTP id 8D05A4000D for ; Wed, 9 Apr 2025 12:49:54 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf01.hostedemail.com: domain of cmarinas@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744202994; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x9pwB6DNq/C+QXNn02M6UvLQr3vnh94BbejrMTSvEAc=; b=UupOPPqAnrA6UcyTNqEg7ALIvpAk/YoHQ0opu6TFTHMh+6SjSkw/OfYS46jwlYGXzKOKsv tSUklfuQ6wKasdiUHgtMiUsaBVX5JwaYbqbwK2ipYQxXADJA/kWeLOvW5cFWldGyDLWkEO BLgSYQOMnZN0pgjUqCEerZC1eh31uXw= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf01.hostedemail.com: domain of cmarinas@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744202994; a=rsa-sha256; cv=none; b=enyrqrFO8PDgTUY1Q0DqdYR3u6KCFWHyfikWQHmywabbYYin+WFdEusFVdaUTZyxsVLOaW uq8nceNty0ef6sEhz5PMrtPGMAVxNt3FkmdiIeDib7hKm4VYekOba9P+du4LbHxk+XRT6H clm6c6++OIaiIUkzrr9NapnZq+ssYew= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 41C3043C1B; Wed, 9 Apr 2025 12:49:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B299FC4CEE3; Wed, 9 Apr 2025 12:49:50 +0000 (UTC) Date: Wed, 9 Apr 2025 13:49:48 +0100 From: Catalin Marinas To: Petr Tesarik Cc: Vlastimil Babka , Feng Tang , Harry Yoo , Peng Fan , Hyeonggon Yoo <42.hyeyoo@gmail.com>, David Rientjes , Christoph Lameter , "linux-mm@kvack.org" , Robin Murphy , Sean Christopherson , Halil Pasic Subject: Re: slub - extended kmalloc redzone and dma alignment Message-ID: References: <39657cf9-e24d-4b85-9773-45fe26dd16ae@suse.cz> <20250408072732.32db7809@mordecai> <20250409103904.54a19faa@mordecai> <20250409110529.3ad65b3c@mordecai> <20250409141816.1046889f@mordecai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250409141816.1046889f@mordecai> X-Rspamd-Server: rspam01 X-Stat-Signature: eatfs4xpd3h7btcmd6tudd341zobxem7 X-Rspam-User: X-Rspamd-Queue-Id: 8D05A4000D X-HE-Tag: 1744202994-278089 X-HE-Meta: U2FsdGVkX1+aoblplC0bUKCYJONBqRfAwoqTw+5oul/HP+6SL2TAZm30kwmisBCOiN9Nquy7FtoqOjGtYC4Ayf+fj12qti5lvMoyE1gn9nZOvUfsycL5lW9xQzTJRNRHnnbOjajlNT5lNMUZ4dr45k1r+K1lfdQearYAamHOtwo5AgkhiqwvV2sYOylKNYQQAT8lYTZosYGgtnmgxzXYpPsPKMC7fIfgo9SDcFBtcDSiSa01fcrLVk7V8IbvfrSf/qNsfuasS57o28G01IdNXGhA77jSFmB9Rb38UYA4hZEzKmsvw4cqbUmDKN4e9mIJ7gh+2uRA8L6mch1U8qVhuj+mFbTsfcUYaZWEdj9+1prBf+Szs35s/JcBz6po37p59Y5R62946f/Xz8nlCwHNsjLgSlDqyhCRRLvPn7zj0N2VvEGqMn7x1UqB5wyAMRqZZlvfjQlRAZDzarnKlKXKWr4AZcFPoFm7tA8fSthMtfbdbIzBpIUrSim/QSih/XwSlWdTJUOB8XlrIb6EjvU/9/zJnQLyK/47GPJcfNKEbj1/1CL2UI1S7tzyIOTVb4mdWyEiv00Y4siO2InT48b73PN4gaWmU3oJiGw1D3WiOEMBO4e3CuqsSYceAMU82+LRt7I6b2Dfco0sbZKWMf/nYIN69dEsKx3ffltqW5gmUBqE0beMKCfsgg75u5RFBYCCz/yAYuDVwPew9iDI3GJh2jle93LcGI21zojgcQ2yLF8gqi9OOtfT/yGIcDMsyNgFx+pLLANY/FcAmgIh/xADmSUd3jwlVLPXeWhA03yx+rUf7VpF05gfx72FHGCOMe7mwJy0KhEGIojtGVNN7ioL80yHogegI2zOlA5oDXEhyaHDoXPU3JoegrLKvaMcKQ37LN2rbdyEQXeFrJvMbvYXMs/makf328wzA56p1vfw2kOxhcp8ihpVrMK9VL6zR0LdHPCZypUG6FkQSdXDEVy S097sw6a 4YKw08gmW1AqLNZUgHrh3Hfm2qaEVXnnbWW2EcnmG+mB219IDK6A2c8da+GGgUhrGzh+aWJLfSKtPQ8KXf/HAT/0l2T+SLJYDqYed+gdMx+IIw1PRHOOaNNZDaxRJqh6eyYTDgBvtgGTH7vSGl3RZucuesTgTRydpZi0rlz2EHqzymyPXf3rbBNofJLyw4AN8QTcDMRsqBAiRmbSCptfeRLo0w5KqTR8+774f1TcMbPNzh9M1uNCUzSCQuj76HetRB99BoHU9GbwnYvZYLDFQ4DEzFx81RlCOO7STbip0wXxZ3rhmtKyeCmk9fcx1AmIIsM+3gGKesBO0Oo4yzvvzY5bM3kEmpJy4qQJ9VZllnDIMgWr9DJwKa0NgaF2jBGnAoXGvlGWWaG/PV9mCaX8I/eqPi3zNoskNoPID2irWqNGnXhlACWP09gnU15bwJJMr9EsH1JLinSbSEtaheqaQxkO1b9Zi/TeonoNUQU9zED9Emdzk8xX8DAp72/nu3WSJVbHaR+BbLs2v7i13ZfwBh8pufwBF4H+KLPS5g+cjdbmHN3ATeoxJSILQUmn98+0IGG83OE3biJ9UHvM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Apr 09, 2025 at 02:18:16PM +0200, Petr Tesarik wrote: > On Wed, 9 Apr 2025 10:47:36 +0100 > Catalin Marinas wrote: > > On Wed, Apr 09, 2025 at 11:05:29AM +0200, Petr Tesarik wrote: > > > On Wed, 9 Apr 2025 10:39:04 +0200 > > > Petr Tesarik wrote: > > > > I believe there is potential for a nasty race condition, and maybe even > > > > info leak. Consider this: > > > > > > > > 1. DMA buffer is allocated by kmalloc(). The memory area previously > > > > contained sensitive information, which had been written to main > > > > memory. > > > > 2. The DMA buffer is initialized with zeroes, but this new content > > > > stays in a CPU cache (because this is kernel memory with a write > > > > behind cache policy). > > > > 3. DMA is set up, but nothing is written to main memory by the > > > > bus-mastering device. > > > > 4. The CPU cache line is now discarded in arch_sync_dma_for_cpu(). > > > > > > > > IIUC the zeroes were never written to main memory, and previous content > > > > can now be read by the CPU through the DMA buffer. > > > > > > > > I haven't checked if any architecture is affected, but I strongly > > > > believe that the CPU cache MUST be flushed both before and after the > > > > DMA transfer. Any architecture which does not do it that way should be > > > > fixed. > > > > > > > > Or did I miss a crucial detail (again)? > > > > > > Just after sending this, I realized I did. :( > > > > > > There is a step between 2 and 3: > > > > > > 2a. arch_sync_dma_for_device() invalidates the CPU cache line. > > > Architectures which do not write previous content to main memory > > > effectively undo the zeroing here. > > > > Good point, that's a problem on those architectures that invalidate the > > caches in arch_sync_dma_for_device(). We fixed it for arm64 in 5.19 - > > c50f11c6196f ("arm64: mm: Don't invalidate FROM_DEVICE buffers at start > > of DMA transfer") - for the same reasons, information leak. > > > > So we could ignore all those architectures. If they people complain > > about redzone failures, we can ask them to fix. Well, crude attempt > > below at fixing those. I skipped powerpc and for arch/arm I only > > addressed cache-v7. Completely untested. > > > > But I wonder whether it's easier to fix the callers of > > arch_sync_dma_for_device and always pass DMA_BIDIRECTIONAL for security > > reasons: > > Then we could remove this parameter as useless. ;-) Yes, I just took the lazy approach of not changing the arch code. > Now, arch_sync_for_device() must always do the same thing, regardless > of the transfer direction: Write back any cached DMA buffer data to > main memory. Except, if an architectures can do this with or without > invalidating the cache line _and_ it never loads cache content > speculatively (does not even have a prefetch instruction), it might > optimize like this: > > - DMA_FROM_DEVICE: > - arch_sync_for_device(): writeback and invalidate > - arch_sync_for_cpu(): nothing > > - anythig else: > - arch_sync_for_device(): writeback only > - arch_sync_for_cpu(): invalidate unless DMA_TO_DEVICE > > I don't know if there's any such non-prefetching architecture, much > less if this optimization would make sense there. It's just the only > scenario I can imagine where the direction parameter makes any > difference for arch_sync_for_device(). We have at least some old arm cores (pre ARMv6) that have a no-op for the arch_sync_dma_for_cpu() case. They rely on the for_device code to invalidate the caches. That's why I suggested DMA_BIDIRECTIONAL as a cover-all option. However, such default may affect the performance of CPUs that would benefit from a writeback without invalidate. Basically what we need is something like: if (dir == DMA_TO_DEVICE) dir = DMA_BIDIRECTIONAL; We could hide this in the core DMA code (behind some macro/function) or update the arch code to do this. I don't have the setup to test all of them (I can test arm64, maybe modern arm32 but that's about it). Or we ignore the problem and tell people to fix their DMA ops if they see complains about slab redzones. We also ignore the potential information leak we've had for decades. -- Catalin