On 27.07.2008 16:36, Stefan Reinauer wrote:
> I have been working on an SMM handler for coreboot in the last week, so
> we can support laptops and mainboards with power management features
> that are hard or impossible to support in the near future.
>
Great!
> The SMM handler I wrote switches to 32bit protected mode and all SMI#
> handling is written in C code, compiled with normal gcc without the
> gcc16 hack or similar nasty things. Thus it is just another exception
> handler, like the ones we have in coreboot already.
>
I like that approach.
> One difference is that the SMM handler stays operational once the OS is
> loaded. The SMM stub living at 0xa8000 currently jumps to the C handler
> in normal coreboot code in ram, which starts at _RAMBASE. So in order to
> be able to use the SMM handler, that memory (code, data, bss, and heap;
> not the stack) needs to stay in place and untouched for the current
> scenario to work.
>
> Now, memory consumption of the ram part of coreboot is quite tough:
>
> On an example mainboard, I get these values:
>
> code: 102464
> data: 53088
> bss: 10248
> stack: 32768
> heap: 32768
> ------------------
> total: 231336
>
> Usually code starts at 0x4000 (_RAMBASE) and, in the above example,
> reaches up to 0x3e000, occupying almost 4 64k "segments" (0x3a000/237568
> bytes)
>
> My first thought was: we could add that memory as reserved in the
> coreboot table / e820. coreboot keeps a lot of information in memory
> already, and expects the OS / payload to take care it is not overwritten:
>
> - mptable
> - pirq
> - dsdt, and the other ACPI tables
> - DMI (required for ACPI on 32bit systems with newer Linux kernels)
> - i remember some ebda issues in the last few days on this list, too
> - last but not least of course the coreboot table.
>
> So far, coreboot has been "tricking around" to put these in places that
> don't hurt and where the OS is going to find them. This worked in a
> rough-and-ready manner but will fail us in the future, at least make us
> stay quick'n'dirty fixing after every occurence of a problem.
>
> But to conclude, keeping (parts of) coreboot resident in memory is
> nothing that SMM would introduce. We have been doing this for many years.
>
> Another alternative to keeping full coreboot around, would be to make
> the SMM handler self contained. This would mean, the SMM handler could
> not use coreboot's functions like printk_debug, pci_read_config32, it
> could not use the device tree, and it would become more complex, because
> for some information we have to reprobe the hardware, or parse the
> coreboot table.
>
>From a v3 perspective, it might make sense to keep the SMI handler (if
it has limited size) in the boot block. That avoids any and all
requirements to keep code in RAM, thereby taking away the problem of
code relocation.
> In the case of the SMM handler, this would also confine us, because the
> actual SMI# handling code (written in C) would not be shared between
> CPUs but has to be duplicated for every CPU core. However, my current
> approach only keeps a very small amount of code per CPU, that is just
> enough to enter gcc compiled functions and return from them, cleanly.
>
AFAIK factory BIOS SMM handlers have the ability to lock down the memory
segment they are using, protecting them from accidental or deliberate
tampering by the OS (which could lead to interesting security issues).
Can we do that even if the handler is "somewhere" in RAM?
> One of the questions in my mind is: where should we put the coreboot
> image, if we want to keep it around?
>
> A little excerpt from coreboot v2:
>
> I know the problem of where to put coreboot has been thought about
> before, elfboot() relocates coreboot to another place when loading an
> ELF binary that demands the space where coreboot lives:
> * coreboot tries to load a segment and finds out, that it is in the way.
> * coreboot copies itself to a new position
> * coreboot jumps into the assembler handler in jmp_to_elf_entry at the
> new position
> * coreboot tries to start the ELF binary.
> * If it fails, it overwrites the loaded ELF binary by copying itself
> back and jumping to the original position.
>
> This is quite an interesting concept, but it also makes clear that the
> ram portion of coreboot itself ("stage2") can not be relocated freely in
> memory. Yet.
>
Please see my other mail in this thread about possible problems with a
relocatable stage2. Besides that, we'd need a way in v3 to tag a LAR
member as PIC (sort of done for the special case of XIP in initram) and
new code to figure out a good load address during run time.
> Since we know how big our RAM is when we copy coreboot to RAM, I suggest
> that we copy coreboot to the end of memory and run it from there. It is
> a pretty good assumption that no payload will require that space. During
> memory map creation, we just reserve 256k at the upper end, and we're good.
>
Hm... I assume end of memory is "end of memory below 4G". If we want to
avoid conflicts with mapped memory areas of extension cards, stage2 code
has to be loaded twice: Once before setting up extension cards (load
stage2 to above 1M or other failsafe location) and after setting up
extension cards (load stage2 to end of memory below 4G and below
extension card space). That's not exactly the nicest code flow I can
think of.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
--
coreboot mailing list
[email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
