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: > > Currently when setting up an IMR around the kernel .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 running through kexec. In > > such a > > scenario a second kernel can have a different size and location to > > it's > > predecessor and can view some of the memory occupied by its > > predecessor as > > legitimately usable RAM. This RAM can then be allocated to DMA > > agents > > within the system and trigger an IMR violation. > > > > 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. --- bod -- 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