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 6F614C36002 for ; Wed, 9 Apr 2025 12:18:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AA1A280079; Wed, 9 Apr 2025 08:18:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9308B280068; Wed, 9 Apr 2025 08:18:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A9C2280079; Wed, 9 Apr 2025 08:18:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5A957280068 for ; Wed, 9 Apr 2025 08:18:22 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9695580772 for ; Wed, 9 Apr 2025 12:18:22 +0000 (UTC) X-FDA: 83314408044.01.ED0F1FB Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by imf28.hostedemail.com (Postfix) with ESMTP id B1E72C0011 for ; Wed, 9 Apr 2025 12:18:20 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="D/2DIBZu"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.45 as permitted sender) smtp.mailfrom=ptesarik@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744201100; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Eqdoy4jLnBujLLT1L6bmVqE4A4Fb8dZV88qv7f79rW8=; b=DVBbgXE3+1E0pQITbU4Z7vKGizMYiD8GozKXgEB4Ma0/q68Mpl82He56PWeDrB/M1WkqSY 5xDarhQhsP16BzH8HtwkBftwTGgBBu99Z/ojl+OjUozNPBYpCF3XcBcim8YRVH3KBWnSsl 5PzqnmYNSZryq4zeDDX83JgyoHZP638= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744201100; a=rsa-sha256; cv=none; b=NR3zx7E8Tw++xuuvXVVQT/MEJidH+PDfkmQeyNIMUP9Hqp9Dn/dQYEl6kyLCqiRt2Mq+xi F5bWxBomaGHqXzDsw/L0XI+1i9fDuDKv+Uw/6MBsSyxpccLt3wIGK3PZidC4Vj1/NO1XIf U+Dasev3IoIYDgWmIUnV560dtOhpCTA= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="D/2DIBZu"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.hostedemail.com: domain of ptesarik@suse.com designates 209.85.128.45 as permitted sender) smtp.mailfrom=ptesarik@suse.com Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-43d0953d3e1so4044255e9.2 for ; Wed, 09 Apr 2025 05:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1744201099; x=1744805899; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Eqdoy4jLnBujLLT1L6bmVqE4A4Fb8dZV88qv7f79rW8=; b=D/2DIBZu3una2h3Cty3Po2C7n2IvqMYqLRey2wZ7hchuYGGwkJdEwv68gsA+yckT/z f5mR07CbGCY23WpR/lLVlkUzOL4e2P2Z0oM7hCVAFs1xRc3rce/kplZ6dtwwS5FdX23A XT0V9PymYcl+tZFFCs8bW1GeCauRXiP/g3rEbygKhkWQyhsteMQVG7AobPJ+JOSxyyx/ Aq6U8+NNyP/1taRyV7Pt3f24Rcyzvwt+J1zx3Y6R5+JYh+5udh64ty5xQFrerU9bkGOz emOU/Dv5iBUxg1srppwpe95Cdq3/kAnACu9dqGM7U8t93z6wVKoOeZwLayXRS7bkSWKJ 4Dqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744201099; x=1744805899; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Eqdoy4jLnBujLLT1L6bmVqE4A4Fb8dZV88qv7f79rW8=; b=dR51ESMQ9KHmCkpXrl0lsu3KiCF5Mea9b8XWoiBabUSPS8LutWfRonxjF1MVTQ/McZ cOhnUxlObumbyya8n3KJzyb7IaKYGBtY+LLcfKhYWl9ERW/OvboQwxDucpnQQM5Ki8mY gEoi5zQ2ui/Nx7NiXUIRBTvpzE2MlK4O/VhxbmDBS5EG79FlXWrZnnzRsM34EyAcjxTM 1CKaQuIcxV4IuO8ZCC9vhOR4UsBOIkRxp49u7V2ch92m+kiGSYK1dzmKBmEgLWR8JztO 8E4HSXI4DVfGpRqUK+Oi//OyQFuO4K7gj9gONLd3Ek2GNHIIRh2BNAGLUGCVayE8oEJ5 S0Aw== X-Forwarded-Encrypted: i=1; AJvYcCXyyNIfNg9wHcZAYARjdlGPz77XnT8uCJlLkEtGxl4s9OW2O4tKqWnOw9sKPFU1ujpb2hlL6jhXpw==@kvack.org X-Gm-Message-State: AOJu0YzlBqs6NXErh84o6VAQ+plqvO1RV91r1QCdbmk475JqELb1TQfg oKsbYxns3dbA8RU1yZvcJ33naV12o3KxUIkA6t12dAZo+STRf4TLI+x0t3EGLPI= X-Gm-Gg: ASbGncsWGwltjPY2eOlyG43WY/RbbT2mRau322g3TSeXD3D4TLYLAGOhZABGtrd1FHA ys33dXZheNhjqkXT529l4ab+WF3Z6GBm4Slpa3FcynOXz4KCBEx97WMNts/6OlHLzcBqq3Ve680 zMSsREsQ3rGzVyk82P13fnQ6Nn1Ykl8ZjVcpKtSM+WAPtGa9oDTECh/6Rbcs6+dBuB6V8v3+OQv uBLpdkjrjgr2U2ZcIG3hChikR42nfTj2HHTtuVR+uGNFaHFXFsH/Bsvc1i6ADj3C5erVA6MWowT v2L650isyztCbyujm2KGQ9kmgXQ4qT6qi9PM3Nmd/XwqCavXD19yarGkgi2DhwI6Z3AhEqBLH3+ w5yWctzQhDhgj/xgxiME9SbARFpDT0mngL5Gxmg/C X-Google-Smtp-Source: AGHT+IGzVXpUXEd2DM/H6JBtFIySwk5n3FNCS9WluA0iaZqzb1c1OGB3jzX2eGzjUs9G8Ry4NdPDQw== X-Received: by 2002:a05:600c:4f09:b0:43b:c844:a4ba with SMTP id 5b1f17b1804b1-43f1ecac8b7mr8884475e9.3.1744201098997; Wed, 09 Apr 2025 05:18:18 -0700 (PDT) Received: from mordecai (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43f2066d26bsm18668065e9.22.2025.04.09.05.18.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Apr 2025 05:18:18 -0700 (PDT) Date: Wed, 9 Apr 2025 14:18:16 +0200 From: Petr Tesarik To: Catalin Marinas 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: <20250409141816.1046889f@mordecai> In-Reply-To: References: <20250404155303.2e0cdd27@mordecai> <39657cf9-e24d-4b85-9773-45fe26dd16ae@suse.cz> <20250408072732.32db7809@mordecai> <20250409103904.54a19faa@mordecai> <20250409110529.3ad65b3c@mordecai> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.48; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B1E72C0011 X-Stat-Signature: 5zqnuzkm8w95pzdoi183cqp4hn6uaaas X-Rspam-User: X-HE-Tag: 1744201100-412418 X-HE-Meta: U2FsdGVkX19RbOG/G2AhefWRDcR6IjLC6nuY8X85MV58K+FDXGIBm/8QIrMdsZS61wf21wVK14YrCMwnM49tq4Xi2/Q8h+5C2FXIf58nfwMJtcLt/4sXUNjxSqPUAKAZiRrbincOLnj3fEmeKQ6m1/cfYTCMlhExfS5z1GKXS14ndHsMYUOPzyw0Yupd0A5uDE1oo7Fy6d+yHZ/ZebOOuW98mAGq79asRZ5gE/6Sumdu6s1NQjHgFIeCMdSb2dGQFUzyaHjS95Qg3e7CbcVDtpMP11/oKRS4YU8vkiRICmFxIABF7RUvmlQ0b8Hqml/qmWpTYxmm7NRv8CHsCcvzTCPi4OohJnGR3njHy5bmamvzOWHLFK4ytufvl7NzevN6BtuQVgkVdRq1MBzJuMsINPO7NK81eNqVM2nxfUPVMn9p4Iv/KBoaCHgUuLWnxaKtN7+mgTV8/sqNic/nsFuMGFj2lPr5evktgV6SFpmqCnIrvkDpcNFjCXdKV1w3JrK1aGkRL2OEVfHTjiXykpAPB8DKRlp3Jz+c1BLc3Wd3BYH4YOAhD+5sBiu8LSKDYkRt5ph/e2oAoyK0VKrVNTK6wq+qI9+VU9uLSgm9OjQdUaMS05uCOIfvhFiO0EsAvi0RmiNUCgKgelYgmtIvqhE+pWPPO3xP0NOd4VTY7DHnUj/IrMDOX+sFuPAFeQjE6kdhYMKf2pDRKnfplJUH8eCKHH4simu5f3+/krROcDmAoNapOWfa6V09TzNF0QJ9QtX9hbxdfy+CrVhBgwa2erJiFupKx0QyrmDRbvzFNUlTpqSf+F6jGS8tLldGuIY0qxa7Qgy67YXBRpn31ek4UR/SwsRLkwl0IBx8MaqmSem25+KWBD9VECKiHeh/C4Yfi2Y2jV3Lfutyh6Wybzp8buihL4Td4749Yk3NX+Y0eVDkRDX3jpGXn8rWghuxB7WDF+Ay+pg0zNY6ZhNbs23z6M3 48dBXHId 3sn1cAIZt+Z3HpeaJsktvpOX9ZpZ872ZcGqwogX5XyegApkIEhhpYIvk44Czv+fx7UjV6jBLRYrMrj9MUAzOea+lyhw== 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, 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. ;-) 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(). Unless you are aware of such combination, I suggest to kill the parameter and implement the "anything else" case above for all architectures. Petr T