ron minnich wrote:
[on arm]
Why is it helpful or neccessary there?
It only matters if you like to have a dcache. Do you want a dcache?
What are the numbers?
On PPC, you have no choice
Not much effort going into that in coreboot these days, so might not be a big concern.
We will have to have it on x86_64.
Why is it neccessary there?
It only matters if you want to enter 64-bit mode.
(Why) Does coreboot need to do so?
- MTRRs sure make for a lot of fuss.
- I wish we could do something simpler.
- Let's turn on paging, that would be simpler!
And, in fact, it is. It's far, far simpler.
I am not dismissing the thought that it is simpler.
I am trying to say that *despite paging being simpler* there are (several) more things to think of, which are not being mentioned and so how would anyone know if they've been considered?
Just look at our last iteration of MTRR setup.
I'm unfortunately being kept too busy trying to keep coreboot from making changes which seem good enough when proposed but which may not actually be worth the change.
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.
I am very worried that this is an XY problem:
Someone wants X and thinks that Y is the best way to accomplish it. They move on to communicate with others about Y, instead of about X, which is the more constructive communication to be had.
Is your goal to write-protect coreboot code in RAM while coreboot runs?
And, again, we've had virtual addresses forever. That's what segmentation hardware does. We just had a 1:1 mapping.
A 1:1 mapping is (obviously, I hope) equivalent to not having paging at all for the purpose of this discussion.
//Peter
On Wednesday, March 12, 2014 07:08:16 PM Peter Stuge wrote:
A 1:1 mapping is (obviously, I hope) equivalent to not having paging at all for the purpose of this discussion.
Not for Via NANO micrococde updates.
Alex
* Peter Stuge peter@stuge.se [140312 19:08]:
ron minnich wrote:
[on arm]
Why is it helpful or neccessary there?
It only matters if you like to have a dcache. Do you want a dcache?
What are the numbers?
Of running with dcache vs without? Beyond 10x speed improvement iirc. Far too much to ignore it.
Why is it neccessary there?
It only matters if you want to enter 64-bit mode.
(Why) Does coreboot need to do so?
I'd have to look up what we told the BIOS guys about why we switched to 32bit mode on 32bit platforms instead of staying in real mode. But with address space being more than 4G these days it seems like a good decision to go with the CPUs native mode instead of keeping to add tricks to address memory above 4G.
Just look at our last iteration of MTRR setup.
I'm unfortunately being kept too busy trying to keep coreboot from making changes which seem good enough when proposed but which may not actually be worth the change.
I don't think this is going to make MTRR setup go away. These are two separate mechanisms and at least the OS will still need MTRRs set up correctly. Unfortunate, but that's how the hardware works. However there are other potential benefits, see below.
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) - 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 - run in 64 bit mode, for easy addressing of memory / devices, have more registers available for more compact code, etc.
I am very worried that this is an XY problem:
Someone wants X and thinks that Y is the best way to accomplish it. They move on to communicate with others about Y, instead of about X, which is the more constructive communication to be had.
Possibly. It is an experiment at this point but it might prove really useful in the future.
Stefan
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
On Sat, Mar 15, 2014 at 10:22 AM, Kevin O'Connor kevin@koconnor.net wrote:
Agreed. I don't see any problems with a 1:1 page mapping where it's useful.
me neither.
ron
Am Samstag, den 15.03.2014, 13:22 -0400 schrieb Kevin O'Connor:
On Wed, Mar 12, 2014 at 09:12:05PM +0100, Stefan Reinauer wrote:
[...] 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 a fixed memory location before being put there, which is what Stefan was referring to - you can't just add it like any arbitrary file, and we have some convoluted things in the build system to handle this.
Patrick
On Sat, Mar 15, 2014 at 06:51:08PM +0100, Patrick Georgi wrote:
Am Samstag, den 15.03.2014, 13:22 -0400 schrieb Kevin O'Connor:
On Wed, Mar 12, 2014 at 09:12:05PM +0100, Stefan Reinauer wrote:
[...] 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 a fixed memory location before being put there, which is what Stefan was referring to - you can't just add it like any arbitrary file, and we have some convoluted things in the build system to handle this.
Agreed. But, even with paging, some code has to be at a static address (eg, the code which initially sets up the paging).
I suspect the pain of mapping files in CBFS to different virtual addresses is greater then the pain of having files in CBFS at static addresses.
-Kevin
On Sat, Mar 15, 2014 at 11:31 AM, Kevin O'Connor kevin@koconnor.net wrote:
I suspect the pain of mapping files in CBFS to different virtual addresses is greater then the pain of having files in CBFS at static addresses.
I'm happy to verify it either way :-)
You won't have to feel my pain :-)
ron
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
-
Kevin O'Connor -
mrnuke -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer