On 2019-10-01 07:32 PM, Aaron Durbin via coreboot wrote:
On Tue, Oct 1, 2019 at 10:29 AM Raul Rangel rrangel@chromium.org wrote:
Yeah, we can place the stack at the bottom of a page so if it overflows we get a page fault. I'm assuming that will work in SMM?
Paging works in SMM, yes. However, paging works on 32-bit as well where one could achieve the same thing. Minimum 4KiB stack granularity is necessary as well as ensuring physical and virtual address spaces are split up to allow guard pages. Currently everything is assumed 1:1.
Currently neither 4KiB page, non identity mapping or a page fault handler is present. It would also require runtime modification of page tables, as the position of TSEG/A-Seg and the stack isn't known at build time, which only works if those reside in RAM. The current approach places page tables in RO CBFS to make sure it can't be modified from ring 0, which is sufficient for basic x86_64 support. Of course those can be added once the basic support has landed and is stable.
On Tue, Oct 1, 2019 at 10:27 AM Aaron Durbin adurbin@google.com wrote:
On Tue, Oct 1, 2019 at 9:42 AM Raul Rangel rrangel@chromium.org wrote:
That's exciting. That means we can finally catch stack overflows in SMM.
Because of paging?
On Sun, Sep 29, 2019 at 5:42 AM Patrick Rudolph siro@das-labor.org wrote: Dear coreboot community, Please test and review the patch series [1].
It adds support for x86 long mode on qemu and allows to build test most of coreboot's common code using the x86_64 toolchain. It serves as reference implementation to migrate real hardware to long mode.
Here some technical details, that can also be found in the Documentation/ folder:
A new tool called pgtblgen create static page tables for a known physical memory address. The page tables are placed in CBFS at the given address. Due to the fixed and known address, they can easily be loaded in assembly code. It only works on platforms that memory map the SPI flash, which are almost all modern x86 platforms.
The advantage of page tables in ROM are:
- No runtime (assembly) code to generate page tables
- No need to find a (4K aligned) place in heap to store them
- Improved security for SMM, as page tables are always immutable
The page tables are loaded in bootblock and SMM and persist until control is handed over to the payload.
For the Proof-of-Concept only 4GiB are identity mapped, thus no stage can't access memory over 4GiB. That's not a problem for now as no coreboot code make use of memory above 4GiB yet.
I haven't done further tests on long mode. It will be interesting to see if there are improvements on boot speed, code size or faster firmware decompression speeds.
Regards, Patrick
1:
https://review.coreboot.org/q/topic:%22x86_64_support2%22+(status:open%20OR%...)
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Patrick Rudolph