[coreboot] I've turned on paging as a test
Kevin O'Connor
kevin at koconnor.net
Sat Mar 15 18:22:14 CET 2014
On Wed, Mar 12, 2014 at 09:12:05PM +0100, Stefan Reinauer wrote:
> * Peter Stuge <peter at stuge.se> [140312 19:08]:
> > ron minnich wrote:
> > > For the base identity map on x86-32, it's one page for 4G.
> > > For a map which locks out page 0, it's two pages.
> >
> > I think it would be great if you could write up what you actually
> > want to accomplish.
>
> - be able to run code at any address without run time
> linking/relocating. This can also greatly simplify the way
> we do romstage today (which can't be moved inside the CBFS, for
> example)
Why can't romstage be moved into CBFS? Is this in reference to one of
the non X86 platforms?
Implementing relocation via page tables seems reminiscent of UEFI, and
I'm sure you can imagine my reaction to that.
For what it's worth, SeaBIOS implements self relocation and the code
to do that is about 100 lines (see src/post.c:reloc_preinit() and
scripts/layoutrom.py:getRelocs() ). This wouldn't work for romstage,
but self relocation isn't too difficult for code that runs in ram.
> - be able to write protect code, eg prevent exploits to rewrite code.
> - catch NULL pointer accesses
> - catch writes to non-designated memory, e.g. overwriting OS
> memory on resume
In these fault situations, what can be done though? If the basic boot
system fails, the machine is a brick regardless of whether or not it
caught itself failing.
> - run in 64 bit mode, for easy addressing of memory / devices,
> have more registers available for more compact code, etc.
Agreed. I don't see any problems with a 1:1 page mapping where it's
useful.
-Kevin
More information about the coreboot
mailing list