From: Andy Lutomirski <luto@kernel.org>
To: David Laight <David.Laight@aculab.com>
Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Andy Lutomirski <luto@kernel.org>,
Balbir Singh <bsingharora@gmail.com>,
Borislav Petkov <bp@alien8.de>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Eugene Syromiatnikov <esyr@redhat.com>,
Florian Weimer <fweimer@redhat.com>,
"H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromium.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
Peter Zijlstra <peterz@infradead.org>,
Randy Dunlap <rdunlap@infradead.org>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>,
Dave Martin <Dave.Martin@arm.com>,
Weijiang Yang <weijiang.yang@intel.com>,
Pengfei Xu <pengfei.xu@intel.com>,
Haitao Huang <haitao.huang@intel.com>
Subject: Re: [PATCH v26 0/9] Control-flow Enforcement: Indirect Branch Tracking
Date: Wed, 28 Apr 2021 07:52:19 -0700 [thread overview]
Message-ID: <CALCETrUpZfznXzN3Ld33DMvQcHD2ACnhYf9KdP+5-xXuX_pVpA@mail.gmail.com> (raw)
In-Reply-To: <0e03c50ea05440209d620971b9db4f29@AcuMS.aculab.com>
On Wed, Apr 28, 2021 at 7:48 AM David Laight <David.Laight@aculab.com> 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?
> Or do all userspace programs and libraries have to have been compiled
> with the ENDBRA instructions?
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?
--Andy
next prev parent reply other threads:[~2021-04-28 14:52 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-27 20:47 [PATCH v26 0/9] Control-flow Enforcement: Indirect Branch Tracking Yu-cheng Yu
2021-04-27 20:47 ` [PATCH v26 1/9] x86/cet/ibt: Add Kconfig option for " Yu-cheng Yu
2021-04-28 20:29 ` Kees Cook
2021-04-27 20:47 ` [PATCH v26 2/9] x86/cet/ibt: Add user-mode Indirect Branch Tracking support Yu-cheng Yu
2021-04-28 20:30 ` Kees Cook
2021-04-27 20:47 ` [PATCH v26 3/9] x86/cet/ibt: Handle signals for Indirect Branch Tracking Yu-cheng Yu
2021-04-28 20:31 ` Kees Cook
2021-04-27 20:47 ` [PATCH v26 4/9] x86/cet/ibt: Update ELF header parsing " Yu-cheng Yu
2021-04-28 20:31 ` Kees Cook
2021-04-27 20:47 ` [PATCH v26 5/9] x86/cet/ibt: Update arch_prctl functions " Yu-cheng Yu
2021-04-27 20:47 ` [PATCH v26 6/9] x86/vdso: Insert endbr32/endbr64 to vDSO Yu-cheng Yu
2021-04-28 20:33 ` Kees Cook
2021-04-28 20:49 ` Yu, Yu-cheng
2021-04-28 20:38 ` Kees Cook
2021-04-27 20:47 ` [PATCH v26 7/9] x86/vdso: Introduce ENDBR macro Yu-cheng Yu
2021-04-28 20:33 ` Kees Cook
2021-04-27 20:47 ` [PATCH v26 8/9] x86/vdso/32: Add ENDBR to __kernel_vsyscall entry point Yu-cheng Yu
2021-04-28 20:33 ` Kees Cook
2021-04-28 20:39 ` Kees Cook
2021-04-27 20:47 ` [PATCH v26 9/9] x86/vdso: Add ENDBR to __vdso_sgx_enter_enclave Yu-cheng Yu
2021-04-28 20:39 ` Kees Cook
2021-04-28 14:48 ` [PATCH v26 0/9] Control-flow Enforcement: Indirect Branch Tracking David Laight
2021-04-28 14:52 ` Andy Lutomirski [this message]
2021-04-28 14:52 ` Andy Lutomirski
2021-04-28 14:56 ` H.J. Lu
2021-04-28 14:56 ` H.J. Lu
2021-04-28 15:14 ` Andy Lutomirski
2021-04-28 15:14 ` Andy Lutomirski
2021-04-28 15:33 ` David Laight
2021-04-28 16:24 ` Yu, Yu-cheng
2021-04-28 17:15 ` H.J. Lu
2021-04-28 17:15 ` H.J. Lu
2021-04-28 15:42 ` Yu, Yu-cheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrUpZfznXzN3Ld33DMvQcHD2ACnhYf9KdP+5-xXuX_pVpA@mail.gmail.com \
--to=luto@kernel.org \
--cc=Dave.Martin@arm.com \
--cc=David.Laight@aculab.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=bsingharora@gmail.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=esyr@redhat.com \
--cc=fweimer@redhat.com \
--cc=gorcunov@gmail.com \
--cc=haitao.huang@intel.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=oleg@redhat.com \
--cc=pavel@ucw.cz \
--cc=pengfei.xu@intel.com \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=rdunlap@infradead.org \
--cc=tglx@linutronix.de \
--cc=vedvyas.shanbhogue@intel.com \
--cc=weijiang.yang@intel.com \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.