Linux-mm Archive on lore.kernel.org
 help / color / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>,
	Andy Lutomirski <luto@amacapital.net>
Cc: 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>,
	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>,
	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: Mon, 10 Jun 2019 13:43:33 -0700
Message-ID: <ac9a20a6-170a-694e-beeb-605a17195034@intel.com> (raw)
In-Reply-To: <5c8727dde9653402eea97bfdd030c479d1e8dd99.camel@intel.com>

On 6/10/19 1:27 PM, Yu-cheng Yu wrote:
>>> If the loader cannot allocate a big bitmap to cover all 5-level
>>> address space (the bitmap will be large), it can put all legacy lib's
>>> at lower address.  We cannot do these easily in the kernel.
>> This is actually an argument to do it in the kernel.  The kernel can
>> always allocate the virtual space however it wants, no matter how large.
>>  If we hide the bitmap behind a kernel API then we can put it at high
>> 5-level user addresses because we also don't have to worry about the
>> high bits confusing userspace.
> We actually tried this.  The kernel needs to reserve the bitmap space in the
> beginning for every CET-enabled app, regardless of actual needs. 

I don't think this is a problem.  In fact, I think reserving the space
is actually the only sane behavior.  If you don't reserve it, you
fundamentally limit where future legacy instructions can go.

One idea is that we always size the bitmap for the 48-bit addressing
systems.  Legacy code probably doesn't _need_ to go in the new address
space, and if we do this we don't have to worry about the gigantic
57-bit address space bitmap.

> On each memory request, the kernel then must consider a percentage of
> allocated space in its calculation, and on systems with less memory
> this quickly becomes a problem.

I'm not sure what you're referring to here?  Are you referring to our
overcommit limits?


  reply index

Thread overview: 72+ 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 ` [PATCH v7 01/14] x86/cet/ibt: Add Kconfig option for user-mode Indirect Branch Tracking 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 ` [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function Yu-cheng Yu
2019-06-07  8:08   ` Peter Zijlstra
2019-06-07 16:23     ` Yu-cheng Yu
2019-06-07 16:35       ` Andy Lutomirski
2019-06-07 16:39         ` Dave Hansen
2019-06-07 16:45         ` Yu-cheng Yu
2019-06-07 17:05           ` Andy Lutomirski
2019-06-07 17:43       ` Peter Zijlstra
2019-06-07 17:59         ` Dave Hansen
2019-06-07 18:29           ` Andy Lutomirski
2019-06-07 18:58             ` Dave Hansen
2019-06-07 19:56               ` Yu-cheng Yu
2019-06-07 20:40               ` Andy Lutomirski
2019-06-07 21:05                 ` Dave Hansen
2019-06-07 19:49             ` Yu-cheng Yu
2019-06-07 20:00               ` Dave Hansen
2019-06-07 20:06                 ` Yu-cheng Yu
2019-06-07 21:09                   ` Dave Hansen
2019-06-07 22:27                     ` Andy Lutomirski
2019-06-10 16:03                       ` Yu-cheng Yu
2019-06-10 16:05                     ` Yu-cheng Yu
2019-06-10 17:28                       ` Florian Weimer
2019-06-10 17:59                       ` Dave Hansen
2019-06-07 20:43               ` Andy Lutomirski
2019-06-10 15:22                 ` Yu-cheng Yu
2019-06-10 18:02                   ` Dave Hansen
2019-06-10 19:38                     ` Yu-cheng Yu
2019-06-10 19:52                       ` Dave Hansen
2019-06-10 19:55                         ` Andy Lutomirski
2019-06-10 20:27                         ` Yu-cheng Yu
2019-06-10 20:43                           ` Dave Hansen [this message]
2019-06-10 20:58                             ` Yu-cheng Yu
2019-06-10 22:02                               ` Dave Hansen
2019-06-10 22:40                                 ` Yu-cheng Yu
2019-06-10 22:59                                   ` Dave Hansen
2019-06-10 23:20                                     ` H.J. Lu
2019-06-10 23:37                                       ` Dave Hansen
2019-06-10 23:54                                     ` Andy Lutomirski
2019-06-11  0:08                                       ` Dave Hansen
2019-06-11  0:36                                         ` Andy Lutomirski
2019-06-14 15:25                                     ` Yu-cheng Yu
2019-06-14 16:13                                       ` Dave Hansen
2019-06-14 17:13                                         ` Yu-cheng Yu
2019-06-14 20:57                                           ` Dave Hansen
2019-06-14 21:34                                             ` Yu-cheng Yu
2019-06-14 22:06                                               ` Dave Hansen
2019-06-15 15:30                                                 ` Andy Lutomirski
2019-06-11  7:24                                 ` Florian Weimer
2019-06-08 20:52           ` Pavel Machek
2019-06-10 15:47             ` Yu-cheng Yu
2019-06-11 10:33               ` Pavel Machek
2019-06-07 19:03   ` Dave Hansen
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 ` [PATCH v7 05/14] mm/mmap: Add IBT bitmap size to address space limit check 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 ` [PATCH v7 07/14] x86/cet/ibt: Add arch_prctl functions " Yu-cheng Yu
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 ` [PATCH v7 09/14] x86/vdso: Insert endbr32/endbr64 to vDSO Yu-cheng Yu
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: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: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: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 ` [PATCH v7 14/14] x86: Discard .note.gnu.property sections Yu-cheng Yu

Reply instructions:

You may reply publically 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=ac9a20a6-170a-694e-beeb-605a17195034@intel.com \
    --to=dave.hansen@intel.com \
    --cc=Dave.Martin@arm.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=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=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=oleg@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=rdunlap@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=vedvyas.shanbhogue@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

Linux-mm Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \
		linux-mm@kvack.org linux-mm@archiver.kernel.org
	public-inbox-index linux-mm


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kvack.linux-mm


AGPL code for this site: git clone https://public-inbox.org/ public-inbox