From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A93E4483AA for ; Wed, 15 Jul 2026 11:22:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784114560; cv=none; b=PmT+51nuYwX32ia14L+8veoP2K9/AJt0mZYU38GaRIah4RypiSl5ZMcirsWSmYPGak9jZ7zL1IhIcGH9jIuItszw2KyVc8ibA/wEora6AOiTAwvLEaDEiqjygrPxjTI9UKvEZ7uRR9nY7t9GjMzN1rlUKblfGwjIrJ5VLxPDYps= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784114560; c=relaxed/simple; bh=tHMYdwKk1g/vZUdi/98WLI5zFdqna7NONLLcf4ESMlk=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=mO9WAX1j6Cl2ucIb/TSo98rTra2RVxzf0LTttVb8Z9UDtvsTiHoxix4nsgI8SbvCJZ7D23P9Z/XpoP1Uf2IgY6n3cvC7kWsPOT2QpUfbdyn6AMc33U5MK9ZFGeNc75KBGWwAa/4LuKgb+Hh6e6A2XugyiVdJSHlRaS9TGB7TAlM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=u29GFpsZ; arc=none smtp.client-ip=91.218.175.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="u29GFpsZ" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784114555; h=from:from: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; bh=xzse005bRK2beF4axCqwSeS3nY/Hievh0FGpo5JbUqE=; b=u29GFpsZPTVPLgktNR0g+QLd237hye/AUK+IfIMVJB4Z63V1UVaP983BXy/sk3KjtdfDgq SMtP/MHsVGi9w7wkqmd4X0qYqgqnAjm17ma9mJBafVLVCkuy/flWiIx2gRe+MCp6sx6sxK 8ypyz8fSPE+VJ2wQMO3fAt7UbGRx9kk= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 15 Jul 2026 11:22:33 +0000 Message-Id: X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Brendan Jackman" To: "David Hildenbrand (Arm)" , "Mike Rapoport" , "Brendan Jackman" Cc: "Andrew Morton" , "Brendan Jackman" , "Lorenzo Stoakes" , "Liam R. Howlett" , "Vlastimil Babka" , "Suren Baghdasaryan" , "Michal Hocko" , , Subject: Re: [PATCH] mm/secretmem: disable under HIGHMEM References: <20260703-secretmem-highmem-v1-1-30d5ff944664@google.com> <20260704192603.40aa80cf9242b77aa75e8d8d@linux-foundation.org> <503aee9e-97fc-4889-a379-3c0a5d140554@kernel.org> In-Reply-To: <503aee9e-97fc-4889-a379-3c0a5d140554@kernel.org> X-Migadu-Flow: FLOW_OUT On Mon Jul 6, 2026 at 8:42 AM UTC, David Hildenbrand (Arm) wrote: > On 7/5/26 13:34, Mike Rapoport wrote: >> On Sun, Jul 05, 2026 at 10:46:19AM +0000, Brendan Jackman wrote: >>> On Sun Jul 5, 2026 at 2:26 AM UTC, Andrew Morton wrote: >>>> >>>> Well OK, but the secretmem code is still wrong. The patch protects >>>> people from hitting the bug but leaves the bug in place. Surely it wo= uld be >>>> better to fix the bug? >>> >>> I don't think the code is wrong if highmem is disabled. Certainly >>> there is an implicit coupling between the .c file and the Kconfig file, >>> but we could always add a BUILD_BUG_ON(IS_ENABLED(CONFIG_SECRETMEM)) to >>> the relevant bit of code to make it explicit. >>> >>>> Is that as simple as adding the folio_test_highmem() test? =20 >>> >>> This would fix the WARN+SIGBUS but I don't think it resolves the fact >>> that this configuration is completely untested - there are likely other >>> functional bugs? But more importantly, I am not sure if secretmem >>> actually does its security job if kmap_local_page() isn't a NOP. I >>> think shipping a "security feature" that doesn't do what it says would >>> be really terrible. (It might work totally fine, I dunno, but it would >>> require some research and deep thinking that I don't really want to do >>> for a configuration with no users). >>> >>>> Or switching to GFP_KERNEL? =20 >>> >>> ... Oh, that's a nice idea though :) >>=20 >> GFP_USER if anything :) > > Right. > >>=20 >> But still with kmap() and friends not being an NOP the promise "kernel d= oes >> not map this memory" does not hold. >>=20 >> I think that keeping SECRETMEM and HIGHMEM mutually exclusive is >> conceptually correct. > > We could even limit it to 64BIT ;) I fear this in limbo, we have quite a wide range of opinions from "fix the broken configuration" all the way to "disable secretmem completely on 32bit". I'm not passionately committed to any one answer but I do think we need to pick something. Mike's position seems to be roughly "in the middle" of the spectrum, and (conveniently for me) happens to align with what I did in the [PATCH]. So... could we go ahead with this?