[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