On Mar 15, 2014, at 10:22, Kevin O'Connor kevin@koconnor.net wrote:
On Wed, Mar 12, 2014 at 09:12:05PM +0100, Stefan Reinauer wrote:
- Peter Stuge peter@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?
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