[coreboot] I've turned on paging as a test

[Stefan Reinauer]

> On Mar 15, 2014, at 10:22, Kevin O'Connor <kevin at koconnor.net> wrote:
> 
>> 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?

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
>