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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 A744DC10F25 for ; Mon, 9 Mar 2020 19:50:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6B19E20828 for ; Mon, 9 Mar 2020 19:50:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GRUVcWz8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B19E20828 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0F4D86B0007; Mon, 9 Mar 2020 15:50:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A63C6B0008; Mon, 9 Mar 2020 15:50:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAEBF6B000A; Mon, 9 Mar 2020 15:50:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0230.hostedemail.com [216.40.44.230]) by kanga.kvack.org (Postfix) with ESMTP id D1D146B0007 for ; Mon, 9 Mar 2020 15:50:52 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B1ADC180AD80F for ; Mon, 9 Mar 2020 19:50:52 +0000 (UTC) X-FDA: 76576866744.22.step04_41d347649c815 X-HE-Tag: step04_41d347649c815 X-Filterd-Recvd-Size: 6081 Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Mar 2020 19:50:52 +0000 (UTC) Received: by mail-ot1-f67.google.com with SMTP id i14so10865965otp.5 for ; Mon, 09 Mar 2020 12:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nkN/HhcaxTaMqjSPmAB4y2TrVQWh2UghCp6ed7Ymedw=; b=GRUVcWz8NS6GonVqLH7A8HBhMLWHO/FQrUmK2o5rILiHn267Yu/YMDls+jBXFYlQoU sSBf9pKseLsFO4P4HQkiLtMdyYGx5v+rBWxbsRgtg2F+BXuQ6I6vQDlqAVjwJ8/KHBNR BOq0GhdowdUt/dQFjA5j0PZ65C+X4OoD/KEjb1wNROmtYHkAjWzwOg1En720F6woKchZ ni/J3LoGiyqx+2RrYBFLY8wXJMlNphBeMahzijYvyYzk2Q/dbcuxv6PiIfYlXDhvrBwR bEr/fwCZE3AY6rhbz8+c4NEGZ9kShnw4A+xjp7kOroNplVej75u5I64gxC2fTfMciQh5 lMVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nkN/HhcaxTaMqjSPmAB4y2TrVQWh2UghCp6ed7Ymedw=; b=h+p7mRioxN1qHpJpMRNzOhkK+W84lv4DN9k2ROaIW21+52bJqAX1b2SJdxNA/LIr2f j+xoNp7OZ1vnqpZ5z4aeVtqqe3RfcwvpC58ywXpvlTm2CHudeC+CcnLhJyvYfUSimYQY vkT91/EnuNmoLAcTeWVpOl5FHPz9rveiZXLpjcRpoH7Yuiju+PDheNLkovX3ssPEzXoW WHSjiAo/5i3A3c/8TZnz8KwH1o51RzE9KSLG6aAwB9BzdXT4D5FNdf6jJqt05bHdsfKg 6/3AgvmJZOsto/NT7s9dZESzMB3b49rFIawV1cWzPe/bjuX8Ud1eiFdPFS1wt13/9E9r Rwag== X-Gm-Message-State: ANhLgQ3B3Rrw/Ynb46l7mJ1cO5VL7eNOAd3J1pLF8Dc+8+lHY4k7v20l 2RtHY7U19Ah5Gv0qUJ38rI/O++X7pO+JIgtO9zo= X-Google-Smtp-Source: ADFU+vve+GcrqYBONvNR2/zOYFR37sq8ywR+BjHMbjrW7EG8MZXD9YH7Fm5vcljapWORsYBTgXr3IcPwh7QcWKheLL4= X-Received: by 2002:a9d:6c94:: with SMTP id c20mr14659465otr.285.1583783451354; Mon, 09 Mar 2020 12:50:51 -0700 (PDT) MIME-Version: 1.0 References: <20200205181935.3712-1-yu-cheng.yu@intel.com> <20200205181935.3712-2-yu-cheng.yu@intel.com> <9ae1cf84-1d84-1d34-c0ce-48b0d70b8f3f@intel.com> <0f43463e02d1be2af6bcf8ff6917e751ba7676a0.camel@intel.com> <968af1c2-a5b4-fb48-dfa9-499ec37f677c@intel.com> <9b7ff325-d7cd-9309-d060-ad641486d106@intel.com> In-Reply-To: <9b7ff325-d7cd-9309-d060-ad641486d106@intel.com> From: "H.J. Lu" Date: Mon, 9 Mar 2020 12:50:15 -0700 Message-ID: Subject: Re: [RFC PATCH v9 01/27] Documentation/x86: Add CET description To: Dave Hansen Cc: Yu-cheng Yu , "the arch/x86 maintainers" , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , Linux API , Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , x86-patch-review@intel.com Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Mar 9, 2020 at 12:35 PM Dave Hansen wrote: > > On 3/9/20 12:27 PM, Yu-cheng Yu wrote: > > On Mon, 2020-03-09 at 10:21 -0700, Dave Hansen wrote: > >> On 3/9/20 10:00 AM, Yu-cheng Yu wrote: > >>> On Wed, 2020-02-26 at 09:57 -0800, Dave Hansen wrote>>>>> +Note: > >>>>> + There is no CET-enabling arch_prctl function. By design, CET is > >>>>> + enabled automatically if the binary and the system can support it. > >>>> > >>>> This is kinda interesting. It means that a JIT couldn't choose to > >>>> protect the code it generates and have different rules from itself? > >>> > >>> JIT needs to be updated for CET first. Once that is done, it runs with CET > >>> enabled. It can use the NOTRACK prefix, for example. > >> > >> Am I missing something? > >> > >> What's the direct connection between shadow stacks and Indirect Branch > >> Tracking other than Intel marketing umbrellas? > > > > What I meant is that JIT code needs to be updated first; if it skips RETs, > > it needs to unwind the stack, and if it does indirect JMPs somewhere it > > needs to fix up the branch target or use NOTRACK. > > I'm totally lost. I think we have very different models of how a JIT > might generate and run code. > > I can totally see a scenario where a JIT goes and generates a bunch of > code, then forks a new thread to go run that code. The control flow of > the JIT thread itself *NEVER* interacts with the control flow of the > program it writes. They never share a stack and nothing ever jumps or > rets between the two worlds. > > Does anything actually do that? I've got no idea. But, I can clearly > see a world where the entirety of Chrome and Firefox and the entire rust > runtime might not be fully recompiled and CET-enabled for a while. But, > we still want the JIT-generated code to be CET-protected since it has > the most exposed attack surface. > > I don't think that's too far-fetched. CET support is all or nothing. You can mix and match, but you will get no CET protection, similar to NX feature. -- H.J.