> On Mar 15, 2014, at 10:22, Kevin O'Connor <[email protected]> wrote: > >> On Wed, Mar 12, 2014 at 09:12:05PM +0100, Stefan Reinauer wrote: >> * Peter Stuge <[email protected]> [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?
Romstage is in CBFS but it's linked to its final position and can't be moved > > 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. coreboot does that too with relocatable ramstage > >> - 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 > -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
