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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 915A4C43461 for ; Wed, 28 Apr 2021 16:25:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F099561418 for ; Wed, 28 Apr 2021 16:25:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F099561418 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 558BC6B00D9; Wed, 28 Apr 2021 12:25:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 52F2D6B00DA; Wed, 28 Apr 2021 12:25:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3AAA56B00DB; Wed, 28 Apr 2021 12:25:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 2241E6B00D9 for ; Wed, 28 Apr 2021 12:25:01 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id CD7EA1269 for ; Wed, 28 Apr 2021 16:25:00 +0000 (UTC) X-FDA: 78082299960.35.5DD96C9 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf04.hostedemail.com (Postfix) with ESMTP id 0D69E13A for ; Wed, 28 Apr 2021 16:24:55 +0000 (UTC) IronPort-SDR: 9/QXGX09BTsxpC6Idv8qfu1bQmLiVs8trrLYgMXbGEVUw01hKKWm+luXxg2zx8LDLFJP6OfcrU 5bYo7weMtY8Q== X-IronPort-AV: E=McAfee;i="6200,9189,9968"; a="260737050" X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="260737050" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2021 09:24:55 -0700 IronPort-SDR: iYKiWGUzmjWmi7osjPR7ovPDHt4e7Z5mHFxVw8uXJpANdfEyblOIG9sK3P803dR1wOybig8Imf nQ2aVbEXh9Zg== X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="537022643" Received: from yyu32-mobl1.amr.corp.intel.com (HELO [10.209.133.34]) ([10.209.133.34]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2021 09:24:53 -0700 Subject: Re: [PATCH v26 0/9] Control-flow Enforcement: Indirect Branch Tracking To: David Laight , 'Andy Lutomirski' , "H.J. Lu" Cc: "x86@kernel.org" , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-mm@kvack.org" , "linux-arch@vger.kernel.org" , "linux-api@vger.kernel.org" , Arnd Bergmann , 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 , Weijiang Yang , Pengfei Xu , Haitao Huang References: <20210427204720.25007-1-yu-cheng.yu@intel.com> <0e03c50ea05440209d620971b9db4f29@AcuMS.aculab.com> <0c6e1c922bc54326b1121194759565f5@AcuMS.aculab.com> From: "Yu, Yu-cheng" Message-ID: <7d857e5d-e3d3-1182-5712-813abf48ccba@intel.com> Date: Wed, 28 Apr 2021 09:24:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <0c6e1c922bc54326b1121194759565f5@AcuMS.aculab.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0D69E13A X-Stat-Signature: 9k7wyi6rfix4abc8aw96zn8igh81j4ds Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf04; identity=mailfrom; envelope-from=""; helo=mga07.intel.com; client-ip=134.134.136.100 X-HE-DKIM-Result: none/none X-HE-Tag: 1619627095-749290 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 4/28/2021 8:33 AM, David Laight wrote: > From: Andy Lutomirski >> Sent: 28 April 2021 16:15 >> >> On Wed, Apr 28, 2021 at 7:57 AM H.J. Lu wrote: >>> >>> On Wed, Apr 28, 2021 at 7:52 AM Andy Lutomirski wrote: >>>> >>>> On Wed, Apr 28, 2021 at 7:48 AM David Laight wrote: >>>>> >>>>> From: Yu-cheng Yu >>>>>> Sent: 27 April 2021 21:47 >>>>>> >>>>>> Control-flow Enforcement (CET) is a new Intel processor feature that blocks >>>>>> return/jump-oriented programming attacks. Details are in "Intel 64 and >>>>>> IA-32 Architectures Software Developer's Manual" [1]. >>>>> ... >>>>> >>>>> Does this feature require that 'binary blobs' for out of tree drivers >>>>> be compiled by a version of gcc that adds the ENDBRA instructions? >>>>> >>>>> If enabled for userspace, what happens if an old .so is dynamically >>>>> loaded? >>> >>> CET will be disabled by ld.so in this case. >> >> What if a program starts a thread and then dlopens a legacy .so? > > Or has shadow stack enabled and opens a .so that uses retpolines? > When shadow stack is enabled, retpolines are not necessary. I don't know if glibc has been updated for detection of this case. H.J.? >>>>> Or do all userspace programs and libraries have to have been compiled >>>>> with the ENDBRA instructions? >>> >>> Correct. ld and ld.so check this. >>> >>>> If you believe that the userspace tooling for the legacy IBT table >>>> actually works, then it should just work. Yu-cheng, etc: how well >>>> tested is it? >>>> >>> >>> Legacy IBT bitmap isn't unused since it doesn't cover legacy codes >>> generated by legacy JITs. >>> >> >> How does ld.so decide whether a legacy JIT is in use? > > What if your malware just precedes its 'jump into the middle of a function' > with a %ds segment override? > Do you mean far jump? It is not tracked by ibt, which tracks near indirect jump. The details can be found in Intel SDM. > I may have a real problem here. > We currently release program/library binaries that run on Linux > distributions that go back as far as RHEL6 (2.6.32 kernel era). > To do this everything is compiled on a userspace of the same vintage. > I'm not at all sure a new enough gcc to generate the ENDBR64 instructions > will run on the relevant system - and may barf on the system headers > even if we got it to run. > I really don't want to have to build multiple copies of everything. This is likely OK. We have tested many combinations. Should you run into any issue, please let glibc people know. Thanks! > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) >