Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function - Yu-cheng Yu

From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Dave Hansen <dave.hansen@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: Fri, 14 Jun 2019 14:34:12 -0700	[thread overview]
Message-ID: <359e6f64d646d5305c52f393db5296c469630d11.camel@intel.com> (raw)
In-Reply-To: <598edca7-c36a-a236-3b72-08b2194eb609@intel.com>

On Fri, 2019-06-14 at 13:57 -0700, Dave Hansen wrote:
> On 6/14/19 10:13 AM, Yu-cheng Yu wrote:
> > On Fri, 2019-06-14 at 09:13 -0700, Dave Hansen wrote:
> > > On 6/14/19 8:25 AM, Yu-cheng Yu wrote:
> > > > The bitmap is very big.
> > > 
> > > Really?  It's actually, what, 8*4096=32k, so 1/32,768th of the size of
> > > the libraries legacy libraries you load?  Do our crash dumps really not
> > > know how to represent or deal with sparse mappings?
> > 
> > Ok, even the core dump is not physically big, its size still looks odd,
> > right?
> 
> Hell if I know.
> 
> Could you please go try this in practice so that we're designing this
> thing fixing real actual problems instead of phantoms that we're
> anticipating?
> 
> > Could this also affect how much time for GDB to load it.
> 
> I don't know.  Can you go find out for sure, please?

OK!

> 
> > I have a related question:
> > 
> > Do we allow the application to read the bitmap, or any fault from the
> > application on bitmap pages?
> 
> We have to allow apps to read it.  Otherwise they can't execute
> instructions.

What I meant was, if an app executes some legacy code that results in bitmap
lookup, but the bitmap page is not yet populated, and if we then populate that
page with all-zero, a #CP should follow.  So do we even populate that zero page
at all?

I think we should; a #CP is more obvious to the user at least.

> 
> We don't have to allow them to (popuating) fault on it.  But, if we
> don't, we need some kind of kernel interface to avoid the faults.

The plan is:

* Move STACK_TOP (and vdso) down to give space to the bitmap.

* Reserve the bitmap space from (mm->start_stack + PAGE_SIZE) to cover a code
size of TASK_SIZE_LOW, which is (TASK_SIZE_LOW / PAGE_SIZE / 8).

* Mmap the space only when the app issues the first mark-legacy prctl.  This
avoids the core-dump issue for most apps and the accounting problem that
MAP_NORESERVE probably won't solve completely.

* The bitmap is read-only.  The kernel sets the bitmap with
get_user_pages_fast(FOLL_WRITE) and user_access_begin()/user_addess_end().

I will send out a RFC patch.

Yu-cheng