* Ingo Molnar <mi...@kernel.org> wrote:
>
> * Matt Fleming <m...@codeblueprint.co.uk> wrote:
>
> > > > Right, we could do that, but then we wouldn't be able to support
> > > > creation/updating variables at runtime, such as when you install a
> > > > distribution for the first time, or want to boot a new kernel filename
> > > > directly from the firmware without a boot loader (and need to modify
> > > > the
> > > > BootXXXX variables).
> > >
> > > Do we know the precise position and address range of these variables?
> > >
> > > We could map them writable (but not executable), and the rest executable
> > > (but
> > > not writable).
> >
> > The variables are stored in NVRAM, which we don't map into the kernel
> > virtual
> > address space. [...]
>
> Just curious: is there firmware that memory maps those variables privately?
>
> > [...] We have to initiate the transaction of writing to the variables by
> > executing EFI runtime services.
> >
> > We obviously have buffers that we pass to the BIOS that contain variable
> > data,
> > but these should be NX anyway because they're regular kernel allocations.
> >
> > > That raises the question whether the same physical page ever mixes
> > > variables
> > > and actual code - but the hope would be that it's suffiently page
> > > granular for
> > > this to work.
> >
> > I don't think that would ever happen.
>
> Ok, that's promising, so how about this then to solve the security weakness
> the
> new warning unearthed: map the whole EFI range as 'r-x (NX)', but detect
> writes
> from the page fault handler and transparently allow them to flip over the
> range
> to 'rw-'.
So I meant to say 'page' instead of 'range'.
I.e. this dynamic mechanism would flip pages over to 'rw-', as write faults
occur
from EFI code that writes to them.
We don't need to know which regions are writable data, and which regions are
executable-code/readonly-data.
The following aspect would guarantee safety:
> Note that for security reasons we don't allow a subsequent flipping back to
> NX
> if there's an NX fault on the same page, i.e. this new mechanism is a
> monotonic
> one-way process that should dynamically 'map out' data pages versus
> executable
> pages.
>
> It should also be pretty robust, assuming we can take page faults while EFI
> code
> is executing and is trying to modify EFI data: is that the case?
and this is why I asked whether boundaries between 'Code' and 'Writable data'
sections are page granular - which they do appear to be. (i.e. there are no
singular pages that are both writable data and code at once.)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
