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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 74073C388F9 for ; Mon, 16 Nov 2020 23:06:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1BD3A222E8 for ; Mon, 16 Nov 2020 23:06:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="2IOvZZPe" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728639AbgKPXGZ (ORCPT ); Mon, 16 Nov 2020 18:06:25 -0500 Received: from mail.kernel.org ([198.145.29.99]:33152 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725379AbgKPXGY (ORCPT ); Mon, 16 Nov 2020 18:06:24 -0500 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8FEA3241A5 for ; Mon, 16 Nov 2020 23:06:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605567983; bh=0Pqi7azRIWSbLIpOeitvpzKPLJGnjQeCpndMdUmdrAo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=2IOvZZPeGDj+Zct6OlvIZod58PJIp3hy9ZWtyPjPTimvJbBJqiku0bu3pKfw2/M1/ EP2a/7aeAMxXeabBImwfXcm6v+SehUvXkjoVo8wSzxP3eDq3XVahSNr6ha2CyZGNy5 B7Y2QONNejEe08f7hqYXRPS5CrQNPV7hKsfoCuWw= Received: by mail-wm1-f44.google.com with SMTP id p19so837711wmg.0 for ; Mon, 16 Nov 2020 15:06:23 -0800 (PST) X-Gm-Message-State: AOAM531jUcHB9Bzo3kOup5Zca2l9J1sHGRa0FuUAjqsqyWdDByIL1BqL h3n2JJo9/lbaG+kwHNBHa3WvCTuqa7c3Xz/598nc4w== X-Google-Smtp-Source: ABdhPJzaErYYKYPau7kte9K2Eqgjui//v7T+37VcdCsJfQWFo6yKNCo5wdUrCV2Z/NFPrRMrLA8Ahpoyiep2mKeOWO0= X-Received: by 2002:a1c:7e87:: with SMTP id z129mr1136898wmc.176.1605567982035; Mon, 16 Nov 2020 15:06:22 -0800 (PST) MIME-Version: 1.0 References: <20201116144757.1920077-1-alexandre.chartre@oracle.com> <20201116144757.1920077-12-alexandre.chartre@oracle.com> <820278dc-5f8e-6224-71b4-7c61819f68d1@oracle.com> In-Reply-To: <820278dc-5f8e-6224-71b4-7c61819f68d1@oracle.com> From: Andy Lutomirski Date: Mon, 16 Nov 2020 15:06:08 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH v2 11/21] x86/pti: Extend PTI user mappings To: Alexandre Chartre Cc: Andy Lutomirski , Thomas Gleixner , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 16, 2020 at 12:18 PM Alexandre Chartre wrote: > > > On 11/16/20 8:48 PM, Andy Lutomirski wrote: > > On Mon, Nov 16, 2020 at 6:49 AM Alexandre Chartre > > wrote: > >> > >> Extend PTI user mappings so that more kernel entry code can be executed > >> with the user page-table. To do so, we need to map syscall and interrupt > >> entry code, per cpu offsets (__per_cpu_offset, which is used some in > >> entry code), the stack canary, and the PTI stack (which is defined per > >> task). > > > > Does anything unmap the PTI stack? Mapping is easy, and unmapping > > could be a pretty big mess. > > > > No, there's no unmap. The mapping exists as long as the task page-table > does (i.e. as long as the task mm exits). I assume that the task stack > and mm are freed at the same time but that's not something I have checked. > Nope. A multi-threaded mm will free task stacks when the task exits, but the mm may outlive the individual tasks. Additionally, if you allocate page tables as part of mapping PTI stacks, you need to make sure the pagetables are freed. Finally, you need to make sure that the PTI stacks have appropriate guard pages -- just doubling the allocation is not safe enough. My intuition is that this is going to be far more complexity than is justified.