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

On Thu, Apr 12, 2018 at 6:09 AM, Justin Forbes wrote: > On Wed, Apr 11, 2018, 5:38 PM Linus Torvalds > wrote: >> >> So it's really the whole claim that distributions have been running >> for this for the last five years that I wonder about,

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

On Thu, Apr 12, 2018 at 6:09 AM, Justin Forbes wrote: > On Wed, Apr 11, 2018, 5:38 PM Linus Torvalds > wrote: >> >> So it's really the whole claim that distributions have been running >> for this for the last five years that I wonder about, and how often >> people end up being told: "just

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

On Wed, Apr 11, 2018, 5:38 PM Linus Torvalds wrote: > > On Wed, Apr 11, 2018 at 2:05 PM, Jordan Glover > wrote: > >> > >> If that /dev/mem access prevention was just instead done as an even > >> stricter mode of the existing

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

On Wed, Apr 11, 2018, 5:38 PM Linus Torvalds wrote: > > On Wed, Apr 11, 2018 at 2:05 PM, Jordan Glover > wrote: > >> > >> If that /dev/mem access prevention was just instead done as an even > >> stricter mode of the existing CONFIG_STRICT_DEVMEM, it could just be > >> enabled unconditionally. >

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

On Wed, Apr 11, 2018 at 9:24 AM, David Howells wrote: > > (*) CONFIG_LOCK_DOWN_KERNEL > > This makes lockdown available and applies it to all the points that > need to be locked down if the mode is set. Lockdown mode can be > enabled by providing: > >

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

On Wed, Apr 11, 2018 at 9:24 AM, David Howells wrote: > > (*) CONFIG_LOCK_DOWN_KERNEL > > This makes lockdown available and applies it to all the points that > need to be locked down if the mode is set. Lockdown mode can be > enabled by providing: > > lockdown=1 By doing

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

On Wed, Apr 11, 2018 at 2:05 PM, Jordan Glover wrote: >> >> If that /dev/mem access prevention was just instead done as an even >> stricter mode of the existing CONFIG_STRICT_DEVMEM, it could just be >> enabled unconditionally. > > CONFIG_DEVMEM=n It's actually

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

On Wed, Apr 11, 2018 at 2:05 PM, Jordan Glover wrote: >> >> If that /dev/mem access prevention was just instead done as an even >> stricter mode of the existing CONFIG_STRICT_DEVMEM, it could just be >> enabled unconditionally. > > CONFIG_DEVMEM=n It's actually CONFIG_DEVMEM, CONFIG_DEVKMEM and

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

On April 11, 2018 8:09 PM, Linus Torvalds wrote: > On Wed, Apr 11, 2018 at 9:24 AM, David Howells dhowe...@redhat.com wrote: > > > Provide a single call to allow kernel code to determine whether the system > > > > should be locked down, thereby disallowing

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

On April 11, 2018 8:09 PM, Linus Torvalds wrote: > On Wed, Apr 11, 2018 at 9:24 AM, David Howells dhowe...@redhat.com wrote: > > > Provide a single call to allow kernel code to determine whether the system > > > > should be locked down, thereby disallowing various accesses that might > > > >

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

On Wed, Apr 11, 2018 at 7:37 PM, Randy Dunlap wrote: > On 04/11/2018 09:24 AM, David Howells wrote: > >> diff --git a/security/lock_down.c b/security/lock_down.c >> new file mode 100644 >> index ..f35ffdd096ad >> --- /dev/null >> +++ b/security/lock_down.c >> @@

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

On Wed, Apr 11, 2018 at 7:37 PM, Randy Dunlap wrote: > On 04/11/2018 09:24 AM, David Howells wrote: > >> diff --git a/security/lock_down.c b/security/lock_down.c >> new file mode 100644 >> index ..f35ffdd096ad >> --- /dev/null >> +++ b/security/lock_down.c >> @@ -0,0 +1,65 @@ >> +/*

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

On Wed, Apr 11, 2018 at 08:50:00PM +0200, Miguel Ojeda wrote: > On Wed, Apr 11, 2018 at 7:37 PM, Randy Dunlap wrote: > > On 04/11/2018 09:24 AM, David Howells wrote: > > > >> diff --git a/security/lock_down.c b/security/lock_down.c > >> new file mode 100644 > >> index

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

On Wed, Apr 11, 2018 at 08:50:00PM +0200, Miguel Ojeda wrote: > On Wed, Apr 11, 2018 at 7:37 PM, Randy Dunlap wrote: > > On 04/11/2018 09:24 AM, David Howells wrote: > > > >> diff --git a/security/lock_down.c b/security/lock_down.c > >> new file mode 100644 > >> index ..f35ffdd096ad >

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

On Wed, Apr 11, 2018 at 1:09 PM, Linus Torvalds wrote: > On Wed, Apr 11, 2018 at 9:24 AM, David Howells wrote: >> Provide a single call to allow kernel code to determine whether the system >> should be locked down, thereby disallowing various

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

On Wed, Apr 11, 2018 at 1:09 PM, Linus Torvalds wrote: > On Wed, Apr 11, 2018 at 9:24 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

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

On Wed, Apr 11, 2018 at 9:24 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: > > -

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

On Wed, Apr 11, 2018 at 9:24 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: > > - /dev/mem and similar > -

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

Randy Dunlap wrote: > > + drivers from functioning because allowing manual configuration of > > + hardware parameters is forbidden, lest a device be used to access the > > + kernel by DMA. This mostly applies to ISA devices. > > Is DMA from non-ISA

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

Randy Dunlap wrote: > > + drivers from functioning because allowing manual configuration of > > + hardware parameters is forbidden, lest a device be used to access the > > + kernel by DMA. This mostly applies to ISA devices. > > Is DMA from non-ISA devices OK, or did I miss

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

On 04/11/2018 09:24 AM, David Howells wrote: > --- > > arch/x86/kernel/setup.c |2 + > include/linux/kernel.h | 32 +++ > security/Kconfig| 23 - > security/Makefile |3 ++ > security/lock_down.c| 65 >

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

On 04/11/2018 09:24 AM, David Howells wrote: > --- > > arch/x86/kernel/setup.c |2 + > include/linux/kernel.h | 32 +++ > security/Kconfig| 23 - > security/Makefile |3 ++ > security/lock_down.c| 65 >

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

On Wed, Apr 11, 2018 at 6:24 PM, 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: > > -

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

On Wed, Apr 11, 2018 at 6:24 PM, 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: > > - /dev/mem and similar > -