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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBAB3C388F9 for ; Thu, 19 Nov 2020 19:10:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4985B208D5 for ; Thu, 19 Nov 2020 19:10:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="FU/TB9NK"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="cqA167oJ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727863AbgKSTKt (ORCPT ); Thu, 19 Nov 2020 14:10:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727240AbgKSTKt (ORCPT ); Thu, 19 Nov 2020 14:10:49 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E45DCC0613CF for ; Thu, 19 Nov 2020 11:10:48 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1605813047; 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=fqTlt+xmV+wxcpS5yo4wjoab1yCJzP8iG04Acn2vaKA=; b=FU/TB9NKttAWjhk1K07OlHEPQFhYFoPYGEZ0DUIdWthJ5rznjwFWEBmTm0IfmPzdJmG0hj eTGegEMk8exhni9N1UsGdF4oWrTgABHv8n1r00A9iRVn5UGkrzlSDRraZ4WQo0sqzpetZr NCC6B9cCNRd1vRenYoGyrO/ajGEVpc3lWMtxl6n5Iooeu8f5Mr79U76x/fdmhC9k6YqP2e iVcvbNf+7CLE8xuXHm4mX/9ymp7ipU07ju96haHsNaXmVOsCxJ0ipN9R9sHSv5eGeCaiX3 2v3Yy7vm4oA/AS+W8Sg4WDnwtmKzuU7l/a1VSN1Z/EVfgANqh2ymSopry+mRcg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1605813047; 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=fqTlt+xmV+wxcpS5yo4wjoab1yCJzP8iG04Acn2vaKA=; b=cqA167oJl8YpjT3h2H01mJN4qfrIVA7UJcPEWlupJM+9T0y03BkbkNla3eZmyK4rxX1qmk FUoi/S1jlPi7kHBw== To: Alexandre Chartre , Andy Lutomirski Cc: Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , X86 ML , Dave Hansen , Peter Zijlstra , LKML , Tom Lendacky , Joerg Roedel , Konrad Rzeszutek Wilk , jan.setjeeilers@oracle.com, Junaid Shahid , oweisse@google.com, Mike Rapoport , Alexander Graf , mgross@linux.intel.com, kuzuno@gmail.com Subject: Re: [RFC][PATCH v2 12/21] x86/pti: Use PTI stack instead of trampoline stack In-Reply-To: References: <20201116144757.1920077-1-alexandre.chartre@oracle.com> <20201116144757.1920077-13-alexandre.chartre@oracle.com> Date: Thu, 19 Nov 2020 20:10:46 +0100 Message-ID: <87ft55p3gp.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 16 2020 at 19:10, Alexandre Chartre wrote: > On 11/16/20 5:57 PM, Andy Lutomirski wrote: >> On Mon, Nov 16, 2020 at 6:47 AM Alexandre Chartre >> wrote: > When executing more code in the kernel, we are likely to reach a point > where we need to sleep while we are using the user page-table, so we need > to be using a per-thread stack. > >> I can't immediately evaluate how nasty the page table setup is because >> it's not in this patch. > > The page-table is the regular page-table as introduced by PTI. It is just > augmented with a few additional mapping which are in patch 11 (x86/pti: > Extend PTI user mappings). > >> But AFAICS the only thing that this enables is sleeping with user pagetables. > > That's precisely the point, it allows to sleep with the user page-table. Coming late, but this does not make any sense to me. Unless you map most of the kernel into the user page-table sleeping with the user page-table _cannot_ work. And if you do that you broke KPTI. You can neither pick arbitrary points in the C code of an exception handler to switch to the kernel mapping unless you mapped everything which might be touched before that into user space. How is that supposed to work? Thanks, tglx