Re: [PATCH] x86/intel/quark: Parameterize the kernel's IMR lock logic

2016-02-18 Thread Bryan O'Donoghue
On Thu, 2016-02-18 at 19:53 +0100, Ingo Molnar wrote: > * Bryan O'Donoghue wrote: > > > On Thu, 2016-02-18 at 08:58 +0100, Ingo Molnar wrote: > > > So why not simply do the patch below? Very few people use boot > > > parameters, and the > > > complexity does not seem to be worth it. > > > > > >

Re: [PATCH] x86/intel/quark: Parameterize the kernel's IMR lock logic

2016-02-18 Thread Ingo Molnar
* Bryan O'Donoghue wrote: > On Thu, 2016-02-18 at 08:58 +0100, Ingo Molnar wrote: > > So why not simply do the patch below? Very few people use boot > > parameters, and the > > complexity does not seem to be worth it. > > > > Furthermore I think an IMR range in itself is safe enough - it's not

Re: [PATCH] x86/intel/quark: Parameterize the kernel's IMR lock logic

2016-02-18 Thread Bryan O'Donoghue
On Thu, 2016-02-18 at 08:58 +0100, Ingo Molnar wrote: > So why not simply do the patch below? Very few people use boot > parameters, and the > complexity does not seem to be worth it. > > Furthermore I think an IMR range in itself is safe enough - it's not > like such > register state is going t

Re: [PATCH] x86/intel/quark: Parameterize the kernel's IMR lock logic

2016-02-17 Thread Ingo Molnar
* Bryan O'Donoghue wrote: > Currently when setting up an IMR around the kernel's .text area we lock > that IMR, preventing further modification. While superficially this appears > to be the right thing to do, in fact this doesn't account for a legitimate > change in the memory map such as when e

[PATCH] x86/intel/quark: Parameterize the kernel's IMR lock logic

2016-02-17 Thread Bryan O'Donoghue
Currently when setting up an IMR around the kernel's .text area we lock that IMR, preventing further modification. While superficially this appears to be the right thing to do, in fact this doesn't account for a legitimate change in the memory map such as when executing a new kernel via kexec. In