Re: [RFC][PATCH 08/10] x86/mm: do not forbid _PAGE_RW before init for __ro_after_init

2018-02-22 Thread Kees Cook
On Thu, Feb 22, 2018 at 12:37 PM, Dave Hansen wrote: > > From: Dave Hansen > > __ro_after_init data gets stuck in the .rodata section. That's normally > fine because the kernel itself manages the R/W properties. > > But, if we run

Re: [RFC][PATCH 08/10] x86/mm: do not forbid _PAGE_RW before init for __ro_after_init

2018-02-22 Thread Kees Cook
On Thu, Feb 22, 2018 at 12:37 PM, Dave Hansen wrote: > > From: Dave Hansen > > __ro_after_init data gets stuck in the .rodata section. That's normally > fine because the kernel itself manages the R/W properties. > > But, if we run __change_page_attr() on an area which is __ro_after_init, > the

[RFC][PATCH 08/10] x86/mm: do not forbid _PAGE_RW before init for __ro_after_init

2018-02-22 Thread Dave Hansen
From: Dave Hansen __ro_after_init data gets stuck in the .rodata section. That's normally fine because the kernel itself manages the R/W properties. But, if we run __change_page_attr() on an area which is __ro_after_init, the .rodata checks will trigger and force

[RFC][PATCH 08/10] x86/mm: do not forbid _PAGE_RW before init for __ro_after_init

2018-02-22 Thread Dave Hansen
From: Dave Hansen __ro_after_init data gets stuck in the .rodata section. That's normally fine because the kernel itself manages the R/W properties. But, if we run __change_page_attr() on an area which is __ro_after_init, the .rodata checks will trigger and force the area to be immediately