From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function Date: Fri, 14 Jun 2019 13:57:40 -0700 Message-ID: <598edca7-c36a-a236-3b72-08b2194eb609@intel.com> References: <20190606200926.4029-1-yu-cheng.yu@intel.com> <34E0D316-552A-401C-ABAA-5584B5BC98C5@amacapital.net> <7e0b97bf1fbe6ff20653a8e4e147c6285cc5552d.camel@intel.com> <25281DB3-FCE4-40C2-BADB-B3B05C5F8DD3@amacapital.net> <3f19582d-78b1-5849-ffd0-53e8ca747c0d@intel.com> <5aa98999b1343f34828414b74261201886ec4591.camel@intel.com> <0665416d-9999-b394-df17-f2a5e1408130@intel.com> <5c8727dde9653402eea97bfdd030c479d1e8dd99.camel@intel.com> <328275c9b43c06809c9937c83d25126a6e3efcbd.camel@intel.com> <92e56b28-0cd4-e3f4-867b-639d9b98b86c@intel.com> <1b961c71d30e31ecb22da2c5401b1a81cb802d86.camel@intel.com> <5ddf59e2-c701-3741-eaa1-f63ee741ea55@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Yu-cheng Yu , Andy Lutomirski Cc: Peter Zijlstra , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , 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 , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit List-Id: linux-arch.vger.kernel.org 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? > 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. 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com ([192.55.52.93]:18334 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725809AbfFNU5l (ORCPT ); Fri, 14 Jun 2019 16:57:41 -0400 Subject: Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function References: <20190606200926.4029-1-yu-cheng.yu@intel.com> <34E0D316-552A-401C-ABAA-5584B5BC98C5@amacapital.net> <7e0b97bf1fbe6ff20653a8e4e147c6285cc5552d.camel@intel.com> <25281DB3-FCE4-40C2-BADB-B3B05C5F8DD3@amacapital.net> <3f19582d-78b1-5849-ffd0-53e8ca747c0d@intel.com> <5aa98999b1343f34828414b74261201886ec4591.camel@intel.com> <0665416d-9999-b394-df17-f2a5e1408130@intel.com> <5c8727dde9653402eea97bfdd030c479d1e8dd99.camel@intel.com> <328275c9b43c06809c9937c83d25126a6e3efcbd.camel@intel.com> <92e56b28-0cd4-e3f4-867b-639d9b98b86c@intel.com> <1b961c71d30e31ecb22da2c5401b1a81cb802d86.camel@intel.com> <5ddf59e2-c701-3741-eaa1-f63ee741ea55@intel.com> From: Dave Hansen Message-ID: <598edca7-c36a-a236-3b72-08b2194eb609@intel.com> Date: Fri, 14 Jun 2019 13:57:40 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Yu-cheng Yu , Andy Lutomirski Cc: Peter Zijlstra , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , 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 , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin Message-ID: <20190614205740.xOrSJNH-LsNprMVrQbMQtwi_vomAudjMuzmM-eUcrRo@z> 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? > 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. 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.