On Tue, Oct 1, 2019 at 10:29 AM Raul Rangel <rran...@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. > > On Tue, Oct 1, 2019 at 10:27 AM Aaron Durbin <adur...@google.com> wrote: > >> >> >> On Tue, Oct 1, 2019 at 9:42 AM Raul Rangel <rran...@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 <s...@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%20status:merged) >>>> _______________________________________________ >>>> coreboot mailing list -- coreboot@coreboot.org >>>> To unsubscribe send an email to coreboot-le...@coreboot.org >>>> >>> _______________________________________________ >>> coreboot mailing list -- coreboot@coreboot.org >>> To unsubscribe send an email to coreboot-le...@coreboot.org >>> >>
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
