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 5F284C10F29 for ; Mon, 9 Mar 2020 20:54:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2534B24655 for ; Mon, 9 Mar 2020 20:54:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IOHJUtSt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2534B24655 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 B4D3A6B0005; Mon, 9 Mar 2020 16:54:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFC6D6B0006; Mon, 9 Mar 2020 16:54:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A122B6B0007; Mon, 9 Mar 2020 16:54:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0053.hostedemail.com [216.40.44.53]) by kanga.kvack.org (Postfix) with ESMTP id 8964A6B0005 for ; Mon, 9 Mar 2020 16:54:52 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5A967613D for ; Mon, 9 Mar 2020 20:54:52 +0000 (UTC) X-FDA: 76577028024.26.fish90_2a7742d9cad3d X-HE-Tag: fish90_2a7742d9cad3d X-Filterd-Recvd-Size: 6682 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Mar 2020 20:54:51 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id 111so6696764oth.13 for ; Mon, 09 Mar 2020 13:54:51 -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:content-transfer-encoding; bh=EzETE5yRJO875WktHCogKuD+gLJ9pGXC3SMjRgGh6/s=; b=IOHJUtSt4gA2J3tjh8e6nwHGDQlBz5HEn8kCmWFJ/pKzMfURIv0zhomQ1HyrzLdRkk PmaeiOywzKFiwFsUTMNav/3IZ9+Ss0DfhZO8iQzxr4+KOkGQQE396mjwjqZAK9yAqIGO q81jDehmAPZ83ne1F7Cr/GY6sD6mn+z98/zjaxjDXJ1zzoQlMNs8Z5Ssvv7bPXuDGcl7 eKllUwIP1IRCkA0xAyLWOalQPvskHGtMKWbK9wNB/zemsX7lWy8Gi/hLdS69lQ9PECpk ycvFafG1RDOhKZw3wtnJ72dsvthTBzoQUKbQy8J9kzGFm3W0L5hfdrhBfUAfwgS02LhU RFnA== 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:content-transfer-encoding; bh=EzETE5yRJO875WktHCogKuD+gLJ9pGXC3SMjRgGh6/s=; b=V/Ie1Cti1Pr/9Olmk2ysSgbUntIVkqwsTwnFLW+5C6hJ7SwKUjxe+1jR/mWIpeop9w EsGgk14uWgTB0qLEBhM8l0xuE7LpWFvs5R448YtgZOP7pxpDaZAVUeW4nA52PamxYsu0 vlIfgHbUyI4ylOSKNW18OZbRgdTA8+nQCIo7h4Klqdxpxkg1AmUl9hHXZ2zjYQjc56Lv cEmdIJtId+kzSsEhxtj/w3sQJKf0k7KmWzdJxnObBWQhqmy0qrlcEf79wVSMgwkM2DL6 SEfcO5WJYy/MyuizJMBKRtlW0EHAR0nu4Iu8FjA7nL4He8IXdWDvLJWUbWWrrh56Ap9P h9zg== X-Gm-Message-State: ANhLgQ1XLjxh3h6uvreFX9szEdHFZirwk/oHqxqVGxWQoSKHBsMw2TkQ UuEPdCaV6fR8MwFVR6FIrzGYCFW3osw4XpFQR3g= X-Google-Smtp-Source: ADFU+vsPlWEzQFx4TbHhJADrI3NMCO9RXluoOsyiW9GGus6jzt3uDp2BmaPUuAHmAe10jjD+CbZ4n/easHasLtqyYoo= X-Received: by 2002:a9d:19ef:: with SMTP id k102mr11368931otk.220.1583787290605; Mon, 09 Mar 2020 13:54:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Mon, 9 Mar 2020 13:54:14 -0700 Message-ID: Subject: Re: [RFC PATCH v9 01/27] Documentation/x86: Add CET description To: Andy Lutomirski Cc: Dave Hansen , 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" Content-Transfer-Encoding: quoted-printable 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 1:16 PM Andy Lutomirski wrote: > > > > > On Mar 9, 2020, at 12:50 PM, H.J. Lu wrote: > > > > =EF=BB=BFOn 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 Bran= ch > >>>> 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 o= f > >> 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 ru= st > >> runtime might not be fully recompiled and CET-enabled for a while. Bu= t, > >> 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 ge= t > > no CET protection, similar to NX feature. > > > > Can you explain? I was talking about creating a program from mixed object files with and wit= hout CET marker. > If a program with the magic ELF CET flags missing can=E2=80=99t make a th= read with IBT and/or SHSTK enabled, then I think we=E2=80=99ve made an erro= r and should fix it. > A non-CET program can start a CET program and vice versa. --=20 H.J.