All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Peter Zijlstra <peterz@infradead.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-doc@vger.kernel.org,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Andy Lutomirski <luto@amacapital.net>,
	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>
Subject: Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
Date: Tue, 11 Jun 2019 12:33:16 +0200	[thread overview]
Message-ID: <20190611103316.GA20775@amd> (raw)
In-Reply-To: <e1543e7beb0eb55d6febcd847ccab9b219e60338.camel@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On Mon 2019-06-10 08:47:45, Yu-cheng Yu wrote:
> On Sat, 2019-06-08 at 22:52 +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > > I've no idea what the kernel should do; since you failed to answer the
> > > > question what happens when you point this to garbage.
> > > > 
> > > > Does it then fault or what?
> > > 
> > > Yeah, I think you'll fault with a rather mysterious CR2 value since
> > > you'll go look at the instruction that faulted and not see any
> > > references to the CR2 value.
> > > 
> > > I think this new MSR probably needs to get included in oops output when
> > > CET is enabled.
> > > 
> > > Why don't we require that a VMA be in place for the entire bitmap?
> > > Don't we need a "get" prctl function too in case something like a JIT is
> > > running and needs to find the location of this bitmap to set bits itself?
> > > 
> > > Or, do we just go whole-hog and have the kernel manage the bitmap
> > > itself. Our interface here could be:
> > > 
> > > 	prctl(PR_MARK_CODE_AS_LEGACY, start, size);
> > > 
> > > and then have the kernel allocate and set the bitmap for those code
> > > locations.
> > 
> > For the record, that sounds like a better interface than userspace knowing
> > about the bitmap formats...
> > 									Pavel
> 
> Initially we implemented the bitmap that way.  To manage the bitmap, every time
> the application issues a syscall for a .so it loads, and the kernel does
> copy_from_user() & copy_to_user() (or similar things).  If a system has a few
> legacy .so files and every application does the same, it can take a long time to
> boot up.

Loading .so is already many syscalls, I'd not expect measurable
performance there. Are you sure?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Peter Zijlstra <peterz@infradead.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-doc@vger.kernel.org,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Andy Lutomirski <luto@amacapital.net>,
	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>,
	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>
Subject: Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
Date: Tue, 11 Jun 2019 12:33:16 +0200	[thread overview]
Message-ID: <20190611103316.GA20775@amd> (raw)
Message-ID: <20190611103316.fn1zcgv-C4YaV-wrxSNdP735FA-qGnulm1PO7i3YekU@z> (raw)
In-Reply-To: <e1543e7beb0eb55d6febcd847ccab9b219e60338.camel@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On Mon 2019-06-10 08:47:45, Yu-cheng Yu wrote:
> On Sat, 2019-06-08 at 22:52 +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > > I've no idea what the kernel should do; since you failed to answer the
> > > > question what happens when you point this to garbage.
> > > > 
> > > > Does it then fault or what?
> > > 
> > > Yeah, I think you'll fault with a rather mysterious CR2 value since
> > > you'll go look at the instruction that faulted and not see any
> > > references to the CR2 value.
> > > 
> > > I think this new MSR probably needs to get included in oops output when
> > > CET is enabled.
> > > 
> > > Why don't we require that a VMA be in place for the entire bitmap?
> > > Don't we need a "get" prctl function too in case something like a JIT is
> > > running and needs to find the location of this bitmap to set bits itself?
> > > 
> > > Or, do we just go whole-hog and have the kernel manage the bitmap
> > > itself. Our interface here could be:
> > > 
> > > 	prctl(PR_MARK_CODE_AS_LEGACY, start, size);
> > > 
> > > and then have the kernel allocate and set the bitmap for those code
> > > locations.
> > 
> > For the record, that sounds like a better interface than userspace knowing
> > about the bitmap formats...
> > 									Pavel
> 
> Initially we implemented the bitmap that way.  To manage the bitmap, every time
> the application issues a syscall for a .so it loads, and the kernel does
> copy_from_user() & copy_to_user() (or similar things).  If a system has a few
> legacy .so files and every application does the same, it can take a long time to
> boot up.

Loading .so is already many syscalls, I'd not expect measurable
performance there. Are you sure?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2019-06-11 10:33 UTC|newest]

Thread overview: 144+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-06 20:09 [PATCH v7 00/14] Control-flow Enforcement: Branch Tracking, PTRACE Yu-cheng Yu
2019-06-06 20:09 ` Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 01/14] x86/cet/ibt: Add Kconfig option for user-mode Indirect Branch Tracking Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 02/14] x86/cet/ibt: User-mode indirect branch tracking support Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-07  8:08   ` Peter Zijlstra
2019-06-07  8:08     ` Peter Zijlstra
2019-06-07 16:23     ` Yu-cheng Yu
2019-06-07 16:23       ` Yu-cheng Yu
2019-06-07 16:35       ` Andy Lutomirski
2019-06-07 16:35         ` Andy Lutomirski
2019-06-07 16:39         ` Dave Hansen
2019-06-07 16:39           ` Dave Hansen
2019-06-07 16:45         ` Yu-cheng Yu
2019-06-07 16:45           ` Yu-cheng Yu
2019-06-07 17:05           ` Andy Lutomirski
2019-06-07 17:05             ` Andy Lutomirski
2019-06-07 17:43       ` Peter Zijlstra
2019-06-07 17:43         ` Peter Zijlstra
2019-06-07 17:59         ` Dave Hansen
2019-06-07 17:59           ` Dave Hansen
2019-06-07 18:29           ` Andy Lutomirski
2019-06-07 18:29             ` Andy Lutomirski
2019-06-07 18:58             ` Dave Hansen
2019-06-07 18:58               ` Dave Hansen
2019-06-07 19:56               ` Yu-cheng Yu
2019-06-07 19:56                 ` Yu-cheng Yu
2019-06-07 20:40               ` Andy Lutomirski
2019-06-07 20:40                 ` Andy Lutomirski
2019-06-07 21:05                 ` Dave Hansen
2019-06-07 21:05                   ` Dave Hansen
2019-06-07 19:49             ` Yu-cheng Yu
2019-06-07 19:49               ` Yu-cheng Yu
2019-06-07 20:00               ` Dave Hansen
2019-06-07 20:00                 ` Dave Hansen
2019-06-07 20:06                 ` Yu-cheng Yu
2019-06-07 20:06                   ` Yu-cheng Yu
2019-06-07 21:09                   ` Dave Hansen
2019-06-07 21:09                     ` Dave Hansen
2019-06-07 22:27                     ` Andy Lutomirski
2019-06-07 22:27                       ` Andy Lutomirski
2019-06-10 16:03                       ` Yu-cheng Yu
2019-06-10 16:03                         ` Yu-cheng Yu
2019-06-10 16:05                     ` Yu-cheng Yu
2019-06-10 16:05                       ` Yu-cheng Yu
2019-06-10 17:28                       ` Florian Weimer
2019-06-10 17:28                         ` Florian Weimer
2019-06-10 17:59                       ` Dave Hansen
2019-06-10 17:59                         ` Dave Hansen
2019-06-07 20:43               ` Andy Lutomirski
2019-06-07 20:43                 ` Andy Lutomirski
2019-06-10 15:22                 ` Yu-cheng Yu
2019-06-10 15:22                   ` Yu-cheng Yu
2019-06-10 18:02                   ` Dave Hansen
2019-06-10 18:02                     ` Dave Hansen
2019-06-10 19:38                     ` Yu-cheng Yu
2019-06-10 19:38                       ` Yu-cheng Yu
2019-06-10 19:52                       ` Dave Hansen
2019-06-10 19:52                         ` Dave Hansen
2019-06-10 19:55                         ` Andy Lutomirski
2019-06-10 19:55                           ` Andy Lutomirski
2019-06-10 20:27                         ` Yu-cheng Yu
2019-06-10 20:27                           ` Yu-cheng Yu
2019-06-10 20:43                           ` Dave Hansen
2019-06-10 20:43                             ` Dave Hansen
2019-06-10 20:58                             ` Yu-cheng Yu
2019-06-10 20:58                               ` Yu-cheng Yu
2019-06-10 22:02                               ` Dave Hansen
2019-06-10 22:02                                 ` Dave Hansen
2019-06-10 22:40                                 ` Yu-cheng Yu
2019-06-10 22:40                                   ` Yu-cheng Yu
2019-06-10 22:59                                   ` Dave Hansen
2019-06-10 22:59                                     ` Dave Hansen
2019-06-10 23:20                                     ` H.J. Lu
2019-06-10 23:20                                       ` H.J. Lu
2019-06-10 23:37                                       ` Dave Hansen
2019-06-10 23:37                                         ` Dave Hansen
2019-06-10 23:54                                     ` Andy Lutomirski
2019-06-10 23:54                                       ` Andy Lutomirski
2019-06-11  0:08                                       ` Dave Hansen
2019-06-11  0:08                                         ` Dave Hansen
2019-06-11  0:36                                         ` Andy Lutomirski
2019-06-11  0:36                                           ` Andy Lutomirski
2019-06-14 15:25                                     ` Yu-cheng Yu
2019-06-14 15:25                                       ` Yu-cheng Yu
2019-06-14 16:13                                       ` Dave Hansen
2019-06-14 16:13                                         ` Dave Hansen
2019-06-14 17:13                                         ` Yu-cheng Yu
2019-06-14 17:13                                           ` Yu-cheng Yu
2019-06-14 20:57                                           ` Dave Hansen
2019-06-14 20:57                                             ` Dave Hansen
2019-06-14 21:34                                             ` Yu-cheng Yu
2019-06-14 21:34                                               ` Yu-cheng Yu
2019-06-14 22:06                                               ` Dave Hansen
2019-06-14 22:06                                                 ` Dave Hansen
2019-06-15 15:30                                                 ` Andy Lutomirski
2019-06-15 15:30                                                   ` Andy Lutomirski
2019-06-11  7:24                                 ` Florian Weimer
2019-06-11  7:24                                   ` Florian Weimer
2019-06-08 20:52           ` Pavel Machek
2019-06-08 20:52             ` Pavel Machek
2019-06-10 15:47             ` Yu-cheng Yu
2019-06-10 15:47               ` Yu-cheng Yu
2019-06-11 10:33               ` Pavel Machek [this message]
2019-06-11 10:33                 ` Pavel Machek
2019-06-07 19:03   ` Dave Hansen
2019-06-07 19:03     ` Dave Hansen
2019-06-07 19:23     ` Yu-cheng Yu
2019-06-07 19:23       ` Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 04/14] x86/cet/ibt: Handle signals for IBT Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 05/14] mm/mmap: Add IBT bitmap size to address space limit check Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 06/14] x86/cet/ibt: ELF header parsing for IBT Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 07/14] x86/cet/ibt: Add arch_prctl functions " Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-07  8:07   ` Peter Zijlstra
2019-06-07  8:07     ` Peter Zijlstra
2019-06-06 20:09 ` [PATCH v7 08/14] x86/cet/ibt: Add ENDBR to op-code-map Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 09/14] x86/vdso: Insert endbr32/endbr64 to vDSO Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:26   ` Andy Lutomirski
2019-06-06 20:26     ` Andy Lutomirski
2019-06-06 20:09 ` [PATCH v7 10/14] x86/vdso/32: Add ENDBR32 to __kernel_vsyscall entry point Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:25   ` Andy Lutomirski
2019-06-06 20:25     ` Andy Lutomirski
2019-06-06 20:09 ` [PATCH v7 11/14] x86/vsyscall/64: Add ENDBR64 to vsyscall entry points Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:28   ` Andy Lutomirski
2019-06-06 20:28     ` Andy Lutomirski
2019-06-06 20:09 ` [PATCH v7 12/14] x86/vsyscall/64: Fixup shadow stack and branch tracking for vsyscall Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:27   ` Andy Lutomirski
2019-06-06 20:27     ` Andy Lutomirski
2019-06-06 20:09 ` [PATCH v7 13/14] x86/cet: Add PTRACE interface for CET Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu
2019-06-06 20:09 ` [PATCH v7 14/14] x86: Discard .note.gnu.property sections Yu-cheng Yu
2019-06-06 20:09   ` Yu-cheng Yu

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=20190611103316.GA20775@amd \
    --to=pavel@ucw.cz \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=bsingharora@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=esyr@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=gorcunov@gmail.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=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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.