Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3228942pxb; Mon, 16 Nov 2020 08:59:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJxZ5qzNUi8PNy8IDSACh64AH1SLHS71AbugrvQdQNUKcM2cxz6W0LKr4q12DFp2ChGb2eDO X-Received: by 2002:a17:906:26c2:: with SMTP id u2mr14903413ejc.529.1605545997116; Mon, 16 Nov 2020 08:59:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605545997; cv=none; d=google.com; s=arc-20160816; b=N55vj5WSZupRAM80avZyUCciN2FbsK9h3jDGvgFVngzqdTyKRBkdc1gcNTCn/Ez51S mOf+Fz38F0EqoW4pEtyv4J6o/01b/rb1RZJMlrN2I5M8triL/iYhROIZxiNFb2y1JJLa Za+J+qcTUqU2AcsNHvQTcb5Y8ohWj+JGpQpOiHffiupSN63sbCPbbZlrjPiHAAyjr/+Z rZh4kiCmofMsN9PL7kJW3YR1sHfWcYrqAclWGRhdp/PZaKCKOqgwo9W9M8oOIJLcVGN3 YQED+4iogCn2ku1jPLT1+OnBOIS5mE1mVUckEzqJRxskWFOBV2PZeEfIf9OXURRHvK9c fdoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=9a1yjpmsfK74jJv+j66imm63+1J+eEjv5R85vHqHuyE=; b=03H7YhJyzo9Tr7XOixMzYXgBhHA+DgDLTU+tPLQXUbsFDX29ZkH/ezOqh9yxMoBzgS OEPmRe/rks4EP6+yp/gseMWUZlXPRG9IxNxv6u6cVqUfZsTB/MkwOjcRcVGQlSWxBJoN gYvTQFu2UY9Hp78v9E22HhIuqY/oB9BMjBgfuu46zMuRRRDCcAOlQu9CEddWmze7XK72 BetN53iwaYgbN1cXUzHxj64DU1QIyppV1cRkiwKam14X99doxHtTeVFQXNLiiaf7URui O5oXNXnDKgNfRum4wmUr6Y6TQKNkLzHqeSc3m95kb6m79lSC+19/F2E7kuzkfMUd7D0D AyEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=gvFCS4M0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hh23si11733440ejb.752.2020.11.16.08.59.34; Mon, 16 Nov 2020 08:59:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=gvFCS4M0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732344AbgKPQ43 (ORCPT + 99 others); Mon, 16 Nov 2020 11:56:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:35896 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729841AbgKPQ43 (ORCPT ); Mon, 16 Nov 2020 11:56:29 -0500 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 7347222314 for ; Mon, 16 Nov 2020 16:56:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605545788; bh=VmJiVNqZJbVKwffI9xWkUt7jsOnWbxcfYoKiArMJAS8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gvFCS4M0xiGbdy5stjQuUHnrSbHAgJP32jUoz64+EbPi0FYUVM74KzpaVjLSvXDZx tvtNiPwlPzc+rY/ER5kGFL17uksTXLi3tCYRJ/7yau9VZSZ8w7kLb/Yp9Ys9WzGulu LM/9on9c7omar4/aDPSxdPO3SQAxnR+N2P4FBJrU= Received: by mail-wm1-f54.google.com with SMTP id p19so299438wmg.0 for ; Mon, 16 Nov 2020 08:56:28 -0800 (PST) X-Gm-Message-State: AOAM532IP5wG24Smiym1JVsVXt+6/ANwI1OlwKz2IXXEl/HVtjWqNlmj dkVT8ILsjAT937LMHImcA/a8Aw5f3c3/LcAFIIeoGw== X-Received: by 2002:a7b:c195:: with SMTP id y21mr16627031wmi.138.1605545786993; Mon, 16 Nov 2020 08:56:26 -0800 (PST) MIME-Version: 1.0 References: <20201116144757.1920077-1-alexandre.chartre@oracle.com> <20201116144757.1920077-22-alexandre.chartre@oracle.com> In-Reply-To: <20201116144757.1920077-22-alexandre.chartre@oracle.com> From: Andy Lutomirski Date: Mon, 16 Nov 2020 08:56:13 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH v2 21/21] x86/pti: Use a different stack canary with the user and kernel page-table To: Alexandre Chartre Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , X86 ML , Dave Hansen , Andrew Lutomirski , 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 6:48 AM Alexandre Chartre wrote: > > Using stack protector requires the stack canary to be mapped into > the current page-table. Now that the page-table switch between the > user and kernel page-table is deferred to C code, stack protector can > be used while the user page-table is active and so the stack canary > is mapped into the user page-table. > > To prevent leaking the stack canary used with the kernel page-table, > use a different canary with the user and kernel page-table. The stack > canary is changed when switching the page-table. Unless I've missed something, this doesn't have the security properties we want. One CPU can be executing with kernel CR3, and another CPU can read the stack canary using Meltdown. I think that doing this safely requires mapping a different page with the stack canary in the two pagetables.