RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1855790 - glibc: Update Intel CET support from upstream
Summary: glibc: Update Intel CET support from upstream
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: glibc
Version: 8.4
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: 8.4
Assignee: Carlos O'Donell
QA Contact: Sergey Kolosov
URL:
Whiteboard:
: 1645613 (view as bug list)
Depends On: 1893197
Blocks: 1877113 1894575
TreeView+ depends on / blocked
 
Reported: 2020-07-10 13:56 UTC by Carlos O'Donell
Modified: 2023-07-18 14:30 UTC (History)
10 users (show)

Fixed In Version: glibc-2.28-141.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-18 14:36:34 UTC
Type: Enhancement
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Sourceware 26985 0 P2 NEW x86: sysdeps/x86/configure.ac needs quoting for CET support. 2020-12-23 15:33:26 UTC

Description Carlos O'Donell 2020-07-10 13:56:05 UTC 
We need to update the Intel CET support in glibc based on all the current upstream work.

The first step is to get a list of all commits upstream related to Intel CET since the last update for these patches.

Once we have the list of patches we should review them and consider them for inclusion in the RHEL 8.4 y-stream.

We will be working closely with Intel on this list of commits for RHEL 8.4.
Comment 2 Carlos O'Donell 2020-07-20 13:51:00 UTC 
*** Bug 1645613 has been marked as a duplicate of this bug. ***
Comment 4 Carlos O'Donell 2020-08-23 02:16:26 UTC 
We still need to review all of the upstream commits, but during a first pass I identified these:

674ea88294bfb8d89878a0ebbbcec38a85e118a5	x86: Move CET control to _dl_x86_feature_control [BZ #25887]
9e38f455a6c602be86b7b5a8d6523cbdcd7ec051	x86: Add --enable-cet=permissive
7787a35fd0ac1d42a05d3a45223158efa54d87d7	elf.h: Add PT_GNU_PROPERTY
c7aa8596de86fb667914ccb95c10495ad056ff96	rtld: Clean up PT_NOTE and add PT_GNU_PROPERTY handling
Comment 6 Florian Weimer 2020-09-24 11:56:06 UTC 
H.J. submitted a backport via CentOS Stream: https://git.stg.centos.org/source-git/glibc/pull-request/1

He identified the following commits:

6800f76 x86: Remove ARCH_CET_LEGACY_BITMAP [BZ #25397]
9498ead i386: Enable CET support in ucontext functions
b8b19c8 i386: Remove _exit.S
ad5b1c8 i386: Use ENTRY/END in assembly codes
35e2de4 i386-mcount.S: Add _CET_ENDBR to _mcount and fentry
4126519 i386/sub_n.S: Add a missing _CET_ENDBR to indirect jump target
28076c5 i386: Don't unnecessarily save and restore EAX, ECX and EDX [BZ# 25262]
Comment 7 H.J. Lu 2020-09-24 17:52:01 UTC 
Is this commit

commit 9e38f455a6c602be86b7b5a8d6523cbdcd7ec051
Author: H.J. Lu <hjl.tools>
Date:   Mon Apr 27 15:44:07 2020 -0700

    x86: Add --enable-cet=permissive
    
    When CET is enabled, it is an error to dlopen a non CET enabled shared
    library in CET enabled application.  It may be desirable to make CET
    permissive, that is disable CET when dlopening a non CET enabled shared
    library.  With the new --enable-cet=permissive configure option, CET is
    disabled when dlopening a non CET enabled shared library.

needed for RHEL8? If yes, I can create another PR.
Comment 8 Florian Weimer 2020-09-24 17:58:39 UTC 
(In reply to H.J. Lu from comment #7)
> Is this commit
> 
> commit 9e38f455a6c602be86b7b5a8d6523cbdcd7ec051
> Author: H.J. Lu <hjl.tools>
> Date:   Mon Apr 27 15:44:07 2020 -0700
> 
>     x86: Add --enable-cet=permissive
>     
>     When CET is enabled, it is an error to dlopen a non CET enabled shared
>     library in CET enabled application.  It may be desirable to make CET
>     permissive, that is disable CET when dlopening a non CET enabled shared
>     library.  With the new --enable-cet=permissive configure option, CET is
>     disabled when dlopening a non CET enabled shared library.
> 
> needed for RHEL8? If yes, I can create another PR.

Yes, unfortunately I think we need it for supporting NSS modules not built by us (among other things).
Comment 9 H.J. Lu 2020-09-24 18:26:45 UTC 
(In reply to Florian Weimer from comment #8)
> (In reply to H.J. Lu from comment #7)
> > Is this commit
> > 
> > commit 9e38f455a6c602be86b7b5a8d6523cbdcd7ec051
> > Author: H.J. Lu <hjl.tools>
> > Date:   Mon Apr 27 15:44:07 2020 -0700
> > 
> >     x86: Add --enable-cet=permissive
> >     
> >     When CET is enabled, it is an error to dlopen a non CET enabled shared
> >     library in CET enabled application.  It may be desirable to make CET
> >     permissive, that is disable CET when dlopening a non CET enabled shared
> >     library.  With the new --enable-cet=permissive configure option, CET is
> >     disabled when dlopening a non CET enabled shared library.
> > 
> > needed for RHEL8? If yes, I can create another PR.
> 
> Yes, unfortunately I think we need it for supporting NSS modules not built
> by us (among other things).

I updated

https://git.stg.centos.org/source-git/glibc/pull-request/1

with --enable-cet=permissive.
Comment 13 Carlos O'Donell 2020-11-09 13:35:19 UTC 
I additionally added the following recent commit to rhel-8.4.0.

From c02695d776406faaf63418e4e80c4a7023af0b4f Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools>
Date: Wed, 16 Sep 2020 16:00:14 -0700
Subject: [PATCH] x86/CET: Update vfork to prevent child return

Child of vfork should either call _exit or one of the exec family of
functions.  But normally there is nothing to prevent child of vfork from
return of the vfork-calling function.  Simpilfy x86 vfork when shadow
stack is in use to introduce mismatched shadow stack in child of vfork
to trigger SIGSEGV when the child returns from the function in which
vfork was called.
Comment 17 Carlos O'Donell 2020-11-13 05:05:09 UTC 
HJ,

Could you please test these RHEL 8.4.0 RPMs on your system?

Create the following /etc/yum.repos.d/rhbz1855790.repo
~~~
[rhbz1855790]
name=RHEL 8.4.0 testfix for bug 1855790
baseurl=https://people.redhat.com/codonell/rhel-8.4.0-rhbz1855790
enabled=1
gpgcheck=0
protect=1
~~~
Then dnf upgrade should just upgrade you to the testfix version.

You should see glibc-2.28-141 which contains the bundled Intel CET updates.

We're still working on testing these locally.
Comment 18 H.J. Lu 2020-11-13 12:31:37 UTC 
I am getting a new TGL laptop.  I will use it to test RHEL 8.4.0 after my TGL
laptop arrives.
Comment 21 H.J. Lu 2020-11-28 00:30:58 UTC 
I got a Dell XPS 13 9310 with Intel i7-1165G7 and microcode 0x60. I  installed
CentOS-Stream-8-x86_64-20201030-dvd1.iso.  But there is no WiFi driver in
kernel-core-4.18.0-240.el8.x86_64.  I installed hjl/cet/linux-5.9.11 kernel.
But it didn't boot due to old glibc.  glibc-2.28-141.el8.x86_64 fixed the issue.
I can boot into GUI mode.  Shadow stack and indirect branch tracking work
correctly:

[hjl@gnu-tgl-2 violations]$ make
if ./ibt1; then echo FAIL; exit 1; else echo PASS; fi
/bin/sh: line 1: 67059 Segmentation fault      (core dumped) ./ibt1
PASS
if ./shstk1; then echo FAIL; exit 1; else echo PASS; fi
/bin/sh: line 1: 67065 Segmentation fault      (core dumped) ./shstk1
PASS
[hjl@gnu-tgl-2 violations]$
Comment 23 Carlos O'Donell 2020-11-30 21:26:51 UTC 
(In reply to H.J. Lu from comment #21)
> I got a Dell XPS 13 9310 with Intel i7-1165G7 and microcode 0x60. I 
> installed
> CentOS-Stream-8-x86_64-20201030-dvd1.iso.  But there is no WiFi driver in
> kernel-core-4.18.0-240.el8.x86_64.  I installed hjl/cet/linux-5.9.11 kernel.
> But it didn't boot due to old glibc.  glibc-2.28-141.el8.x86_64 fixed the
> issue.
> I can boot into GUI mode.  Shadow stack and indirect branch tracking work
> correctly:

That is excellent news. Having independent checking for this is important and makes sure we didn't miss anything in our configuration.
Comment 24 Carlos O'Donell 2020-11-30 21:37:21 UTC 
(In reply to H.J. Lu from comment #21)
> I got a Dell XPS 13 9310 with Intel i7-1165G7 and microcode 0x60.

For the record we are using 0x6c microcode (after update from Intel).
Comment 26 Carlos O'Donell 2020-12-01 03:35:25 UTC 
HJ,

I filed this upstream for something DJ caught while doing a review of the patches:
https://sourceware.org/bugzilla/show_bug.cgi?id=26985
Comment 33 errata-xmlrpc 2021-05-18 14:36:34 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: glibc security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:1585
Note You need to log in before you can comment on or make changes to this bug.