On Fri, Jan 22, 2016 at 1:08 PM, Bryan O'Donoghue <pure.logic@xxxxxxxxxxxxxxxxx> wrote: > On Thu, 2016-01-21 at 20:44 +0200, Andy Shevchenko wrote: >> On Thu, Jan 21, 2016 at 4:05 PM, Bryan O'Donoghue >> <pure.logic@xxxxxxxxxxxxxxxxx> wrote: [] >> > The solution to this situation is to keep the kernel .text section >> > IMR lock >> > bit false. This means that a subsequent kernel will boot and can >> > tear-down >> > an existing IMR, while still setting up an IMR around its own .text >> > section. >> > >> >> Like I said you privately it would be nice to have a knob how to >> behave. > > Ok - that can work. The default ought to be !locked and we can > parametrize a different behaviour. > > >> My idea is to provide kernel command line imr= and supply imr=lock >> when user wants to boot kernel locked. > > Agreed. > >> >> Optionally: add a warning if imr=lock and kernel build with kexec >> that >> might bring issues > > This makes sense. > >> Optionally: add a kernel config option to boot always in locked mode >> (should depend on !KEXEC) > > Meh. You can still force the state you want with the parameter though. > I reckon we should skip this change for now. OK! P.S. Please, use my @linux.intel.com address in the tags. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html