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 AA3E3C433F5 for ; Fri, 13 May 2022 15:28:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DCCFC6B0073; Fri, 13 May 2022 11:28:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D7B798D0001; Fri, 13 May 2022 11:28:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C43706B0078; Fri, 13 May 2022 11:28:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B1B576B0073 for ; Fri, 13 May 2022 11:28:07 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8DA71E8B for ; Fri, 13 May 2022 15:28:07 +0000 (UTC) X-FDA: 79461100614.07.29B8F15 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 800871800DD for ; Fri, 13 May 2022 15:27:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=nJ0dd5dcOSKw4+ESckVZDki1YhEbIEmb3PnEsHXElEA=; b=Wu3k6TdGzaMVnAN+LPCeRXIcKZ diBlUnP56ZiXXCbTyuGJhSUSXTiVp45DqVdHHfmmAYWDH03vo4JuloK3B0g0qcpbDOr9+cH5FLtJF 1NU7KSLBpOu7/Q2Ng1eHIxhNWlTjXyZ/v3KfvnrrN6rfdXSYvpGgpNgnjDN3ALD3J50xZCiei85XH bBRMdHLfVqrUAblS3eKc8uNdkyxWnJ2+nxGkW/iEnaUMDCX17IGXyrJbbBOrX1WNj++jb2N+GcHkG dZp/x+EFos/lm+Eftp53htZOEyMY9txh72gwqpEoJqmQY1ds9LD8+7C546LcKlBC611qJss0tcCEZ h7nnVHZw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1npWVh-007QV9-Er; Fri, 13 May 2022 14:43:17 +0000 Date: Fri, 13 May 2022 15:43:17 +0100 From: Matthew Wilcox To: Thomas Gleixner Cc: Dave Hansen , Peter Zijlstra , "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , x86@kernel.org, Alexander Potapenko , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFCv2 00/10] Linear Address Masking enabling Message-ID: References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511064943.GR76023@worktop.programming.kicks-ass.net> <20bada85-9203-57f4-2502-57a6fd11f3ea@intel.com> <875ymav8ul.ffs@tglx> <87zgjmtpf8.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zgjmtpf8.ffs@tglx> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 800871800DD X-Stat-Signature: dyttm4pwz4jnz3i6k6aby944f3ac3jid Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Wu3k6TdG; dmarc=none; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspam-User: X-HE-Tag: 1652455677-825903 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: On Thu, May 12, 2022 at 11:24:27PM +0200, Thomas Gleixner wrote: > On Thu, May 12 2022 at 21:39, Thomas Gleixner wrote: > > On Thu, May 12 2022 at 10:22, Dave Hansen wrote: > >> One of the stated reasons for adding LAM hardware is that folks want to > >> use sanitizers outside of debugging environments. To me, that means > >> that LAM is something that the same binary might run with or without. > > > > On/off yes, but is there an actual use case where such a mechanism would > > at start time dynamically chose the number of bits? > > This would need cooperation from the application because it has to tell > the magic facility whether it intends to utilize the large VA space on a > 5-level paging system or not. Taking a step back ... Consider an application like 'grep'. It operates on streams of data, and has a fairly bounded amount of virtual memory that it will use. Let's say it's 1GB (*handwave*). So it has 33 bits of address space that it can use for "security" of one form or another. ASLR is one thing which is vying for bits, and now ASAN is another. Somehow it is supposed to tell the kernel "I want to use 6 bits for ASAN and 27 bits for ASLR". Or "I want to use 15 bits for ASAN and 18 bits for ASLR". So how does grep make that decision? How does it find out what the kernel supports? Deciding which tradeoff is more valuable to grep is clearly not something the kernel can help with, but I do think that the kernel needs to have an API to query what's available. Something like Libreoffice or Firefox is obviously going to be much more complex; it doesn't really have a bounded amount of virtual memory to work with. But if we can't even solve this problem for applications with bounded address space, we stand no chance of solving it for hard cases.