Received-SPF: pass (google.com: domain of linux-kernel+bounces-99908-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Subject: Re: [RFC 11/14] x86: add support for Dynamic Kernel Stacks
From: Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <11e673cf-8bfa-4493-ab86-2f1f97ddd732@app.fastmail.com>
Date: Tue, 12 Mar 2024 09:20:40 +0200
Cc: Dave Hansen <dave.hansen@intel.com>,
 Pasha Tatashin <pasha.tatashin@soleen.com>,
 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
 linux-mm <linux-mm@kvack.org>,
 Andrew Morton <akpm@linux-foundation.org>,
 the arch/x86 maintainers <x86@kernel.org>,
 Borislav Petkov <bp@alien8.de>,
 Christian Brauner <brauner@kernel.org>,
 Daniel Bristot de Oliveira <bristot@redhat.com>,
 Ben Segall <bsegall@google.com>,
 Dave Hansen <dave.hansen@linux.intel.com>,
 dianders@chromium.org,
 dietmar.eggemann@arm.com,
 eric.devolder@oracle.com,
 Heiko Carstens <hca@linux.ibm.com>,
 "hch@infradead.org" <hch@infradead.org>,
 "H. Peter Anvin" <hpa@zytor.com>,
 Jacob Pan <jacob.jun.pan@linux.intel.com>,
 Jason Gunthorpe <jgg@ziepe.ca>,
 Josh Poimboeuf <jpoimboe@kernel.org>,
 Joerg Roedel <jroedel@suse.de>,
 Juri Lelli <juri.lelli@redhat.com>,
 Kent Overstreet <kent.overstreet@linux.dev>,
 kinseyho@google.com,
 "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
 Lorenzo Stoakes <lstoakes@gmail.com>,
 mgorman@suse.de,
 mic@digikod.net,
 michael.christie@oracle.com,
 Ingo Molnar <mingo@redhat.com>,
 mjguzik@gmail.com,
 "Michael S. Tsirkin" <mst@redhat.com>,
 Nicholas Piggin <npiggin@gmail.com>,
 "Peter Zijlstra (Intel)" <peterz@infradead.org>,
 Petr Mladek <pmladek@suse.com>,
 Rick P Edgecombe <rick.p.edgecombe@intel.com>,
 Steven Rostedt <rostedt@goodmis.org>,
 Suren Baghdasaryan <surenb@google.com>,
 Thomas Gleixner <tglx@linutronix.de>,
 Uladzislau Rezki <urezki@gmail.com>,
 vincent.guittot@linaro.org,
 Valentin Schneider <vschneid@redhat.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <32BCF7CC-CBE8-45AD-B3D8-2856DD4FFF30@gmail.com>
References: <20240311164638.2015063-1-pasha.tatashin@soleen.com>
 <20240311164638.2015063-12-pasha.tatashin@soleen.com>
 <3e180c07-53db-4acb-a75c-1a33447d81af@app.fastmail.com>
 <bedfa55b-b1d0-4e59-8c94-dbc5f8485a7f@intel.com>
 <ef0419dd-9d7b-4b77-b63a-5f11aaefb570@app.fastmail.com>
 <08EFDEDB-7BBB-4D9C-B7E5-D7370EC609BE@gmail.com>
 <11e673cf-8bfa-4493-ab86-2f1f97ddd732@app.fastmail.com>
To: Andy Lutomirski <luto@kernel.org>


> On 12 Mar 2024, at 2:02, Andy Lutomirski <luto@kernel.org> wrote:
>=20
> Doesn't this buy a new problem?  Install a page, run the thread =
without using the page but speculatively load the PTE as read-only into =
the TLB, context-switch out the thread, (entirely safely and correctly) =
determine that the page wasn't used, remove it from the PTE, use it for =
something else and fill it with things that aren't zero, run the thread =
again, and read from it.  Now it has some other thread's data!

Yes, you are correct. Bad idea of mine. Regardless of data leak, it =
opens the door for subtle hard-to-analyze bugs where 2 reads return =
different values.=