Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1314896
| From | Bryan O'Donoghue <pure.logic@nexus-software.ie> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] x86/intel/quark: Remove lock bit around kernel IMR |
| Date | 2016-01-22 12:10 +0100 |
| Message-ID | <qTHLk-3dT-33@gated-at.bofh.it> (permalink) |
| References | <qTofE-6n5-7@gated-at.bofh.it> <qTssX-M0-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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@nexus-software.ie> 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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] x86/intel/quark: Remove lock bit around kernel IMR Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2016-01-21 15:20 +0100
Re: [PATCH] x86/intel/quark: Remove lock bit around kernel IMR Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-01-21 19:50 +0100
Re: [PATCH] x86/intel/quark: Remove lock bit around kernel IMR Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2016-01-22 12:10 +0100
Re: [PATCH] x86/intel/quark: Remove lock bit around kernel IMR Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-01-22 13:20 +0100
csiph-web