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 A2822C10F25 for ; Mon, 9 Mar 2020 20:16:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7438E20637 for ; Mon, 9 Mar 2020 20:16:18 +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" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726295AbgCIUQR (ORCPT ); Mon, 9 Mar 2020 16:16:17 -0400 Received: from mail-pj1-f66.google.com ([209.85.216.66]:54260 "EHLO mail-pj1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726096AbgCIUQR (ORCPT ); Mon, 9 Mar 2020 16:16:17 -0400 Received: by mail-pj1-f66.google.com with SMTP id l36so370201pjb.3 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=bqB5YDLdekmwCKPOOOUJXfXSGRGTJAO/alYbA8vlKo9NEmtG35KpLSl6KfgXKJCZjR pX2fsY+xpSFqNEeVp/I2EZ9G0ezlulYxrc1gx84cS4chB2lNczSC9hv1o6uaBqKhvJt4 Q3OdSJgqVpywASE7dSGY5wc5ovbpWj3ErqbW/NY5bryjT4s/R2DnUtq0v/KxfWkd4yqB xux0eJx0fllAq5HJczOserCakN3LbfVcdusO/S20gD+gmA9hGDIGV71ugGl4O5A1yz8v +HCqxt83qPtTyGzh3LZN1Uwt9g/zufihF2FLkRFkRqwY7i1pZIXBrru9kmDVCnG55dqW r0dw== X-Gm-Message-State: ANhLgQ2Yi83cwFM9X8n4Zg7RrDVRy8Wr7QTLTeuY0X96v5LfaagO14IG M2B03orucppTTxS4IJnyMyk0nw== 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) Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org > 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.