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, 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 892ECC10F27 for ; Mon, 9 Mar 2020 20:16:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 420612465A for ; Mon, 9 Mar 2020 20:16:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="ZRaiCHGE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 420612465A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C050A6B0005; Mon, 9 Mar 2020 16:16:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB6476B0006; Mon, 9 Mar 2020 16:16:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA4E76B0007; Mon, 9 Mar 2020 16:16:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0206.hostedemail.com [216.40.44.206]) by kanga.kvack.org (Postfix) with ESMTP id 90A9C6B0005 for ; Mon, 9 Mar 2020 16:16:18 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6C52583E3 for ; Mon, 9 Mar 2020 20:16:18 +0000 (UTC) X-FDA: 76576930836.12.group78_8e55877577f19 X-HE-Tag: group78_8e55877577f19 X-Filterd-Recvd-Size: 6689 Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 9 Mar 2020 20:16:17 +0000 (UTC) Received: by mail-pl1-f196.google.com with SMTP id b22so4440761pls.12 for ; Mon, 09 Mar 2020 13:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=hmz7wPe81dzHCyk8vtSMtwBBBBwZYq3jRplov8Ww+C4=; b=ZRaiCHGEl38L7KRBnErstw4bimBDz87AHqw51Xkkbqe8mwiwaum46PZHXbMEgOOA0j Mwyf6ObvRwr7G2hs8Uj+hpnHhTmm/J8upQOk3D/fFQm05iw67GgRr+tyo+BLdhHy5nB5 Lwwt/y/AF+8OL42TzE087xDA1gbjLJ4boZbPZTHMsE3SeiOU9i8j90C6EyxoOBaxPp5A wprxkqzTwjQRhbgX5n/yY6UyfpmWQRavyv88zmVrNjeeHEmd2qDUM+SZ7oWZZscU3Kii PPT1iRwszjNEqvOJzEFaD43kNCwMl9myIn1ub/f1VW1KDm9Dn4q/kySbYkWX0GbNjPwC 7XmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=hmz7wPe81dzHCyk8vtSMtwBBBBwZYq3jRplov8Ww+C4=; b=BtxElHO2OHWq2tZp8SqG7d3YEkxGWfKoBmIpXdtF9h+O1cMKNlz+cKbkHdxmYYJI3e PjLKdssF85F5+i7ogI6eqCGlw33SnsD4LZKk1YWeODe4C6onuIfKjP81vIbXJ8hLxweA vzRFPGVF4dYievnocL1RUxcwAF2RKmirKoHsz+y+42IaxY/IZ/p+5U1T7TNkA8oaGFr9 FgCiBSocmcSdTvldO5WfSlwWu6Qpo93ABPovWttqkAISBR51QMSiQGzH9C+d/0ij7cp1 3jJxYvoj+TLZlJgel027pzSE8kdO8rg8MeJ6iFc24wOmSpiDnk9i5uVHnyzbsQwKajGm znMQ== X-Gm-Message-State: ANhLgQ2CXDfMQyXWIkM5VX6XiRjTZN++fhepuX/pLSZNGo2dIi25gQXA pZXF2/bbG0qasx08jKJlGS3n2A== X-Google-Smtp-Source: ADFU+vufTMP65N8WnOzHoWZtLu1mlwMdUeuo8lDWUX7ChArVxhlmQwIZxREHkmUUUFy0pcgRqvHV6A== X-Received: by 2002:a17:902:7607:: with SMTP id k7mr17287063pll.175.1583784976613; Mon, 09 Mar 2020 13:16:16 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:61f8:fe1:ddbe:5c19? ([2601:646:c200:1ef2:61f8:fe1:ddbe:5c19]) by smtp.gmail.com with ESMTPSA id h2sm44306210pgv.40.2020.03.09.13.16.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2020 13:16:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [RFC PATCH v9 01/27] Documentation/x86: Add CET description Date: Mon, 9 Mar 2020 13:16:14 -0700 Message-Id: References: 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 In-Reply-To: To: "H.J. Lu" X-Mailer: iPhone Mail (17D50) 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 Mar 9, 2020, at 12:50 PM, H.J. Lu wrote: >=20 > =EF=BB=BFOn Mon, Mar 9, 2020 at 12:35 PM Dave Hansen wrote: >>=20 >>> 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= . >>>>>>=20 >>>>>> This is kinda interesting. It means that a JIT couldn't choose to >>>>>> protect the code it generates and have different rules from itself? >>>>>=20 >>>>> JIT needs to be updated for CET first. Once that is done, it runs wit= h CET >>>>> enabled. It can use the NOTRACK prefix, for example. >>>>=20 >>>> Am I missing something? >>>>=20 >>>> What's the direct connection between shadow stacks and Indirect Branch >>>> Tracking other than Intel marketing umbrellas? >>>=20 >>> What I meant is that JIT code needs to be updated first; if it skips RET= s, >>> it needs to unwind the stack, and if it does indirect JMPs somewhere it >>> needs to fix up the branch target or use NOTRACK. >>=20 >> I'm totally lost. I think we have very different models of how a JIT >> might generate and run code. >>=20 >> 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. >>=20 >> 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. >>=20 >> I don't think that's too far-fetched. >=20 > CET support is all or nothing. You can mix and match, but you will get > no CET protection, similar to NX feature. >=20 Can you explain? If a program with the magic ELF CET flags missing can=E2=80=99t make a threa= d with IBT and/or SHSTK enabled, then I think we=E2=80=99ve made an error an= d should fix it. > --=20 > H.J.