Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Fri, May 26, 2017 at 01:43:12PM +0100, David Howells wrote: > Casey Schaufler wrote: > > > You called out five distinct features in 0/5, so how about > > a bit for each of those? > > Actually, there are more than five in that list - there are three in the first > item

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Fri, May 26, 2017 at 01:43:12PM +0100, David Howells wrote: > Casey Schaufler wrote: > > > You called out five distinct features in 0/5, so how about > > a bit for each of those? > > Actually, there are more than five in that list - there are three in the first > item - and I'm not sure the

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

Casey Schaufler wrote: > You called out five distinct features in 0/5, so how about > a bit for each of those? Actually, there are more than five in that list - there are three in the first item - and I'm not sure the remaining categories are quite as well defined as I

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

Casey Schaufler wrote: > You called out five distinct features in 0/5, so how about > a bit for each of those? Actually, there are more than five in that list - there are three in the first item - and I'm not sure the remaining categories are quite as well defined as I made it seem. Also, that

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Wed, May 24, 2017 at 03:45:45PM +0100, David Howells wrote: > Provide a single call to allow kernel code to determine whether the system > should be locked down, thereby disallowing various accesses that might > allow the running kernel image to be changed including the loading of > modules

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Wed, May 24, 2017 at 03:45:45PM +0100, David Howells wrote: > Provide a single call to allow kernel code to determine whether the system > should be locked down, thereby disallowing various accesses that might > allow the running kernel image to be changed including the loading of > modules

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On 5/24/2017 11:53 PM, David Howells wrote: > Casey Schaufler wrote: > >>> +#ifdef CONFIG_LOCK_DOWN_KERNEL >>> +extern bool kernel_is_locked_down(void); >>> +#else >>> +static inline bool kernel_is_locked_down(void) >> Should this be a bool or an int? I can imagine that

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On 5/24/2017 11:53 PM, David Howells wrote: > Casey Schaufler wrote: > >>> +#ifdef CONFIG_LOCK_DOWN_KERNEL >>> +extern bool kernel_is_locked_down(void); >>> +#else >>> +static inline bool kernel_is_locked_down(void) >> Should this be a bool or an int? I can imagine that someone is going to want

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

Casey Schaufler wrote: > > +#ifdef CONFIG_LOCK_DOWN_KERNEL > > +extern bool kernel_is_locked_down(void); > > +#else > > +static inline bool kernel_is_locked_down(void) > > Should this be a bool or an int? I can imagine that someone is going to want > various different

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

Casey Schaufler wrote: > > +#ifdef CONFIG_LOCK_DOWN_KERNEL > > +extern bool kernel_is_locked_down(void); > > +#else > > +static inline bool kernel_is_locked_down(void) > > Should this be a bool or an int? I can imagine that someone is going to want > various different degrees of lock down for

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On 5/24/2017 7:45 AM, David Howells wrote: > Provide a single call to allow kernel code to determine whether the system > should be locked down, thereby disallowing various accesses that might > allow the running kernel image to be changed including the loading of > modules that aren't validly

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On 5/24/2017 7:45 AM, David Howells wrote: > Provide a single call to allow kernel code to determine whether the system > should be locked down, thereby disallowing various accesses that might > allow the running kernel image to be changed including the loading of > modules that aren't validly

[PATCH 3/5] Add the ability to lock down access to the running kernel image

Provide a single call to allow kernel code to determine whether the system should be locked down, thereby disallowing various accesses that might allow the running kernel image to be changed including the loading of modules that aren't validly signed with a key we recognise, fiddling with MSR

[PATCH 3/5] Add the ability to lock down access to the running kernel image

Provide a single call to allow kernel code to determine whether the system should be locked down, thereby disallowing various accesses that might allow the running kernel image to be changed including the loading of modules that aren't validly signed with a key we recognise, fiddling with MSR

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Thu, 6 Apr 2017, David Howells wrote: > Provide a single call to allow kernel code to determine whether the system > should be locked down, thereby disallowing various accesses that might > allow the running kernel image to be changed including the loading of > modules that aren't validly

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Thu, 6 Apr 2017, David Howells wrote: > Provide a single call to allow kernel code to determine whether the system > should be locked down, thereby disallowing various accesses that might > allow the running kernel image to be changed including the loading of > modules that aren't validly

[PATCH 3/5] Add the ability to lock down access to the running kernel image

Provide a single call to allow kernel code to determine whether the system should be locked down, thereby disallowing various accesses that might allow the running kernel image to be changed including the loading of modules that aren't validly signed with a key we recognise, fiddling with MSR

[PATCH 3/5] Add the ability to lock down access to the running kernel image

Provide a single call to allow kernel code to determine whether the system should be locked down, thereby disallowing various accesses that might allow the running kernel image to be changed including the loading of modules that aren't validly signed with a key we recognise, fiddling with MSR