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 9F41EC0219B for ; Tue, 11 Feb 2025 16:10:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CADB280007; Tue, 11 Feb 2025 11:10:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 05160280001; Tue, 11 Feb 2025 11:10:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0E23280007; Tue, 11 Feb 2025 11:10:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BFD3E280001 for ; Tue, 11 Feb 2025 11:10:46 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 855D0AD7DD for ; Tue, 11 Feb 2025 16:10:46 +0000 (UTC) X-FDA: 83108152092.30.88DA683 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 01C3640011 for ; Tue, 11 Feb 2025 16:10:43 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=i1HUBeyt; spf=pass (imf07.hostedemail.com: domain of vschneid@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739290244; 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:dkim-signature; bh=DkXKKRZIZ3B6nMXAUQwqba2hAbiJWDhaRaBNOU6/fJw=; b=G7/JuCk1UaakQc6tdtM3gXBbiROtdZISc/UFsRTYXoc1cvLgHVcHZEypMHA+rCsCxYgTYI bvyCO/IxwQhW7qPmbD8wx8h6xnbDa0vrNVhfpSC+wKKIkl8jZe63N55G/e1CiSltTw8fsk 2kSyeiQ1FsG6/tNcB+X0UieVLuG44no= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=i1HUBeyt; spf=pass (imf07.hostedemail.com: domain of vschneid@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739290244; a=rsa-sha256; cv=none; b=phBk16RDNZpb161KLxXo3medNwEdRATOWZI1bxX/H2d0yl2V/ranUKqY//Cw0zWOeVGZr0 yI70/tIknNjnI1oh5b0+MGzigRkuq0rRQFbA0JPUpd+/K2eG4SnIS97hpNqxP8Ce2cnTM1 xWe/2STq0CRSNz/bHkIn+b5F3Yrl5Ig= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739290243; 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: in-reply-to:in-reply-to:references:references; bh=DkXKKRZIZ3B6nMXAUQwqba2hAbiJWDhaRaBNOU6/fJw=; b=i1HUBeytVZQfuTjrexbgjP7YEuXhfQTbb6pRe91MQPsrHrNvdDzSOfyC/EERd6n8ZWPDjF +lZ5tsIl54r4itAaxVJ7JLggTgV7punI/95D8cHSFkAUzbdWyJUgYCJxsfKBbdpQAXbDp7 n1YwDMda2zzuC6MFCw8XkhNYDMwIpOc= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-632-iSVc-8FuPW-EB2X111S0PQ-1; Tue, 11 Feb 2025 11:10:42 -0500 X-MC-Unique: iSVc-8FuPW-EB2X111S0PQ-1 X-Mimecast-MFC-AGG-ID: iSVc-8FuPW-EB2X111S0PQ Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4393ed818ccso19010975e9.3 for ; Tue, 11 Feb 2025 08:10:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739290241; x=1739895041; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DkXKKRZIZ3B6nMXAUQwqba2hAbiJWDhaRaBNOU6/fJw=; b=aa8z2otMTD7u1mFmL1eDuGTKVntEvh79xFLNxKARKAtv2cnLrt2JfI1OwGdqmGQi+c wH5xTNIQIt5m6JSWIBEawarQ9nOEGnwiJNuv8nR8esuGY8JsF5AW55tzMBrhkMSr9G1i 3o2Y8fw9J75CuoEdwdJVhgpwL5rxbpTkI5Lv0a3cVCg4hX2U9x44kvHBmojqZc1fv6K3 EbZqEtOEajBqwhr8Q6UKCVRuXet76LigbadmSSN0YH+w2qSetyPqrSw9xhMpmVOLKIGG TOMQZoZhAK1FdojBIrZxaW+OtGX3TKu6jDdd53dQslMotoS7YHi730Q5RxrZISiXzmZT SSqA== X-Forwarded-Encrypted: i=1; AJvYcCXCEXYN74AdjY8C7mVhqNn02VMa1qTCBCSLXc4+PeBjoYCZ5qks4fHCbZxBRVFSJDPCxU2YYPsdyA==@kvack.org X-Gm-Message-State: AOJu0YzufBnvGmOc5JGfZfWb6imkQxI5hK29TeHohnPH1wZV0ZcOg1Zw LMlUxs4YUztjIiSTD/+By+7MjmFwV1aiVjpnqjlGjeNeCx5m6DoRVR0bYJ2uTXIEyTVR8O4MAuK Xpnk8CbbdHxEZ2qvS7gc/mg5HN0syjjV856TTrjCl5FSwVKw5 X-Gm-Gg: ASbGncszk3ML8RTmdfzMSYjlrbcek9j4OkDbdL+aHt9i+R++4+SaSwt1cbu+n4vi7Ru wzZ8KphpQhj6ZUhgXmKm6KFizKjM8WIb9p1ElZE7bpe0NO0SLCxSfddLmYcCrNuaHcXX5Lx2W6f m1dWjqLuv9uXoe4CUJq5Vko4HUX8+LmKIY/nxmtM9CW3RPJeGB2c4nXhYAriq1JNIQA//FMuyWc SJEradvTrf++WVG4imSu2YSz/JIrRIr51aN7Faw3F/gCYQGB9KtxqHNzdrHCi7vF97z0zN8egRd yDRD3cRkRkBgRe7CQ7ZQx/fXTtRK9VMRIv1tiD3xCrtKhbuEl5YYfZUpBBAKQfNk8A== X-Received: by 2002:a05:600c:500b:b0:439:48d9:d8b0 with SMTP id 5b1f17b1804b1-43948d9dd41mr73108495e9.16.1739290240845; Tue, 11 Feb 2025 08:10:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IGxNXfn5PLr2I3O9shVB9BLvMIo6l6XNn4GHuv5+NRtXPlNDWEKqGeQnOp/tv15slnT46loqA== X-Received: by 2002:a05:600c:500b:b0:439:48d9:d8b0 with SMTP id 5b1f17b1804b1-43948d9dd41mr73107295e9.16.1739290240325; Tue, 11 Feb 2025 08:10:40 -0800 (PST) Received: from vschneid-thinkpadt14sgen2i.remote.csb (213-44-141-166.abo.bbox.fr. [213.44.141.166]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38dc9ef8ac6sm12561610f8f.27.2025.02.11.08.10.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2025 08:10:39 -0800 (PST) From: Valentin Schneider To: Dave Hansen , Jann Horn Cc: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, Juergen Gross , Ajay Kaher , Alexey Makhalov , Russell King , Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , "Liang, Kan" , Boris Ostrovsky , Josh Poimboeuf , Pawan Gupta , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Arnd Bergmann , Frederic Weisbecker , "Paul E. McKenney" , Jason Baron , Steven Rostedt , Ard Biesheuvel , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Uladzislau Rezki , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juri Lelli , Clark Williams , Yair Podemsky , Tomas Glozar , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Kees Cook , Andrew Morton , Christoph Hellwig , Shuah Khan , Sami Tolvanen , Miguel Ojeda , Alice Ryhl , "Mike Rapoport (Microsoft)" , Samuel Holland , Rong Xu , Nicolas Saenz Julienne , Geert Uytterhoeven , Yosry Ahmed , "Kirill A. Shutemov" , "Masami Hiramatsu (Google)" , Jinghao Jia , Luis Chamberlain , Randy Dunlap , Tiezhu Yang Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs In-Reply-To: <352317e3-c7dc-43b4-b4cb-9644489318d0@intel.com> References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-30-vschneid@redhat.com> <352317e3-c7dc-43b4-b4cb-9644489318d0@intel.com> Date: Tue, 11 Feb 2025 17:10:36 +0100 Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: JuZVxKomHCq5JcnE7SWi5zYHpurhnu-3I3dZAE2lbR0_1739290241 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 01C3640011 X-Stat-Signature: qwxby3e48tiqhn19q185qcpzr7edzuz4 X-HE-Tag: 1739290243-668841 X-HE-Meta: U2FsdGVkX195lsRflUacVWvc710+FrDVi19mvQQAcEbBQbcGSOt88rbQTkdv8NHpMQb/tELXwyCTQfKczh/ewy+N7tlpPVA26X483hry5udhk9B5+mppRVkl4FbAY3JliNUoTVR2fzDTjM6ubUFGtPu36IAg6booLVbJEQF8aCjd7jOjyiK77AgpVMP1xlAVc+c7nzvlqeiSNRmwEr6FyWV2I9+JRa4dZz2KkPAfed6HWnS7tns9B5S9aWMPJEWYYGbs9pg8HxZKrMHQPJ7B5Qhm/v46BjMjxxJs5FXoD+KTHdxZcD7pwVYOL5FZ6IZ03s/Qs02FkKadlB5YwasTGHBDgYW9kvT+hnz64eJ//ErVFa7tWGHwVb+jLXkvNXvfLuhkWPr4WpP9Tmvy/JR4V6CUMKLGLMCbjnIbrk9yr6wqMlnztLdhEusqPf1IrQluTLa+snlKSnS0KwNBdAjnKzEvvesdRk/ipNGmhXmhWTIig2VDK4M/dtZgcCj417o7Jh60KotPR5CfHmHizbCXrjud2EGaoQcFmBtxgq383k7p5XnHxrTiGPolEIUZPf87WPuRx+yNIAmBKK5mRhXhvx9FFdEGjnwbioClqSOk5jsych5RT2KLx27lCo1HKGABalpbZ/cke5gEAKIqbRPsnNpa9Mpc2q2FRNrI/WZ8E33vEBv/YoZ4x8s8PHcXIHP8opLbRvwI9X4fZ6L0dzIdCkfeIvAKn8X87jMd7oZXzdwk3NkxNVomv9lR3Ob1qUsaO7Xh1+lq98AprEuK9WAlp6IZ/M+TBeTlUD7VJyPxNOc5g9hN03GGpyG6Fdrx3kmFt4scw3kblycyJMkSiomWbOZ70fKmk13FLKWq9FKONICBjoR7XqQEIUr6pfNX9Icb5Op2r5LcInKGDgFh6RlPFbi9jHKqPfvYVzoudbfyP8X1kEyROSTn6vPPB8YSoIFFIa/ALhQe9kfGRDQk7LA U8wjyOHy hkSVkg4qXnsQiBTwJ32z+loc8rCSwjs9uGRxTuW3dJ1PP13jEj95dz4i15lFnGU2C9el4fPjC/yFr4ZDwZYuPfE54Te/irssPx/b5UVg3vgdazHtTuCW9dulaNU1JvFaXESbtwrGc8h1STzEpl8z2N/8d7L8ihP23BUcrTd3bipr9atJFqfzrIqYBTaKSxtfNfEiSESXCikunXfAtsOqLJVksK28t63sNca6V3WBCCNbN8BO0XIZGMzZvJxyO5tTnKSWj6c0gN1p/q5NrA057ktAZhArz4uthWcggr+vfuSoqH8717vM22vg4bANDGZkVZnbTXSug9mT15oFWMNyGniepAxBPx/F0h9vEFOPa6aCg9TuPIQRNHQxcY0lJA2QguxFdC8DHv8sZMk249eSFfMxZ/b2Oj4dwt/RV9d6lD33Tlqw= 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 11/02/25 06:22, Dave Hansen wrote: > On 2/11/25 05:33, Valentin Schneider wrote: >>> 2. It's wrong to assume that TLB entries are only populated for >>> addresses you access - thanks to speculative execution, you have to >>> assume that the CPU might be populating random TLB entries all over >>> the place. >> Gotta love speculation. Now it is supposed to be limited to genuinely >> accessible data & code, right? Say theoretically we have a full TLBi as >> literally the last thing before doing the return-to-userspace, speculation >> should be limited to executing maybe bits of the return-from-userspace >> code? > > In practice, it's mostly limited like that. > > Architecturally, there are no promises from the CPU. It is within its > rights to cache anything from the page tables at any time. If it's in > the CR3 tree, it's fair game. > >> Furthermore, I would hope that once a CPU is executing in userspace, it's >> not going to populate the TLB with kernel address translations - AIUI the >> whole vulnerability mitigation debacle was about preventing this sort of >> thing. > > Nope, unfortunately. There's two big exception to this. First, "implicit > supervisor-mode accesses". There are structures for which the CPU gets a > virtual address and accesses it even while userspace is running. The LDT > and GDT are the most obvious examples, but there are some less > ubiquitous ones like the buffers for PEBS events. > > Second, remember that user versus supervisor is determined *BY* the page > tables. Before Linear Address Space Separation (LASS), all virtual > memory accesses walk the page tables, even userspace accesses to kernel > addresses. The User/Supervisor bit is *in* the page tables, of course. > > A userspace access to a kernel address results in a page walk and the > CPU is completely free to cache all or part of that page walk. A > Meltdown-style _speculative_ userspace access to kernel memory won't > generate a fault either. It won't leak data like it used to, of course, > but it can still walk the page tables. That's one reason LASS is needed. Bummer, now I have at least two architectures proving me wrong :-) Thank you as well for the education, I really appreciate it.