From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 17E55376A09 for ; Sun, 5 Jul 2026 11:34:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783251300; cv=none; b=hDbxV4+m0mvsESt/6MBjmOoSO7VhuPD6rdwxY4zabypiD6gaGrh6I6YW89PjxW78H/eQXGCu2Ih+Y+OpBs3AZ3Ef4zPVub6wQmLaL58PMpICpyQ2NneM4b6h+fcIfPkQHHOhEZ6AG9u3j6mrQIzW6FRe3BWndxECtQl7pQR4QIU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783251300; c=relaxed/simple; bh=Toz1nI9STW3sJDpnzzWMPLZpxxB1xZVygbwgeLWJCBE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XdD2eIGO6OP7ZqW168O4cm+FVL82UPv1XxxHQ2Znw/+Fy0AH8Pl+nKWjfJuYGI/1P5ZfiwANvMvHyfWxne56orMbuOfNLBctxCN1JWrnECXZJa6WNN5MIjjqd1Er2NcPaowGb6ExLjzoBtIjEOcqq9DVwrDyCeHz7LzezglJl3c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nV2g4cTj; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nV2g4cTj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1AF241F000E9; Sun, 5 Jul 2026 11:34:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783251298; bh=a5tukjUWikD+yXvmypS8p+hrJSvR5s26qMGQskWUEKQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=nV2g4cTjYPDzHQbmjJgpTx3yJ9aufUXGyfYJaCKdBvFt1h6DvrlFbl/MnhrZQiFEZ 3dNix56N/U76Co0EvxMMhjFx8cV6XOIaCcwsAwv1mi5Qis4anDQPWFqsHxHRPZh6gT 52wBlT0+Hfv5TM7RXbPKuE4yPGyejZf/+9AbOe2LB+qiCpyVVI+JCc0PyO5//CjAEI lxLKJlZhEsOCujsnKSbqvvR/B6Zu8wyQtuZ1QOUA8IlWeI66qV1MkMN4PDDCoIq9wB Auk/ERaD3iUoXfybs/Ci7a4gCJM/RW68gAquQIZ1YG6mGgKCwWQPOAXoGxrliyG/Kv v7WcmnVFE0uKA== Date: Sun, 5 Jul 2026 14:34:50 +0300 From: Mike Rapoport To: Brendan Jackman Cc: Andrew Morton , Brendan Jackman , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/secretmem: disable under HIGHMEM Message-ID: References: <20260703-secretmem-highmem-v1-1-30d5ff944664@google.com> <20260704192603.40aa80cf9242b77aa75e8d8d@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 would 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? > > 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? > > ... Oh, that's a nice idea though :) GFP_USER if anything :) But still with kmap() and friends not being an NOP the promise "kernel does not map this memory" does not hold. I think that keeping SECRETMEM and HIGHMEM mutually exclusive is conceptually correct. > Any thoughts from Mike on that? I think it might be just as good as this > patch? And then you can still use secretmem reliably on a 32bit build > as long as you have <1G RAM (or whatever the limit is). With <1G RAM there is no need for HIGHMEM :) -- Sincerely yours, Mike.