Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1202564imm; Wed, 11 Jul 2018 20:02:31 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfGVqof0OJdTBUNLYOPqXyv1RO7rpyyNJ0N/dI3N58yXp2kL1Bc3zS43R/xxD+BIhhAeDqv X-Received: by 2002:a62:ce81:: with SMTP id y123-v6mr482862pfg.95.1531364551738; Wed, 11 Jul 2018 20:02:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531364551; cv=none; d=google.com; s=arc-20160816; b=w6dH1K4SHIhvFRthvQ4us1WIt3d6lpShJuF7WB0KAH97Bi84i9lGrVTo9TCEWFIJLf G7OUkvfdgtR859014PiSkGeYzA1uS80i2h2ctP0jnVmpD7uUCN3xdM0IuNHwvikouo5L kAYXM/L0FNebeF8xdCwUPn2R4RvOPR8UB9jk+Z8lBf50flCk+XOw8m7KFR7YBqsnz1Hz aFmqS3Gd2q8/wxp103s6hEleHOCBqe0IdVi3hYQSD4flP2n05GMaf5NFp6aVjCwjeLlR fwsm/wY/WfFHa3xTwi8HKWuQLiB6IKOTBfLxc7pMOZzIBwPO75+dE9RgwCS+mWXrTEUb YSlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature:arc-authentication-results; bh=NC5Wll+Ta90LWa7k3YHEONHdQo3lP6YNOAIHcaPq1+E=; b=QbH69nEAKmbwSxAIQI2K+PsGWdK8ODSE4LuK6xdT9pGUBwDFB/otsjkvI2DAjkODdW GWVaoWsnnBLGJ8XHtj5ohkBd1PIUXYJSqAc7JpvD9RsrZooGTAV4VqU6cVT/vyyaVG2R ovdJDW1LlkzoNXVF7BdV+vZBARwpOOHZ0aa+IgOv2jJisL8UKosWtnbsS4dBwxnuyZ2p Zinsn9u+MM5/SpQxJ8TcdfL5kL9tu8Qp4HhJj7YdfC/WI+gMwgbbYMWwWTNBhyGkC+1t qqX30liOIkoLfFUJiEHO3JJ4OAn5YgjpTIJTFSt4JCW8kUBPP+DIIrKS3MWsoezD3878 i11A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=HK39ME0f; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z4-v6si19203516pgv.621.2018.07.11.20.02.16; Wed, 11 Jul 2018 20:02:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=HK39ME0f; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390652AbeGKW22 (ORCPT + 99 others); Wed, 11 Jul 2018 18:28:28 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:44633 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733146AbeGKW22 (ORCPT ); Wed, 11 Jul 2018 18:28:28 -0400 Received: by mail-pf0-f193.google.com with SMTP id j3-v6so19275053pfh.11 for ; Wed, 11 Jul 2018 15:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NC5Wll+Ta90LWa7k3YHEONHdQo3lP6YNOAIHcaPq1+E=; b=HK39ME0feC6LgQfKJIWgi4Z6wlPvIKWIpfRp4JSUx3Hzcfi1qult6Fnj8EfGQyewzg QPR9o+s+7yVUBLuRwuglutgvxSZZ40yD6WOLbJUEmPDTwaV29ScSPAvFE++4o5F7NG8n ICQT6Nio9+yK0UiDM7BNLUpAwpV/u9Iea4j/SePB3F+Q8vpdG5PjyKgnPahJ0qbTUX+F k1tcAv6Iv09C896C0N8RxxekS6NkXa7abLHt2kKXcQdKFWVdyaV+WaFRHPAxJUaj6p0U y7LTgYq+dlKCcIvelXicgVmtIXL1S+ykc/1V4D+IF/1aSq1SDKNr8+IXSs7/l2OZ8ZFV Pa0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NC5Wll+Ta90LWa7k3YHEONHdQo3lP6YNOAIHcaPq1+E=; b=m76+0JQxVboxIqj2254Kg+EquFy2zzfmNXIpjMOfblt4EzBpwWNkMGw38XmOSZn8WU rjVMCb9qhWElEQwS0U77rm1sgbxmXMO5i09Xx8F39SWw2I0+1IEFcqCF1sXbv6wVSRpk b2KWudtBLUNh1eOy9VpIn2apOcu9N1bJ5caGr6vEytYOYb1mJbOCeA5c3hgsLhTVDIhu cHSGUn7FwMEPUdSYKjcCxKPD5osMCAIW5zdRuFcyqtKRmYXbH5drFC+rSH4NKU/3UQqq XlJlnZxVNBoetHSse/0svNFbQSMqDKt9fGDlbXPxUomvKTPjyszfTKZzUFTYkKpn6nYK p5dw== X-Gm-Message-State: AOUpUlE2WnSbBguXW3R1BoRa5zhW9PKEeay3K/Ybp+isPb7mhumv2eKd 49eVRoG0P1VU+RQdlGGLQLWAqw== X-Received: by 2002:a62:8a4f:: with SMTP id y76-v6mr396246pfd.233.1531347720835; Wed, 11 Jul 2018 15:22:00 -0700 (PDT) Received: from ?IPv6:2600:1010:b052:968:4f0:92ce:1385:5f3d? ([2600:1010:b052:968:4f0:92ce:1385:5f3d]) by smtp.gmail.com with ESMTPSA id a15-v6sm20060710pfe.32.2018.07.11.15.21.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 15:21:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [RFC PATCH v2 17/27] x86/cet/shstk: User-mode shadow stack support From: Andy Lutomirski X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Wed, 11 Jul 2018 15:21:58 -0700 Cc: yu-cheng.yu@intel.com, the arch/x86 maintainers , "H . Peter Anvin" , Thomas Gleixner , Ingo Molnar , kernel list , linux-doc@vger.kernel.org, Linux-MM , linux-arch , Linux API , Arnd Bergmann , bsingharora@gmail.com, Cyrill Gorcunov , Dave Hansen , Florian Weimer , hjl.tools@gmail.com, Jonathan Corbet , keescook@chromiun.org, Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , ravi.v.shankar@intel.com, vedvyas.shanbhogue@intel.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180710222639.8241-1-yu-cheng.yu@intel.com> <20180710222639.8241-18-yu-cheng.yu@intel.com> <6F5FEFFD-0A9A-4181-8D15-5FC323632BA6@amacapital.net> To: Jann Horn Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Jul 11, 2018, at 2:51 PM, Jann Horn wrote: >=20 > On Wed, Jul 11, 2018 at 2:34 PM Andy Lutomirski wrot= e: >>> On Jul 11, 2018, at 2:10 PM, Jann Horn wrote: >>>=20 >>>> On Tue, Jul 10, 2018 at 3:31 PM Yu-cheng Yu wro= te: >>>>=20 >>>> This patch adds basic shadow stack enabling/disabling routines. >>>> A task's shadow stack is allocated from memory with VM_SHSTK >>>> flag set and read-only protection. The shadow stack is >>>> allocated to a fixed size. >>>>=20 >>>> Signed-off-by: Yu-cheng Yu >>> [...] >>>> diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c >>>> new file mode 100644 >>>> index 000000000000..96bf69db7da7 >>>> --- /dev/null >>>> +++ b/arch/x86/kernel/cet.c >>> [...] >>>> +static unsigned long shstk_mmap(unsigned long addr, unsigned long len)= >>>> +{ >>>> + struct mm_struct *mm =3D current->mm; >>>> + unsigned long populate; >>>> + >>>> + down_write(&mm->mmap_sem); >>>> + addr =3D do_mmap(NULL, addr, len, PROT_READ, >>>> + MAP_ANONYMOUS | MAP_PRIVATE, VM_SHSTK, >>>> + 0, &populate, NULL); >>>> + up_write(&mm->mmap_sem); >>>> + >>>> + if (populate) >>>> + mm_populate(addr, populate); >>>> + >>>> + return addr; >>>> +} > [...] >>> Should the kernel enforce that two shadow stacks must have a guard >>> page between them so that they can not be directly adjacent, so that >>> if you have too much recursion, you can't end up corrupting an >>> adjacent shadow stack? >>=20 >> I think the answer is a qualified =E2=80=9Cno=E2=80=9D. I would like to i= nstead enforce a general guard page on all mmaps that don=E2=80=99t use MAP_= FORCE. We *might* need to exempt any mmap with an address hint for compatibi= lity. >=20 > I like this idea a lot. >=20 >> My commercial software has been manually adding guard pages on every sing= le mmap done by tcmalloc for years, and it has caught a couple bugs and cost= s essentially nothing. >>=20 >> Hmm. Linux should maybe add something like Windows=E2=80=99 =E2=80=9Crese= rved=E2=80=9D virtual memory. It=E2=80=99s basically a way to ask for a VA r= ange that explicitly contains nothing and can be subsequently be turned into= something useful with the equivalent of MAP_FORCE. >=20 > What's the benefit over creating an anonymous PROT_NONE region? That > the kernel won't have to scan through the corresponding PTEs when > tearing down the mapping? Make it more obvious what=E2=80=99s happening and avoid accounting issues? W= hat I=E2=80=99ve actually used is MAP_NORESERVE | PROT_NONE, but I think thi= s still counts against the VA rlimit. But maybe that=E2=80=99s actually the d= esired behavior.