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?
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