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 1688397 - libjpeg-turbo: Support running with Intel CET
Summary: libjpeg-turbo: Support running with Intel CET
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libjpeg-turbo
Version: 8.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: 8.0
Assignee: Nikola Forró
QA Contact: Jan Houska
URL:
Whiteboard:
Depends On:
Blocks: 1567218
TreeView+ depends on / blocked
 
Reported: 2019-03-13 16:56 UTC by Paolo Bonzini
Modified: 2020-11-14 11:43 UTC (History)
9 users (show)

Fixed In Version: libjpeg-turbo-1.5.3-8.el8
Doc Type: No Doc Update
Doc Text:
Clone Of: 1630583
Environment:
Last Closed: 2019-11-05 22:42:23 UTC
Type: ---
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Add endbr32/endbr64 instructions to assembly sources (25.63 KB, patch)
2019-04-10 10:32 UTC, Nikola Forró 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:3705 0 None None None 2019-11-05 22:42:28 UTC

Description Paolo Bonzini 2019-03-13 16:56:27 UTC 
> The most common reason for the GNU Property note being missing is that
> the library contains one or more object files that were created by a 
> tool other than gcc.  (It is gcc that produces the GNU property note,
> the annobin tool just monitors its use).  Usually this means that some
> assembler source is included in the build, but using compilers other than
> gcc will also have the same effect.
>
> The linker combines the GNU property notes from the input files when it 
> creates a library (or an executable), but if some of the files are missing
> notes then it will decide to delete the note entirely.  (On the grounds
> that it cannot be sure of the properties of the input files).  The note 
> is important to the loader as it tells it details about the executable,
> and in particular it indicates whether the binary supports Intel's new
> CET (control flow enforcement technology).  Without this note, this
> security feature cannot be (safely) enabled, which would be a bad thing.

You also need to add endbr32 or endbr64 markers to assembly, and nasm does not support those yet.  The encoding is "dd 0xfa1e0ff3" in 64-bit assembly and "dd 0xfb1e0ff3" in 32-bit assembly.

Because libjpeg-turbo uses nasm, it is probably simpler to link with -Wl,-z,ibt -Wl,-z,shstk rather than figuring out how to write GNU property notes.
Comment 3 Nikola Forró 2019-03-21 13:40:03 UTC 
> You also need to add endbr32 or endbr64 markers to assembly, and nasm does not support those yet.

As far as I can tell, there are no indirect calls nor indirect jumps in nasm sources. That means nasm-compiled object files are only missing the GNU Property note, which I can force on the resulting library by passing "-Wl,-z,ibt -Wl,-z,shstk" to the linker, am I right?
Comment 4 Paolo Bonzini 2019-04-05 12:13:48 UTC 
You still need endbr32 and endbr64 at the beginning of exported routines, because they can be called through an indirect jump via the PLT, and also at the beginning of any assembly routine that can be called via an indirect call.
Comment 5 Nikola Forró 2019-04-10 10:32:52 UTC 
Created attachment 1554180 [details]
Add endbr32/endbr64 instructions to assembly sources

Paolo, does this patch look good to you?
Comment 6 Paolo Bonzini 2019-04-12 07:35:38 UTC 
Yes, except for the linker flags of course.  You can test that those are applied properly with "readelf -n /usr/lib64/libjpeg.so|grep -A4 prop".

Just one nit, perhaps it's better to call the macros _endbr32 and _endbr64 to avoid future conflicts when nasm implements the instructions.

I can test it for you when you have an RPM patch ready.  And also, don't forget to include it in Fedora too. :)
Comment 7 Nikola Forró 2019-04-29 13:48:32 UTC 
Thanks,

here is a private branch commit:
http://pkgs.devel.redhat.com/cgit/rpms/libjpeg-turbo/commit/?h=private-nforro-bz1688397-rhel-8.1.0&id=e9c1810b1790a1672db7ecacd36a594eedcee9fb

abd here is a scratch build with a repo:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=21354506
http://brew-task-repos.usersys.redhat.com/repos/scratch/nforro/libjpeg-turbo/1.5.3/8.el8/libjpeg-turbo-1.5.3-8.el8-scratch.repo
Comment 10 Jan Houska 2019-07-31 15:10:10 UTC 
VERIFIED:
bug can be confirmed only for x86_64 now. 


NEW PASS:

rpm -qa  libjpeg-turbo
libjpeg-turbo-1.5.3-10.el8.x86_64
libjpeg-turbo-1.5.3-10.el8.i686


[root@sweetpig-8 ~]# readelf -n /usr/lib64/libjpeg.so|grep -A4 prop
Displaying notes found in: .note.gnu.property
  Owner                 Data size       Description
  GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: IBT, SHSTK


OLD FAIL:
[root@sheep-1 ~]# rpm -qa  libjpeg-turbo
libjpeg-turbo-1.5.3-7.el8.i686
libjpeg-turbo-1.5.3-7.el8.x86_64

[root@sheep-1 ~]# readelf -n /usr/lib64/libjpeg.so|grep -A4 prop
[root@sheep-1 ~]# 


NOTE other architectures:

NEW
[root@ibm-z-128 ~]# rpm -qa  libjpeg-turbo
libjpeg-turbo-1.5.3-10.el8.s390x

[root@ibm-z-128 ~]# readelf -n /usr/lib64/libjpeg.so|grep -A4 prop



OLD:
[root@ibm-z-111 ~]# rpm -qa  libjpeg-turbo
libjpeg-turbo-1.5.3-7.el8.s390x

[root@ibm-z-111 ~]# readelf -n /usr/lib64/libjpeg.so|grep -A4 prop
[root@ibm-z-111 ~]#
Comment 12 errata-xmlrpc 2019-11-05 22:42:23 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, 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-2019:3705
Note You need to log in before you can comment on or make changes to this bug.