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=-2.7 required=3.0 tests=BAYES_00,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 A0F5DC433ED for ; Wed, 28 Apr 2021 17:15:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1A17C6143C for ; Wed, 28 Apr 2021 17:15:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A17C6143C 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 3C10B6B006E; Wed, 28 Apr 2021 13:15:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3704E6B00A6; Wed, 28 Apr 2021 13:15:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FD736B00A7; Wed, 28 Apr 2021 13:15:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id 03FE46B006E for ; Wed, 28 Apr 2021 13:15:47 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BB5518249980 for ; Wed, 28 Apr 2021 17:15:47 +0000 (UTC) X-FDA: 78082427934.07.B21FB68 Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) by imf14.hostedemail.com (Postfix) with ESMTP id 6359EC0007EE for ; Wed, 28 Apr 2021 17:15:31 +0000 (UTC) Received: by mail-oi1-f182.google.com with SMTP id z7so11535093oix.9 for ; Wed, 28 Apr 2021 10:15:47 -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=GDNVrff76VfRvD1j2rT05FypZOPT0Mkjjgr3q5U+VQs=; b=erq4vAGuJkQ8SLktjhZPoxGk6wz1+UuIbAj57Rr7KkYYOB1NZYw0zdi5NYSYpquFij 49QBMCIkAsb3hXsHwEzPSV9O/XsH6xbDxOLEBgKaxpRFTmAxC/u0xHHQ6h8BGxojsRly NjkpVJn8Nlpo1eo7rFT0w9fQUHQl30Z1wrn9KtV6SoDHQ7vGuFRjuQh5qFF7TjYtPwdF GPGDDOqEJ9PW94EtgE/59JBvIa8nEcwn6gcXDFB8CVy0EJMpAm8cfirMN+8lXdqfg3gT WmgMfwHNFhSaDHGXh+cDbnNrQ5Mi1HQ+tjOBgAUDyfAgoUtDrIqjx9XNze7X0NqMz6U8 r3Bw== 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=GDNVrff76VfRvD1j2rT05FypZOPT0Mkjjgr3q5U+VQs=; b=ON4mVzA/yF073gc/mvpkt3XNbKY8nuidnohDiOGGmaynAiBbsa18E3WXJpOF8vrmDg WBPHcEGaUemMef2cANjbvLmtcbP04KaGcW/otbokv0yu1BqS2cxOhZA+CH52SoT/7v8R eIb+N8OSeE1MWjaXjiLEUhTAuGRqj9aUZK7F11GX6j9++qG4kEsuN3X7YXg3iHaK5Drn Rh5uid+eBbmlUIEqqAHx0C+KePvlXmXrVHsgoc6wgI/fiTU7Nc+jIe2MNstrLlHEmr/w Buq4EH7cBuoDyqyVqHP1Jr3n+LzATofrzJD2BR7TWeY3r2C+QZ46IwC48OE3UALlWE1B nRIQ== X-Gm-Message-State: AOAM530ITaqrpN27Drv/GVQR77nIud/EoqgxB/MWthPFNiecGr35UoFW c9qODTTAU06ad63ouV5OnCdOe46eUDfFeqyzc/Q= X-Google-Smtp-Source: ABdhPJxQrVjvc83ofCs6l74gjRa0C0tmhbLZn53UQcZWaj4ZM/E1Um2JQFVjFgAom3TPcnepSkOm9AgiCCimYK9INrI= X-Received: by 2002:aca:dd82:: with SMTP id u124mr3624452oig.35.1619630146460; Wed, 28 Apr 2021 10:15:46 -0700 (PDT) MIME-Version: 1.0 References: <20210427204720.25007-1-yu-cheng.yu@intel.com> <0e03c50ea05440209d620971b9db4f29@AcuMS.aculab.com> <0c6e1c922bc54326b1121194759565f5@AcuMS.aculab.com> <7d857e5d-e3d3-1182-5712-813abf48ccba@intel.com> In-Reply-To: <7d857e5d-e3d3-1182-5712-813abf48ccba@intel.com> From: "H.J. Lu" Date: Wed, 28 Apr 2021 10:15:10 -0700 Message-ID: Subject: Re: [PATCH v26 0/9] Control-flow Enforcement: Indirect Branch Tracking To: "Yu, Yu-cheng" Cc: David Laight , Andy Lutomirski , "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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6359EC0007EE X-Stat-Signature: qknt7dnaidrx5q3qi8op478wnzgm7rqd Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=mail-oi1-f182.google.com; client-ip=209.85.167.182 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619630131-433133 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 Wed, Apr 28, 2021 at 9:25 AM Yu, Yu-cheng wrote: > > 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. > If you have a Tiger Lake laptop, you can install the CET kernel on Fedora 34 or Ubuntu 20.10/21.04. -- H.J.