[coreboot] Re: Security notice: SMM can be hijacked by the OS on APs
On April 12, 2022 8:55:56 AM UTC, Arthur Heymans wrote: >Hi > >Would it make sense to backport your fix to old releases and bump >> those release numbers to a .1 on the end? >> > >Some see releases as mere synchronization tags & nice PR. >Some releases are also branches in gerrit but there are none affected by >this (latest is 4.12 and it was introduced in 4.13). As you may know, coreboot distributions (talking of Heads specifically here), take releases tarballs and apply patches where needed on top of it. In the present case, Heads currently depends on coreboot 4.11, 4.13 and 4.15 for its supported boards. I quickly attempted to backport the relevant patches to 4.13 tarball release, unsuccessfully. The alternative would be to move all 4.13+ coreboot versions to switch to a specific commit in the middle of the current 4.16 release, which doesn't seem to be interesting from a stability perspective for users, moving production board owners to testers of 4.17 coreboot release. The relevant patchset is on top of 4.16, where I haven't found a proper merging strategy to backport a good patchset onto 4.13. I attempted to find all patches touching the 4.13 introduced new smm2 handler, but conflicts arose when trying to cherry-pick those commits in reverse order in the attempt of creating a patch that would apply successfully on top of 4.13 extracted tarball. I believe as well that new tarballs for 4.13.1 and newer should have the patchset backported and included and newer branches/tarballs (.1) released, so that all coreboot based distributions can easily point to those new tarballs without each of them having to suddenly point to a specific commit in between releases, 4.16 just having been released, also containing the vulnerability. >There is a precedent where 4.8 was bumped to 4.8.1 because all boards were >broken. > >I don't have a strong opinion on this. >Do people really use the releases in production or are most using git >anyway? In the goal of coreboot release based distributions, and to properly support products/solutions, I am not aware of a lot of projects that are based on coreboot rolling release (git). If reproducibility of coreboot distribution builds (roms) are also being a goal for those coreboot distribution projects, pointing to a git commit is only good for testing new introduced platforms, not optimal in creating stable releases for already supported platforms, which project codebase changes as well in between coreboot upstream releases. >It's a bit weird to have releases that you'd have to advertise as *don't >use*, but I've seen us do that in the past (because issues are quite often >just fixed in master). In an ideal world, each of those projects would have time to test fully rolling releases. But the reality is different. Heads/Skulls/Osboot/libreboot relies on coreboot releases to build ROMs for their supported platforms and users. > >Kind regards >Arthur > >On Tue, Apr 12, 2022 at 12:52 AM Peter Stuge wrote: > >> Arthur Heymans wrote: >> > I think this issue might affect a lot more systems than I initially >> thought. >> >> Would it make sense to backport your fix to old releases and bump >> those release numbers to a .1 on the end? >> >> >> //Peter >> ___ >> 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] Re: KGPE-D16 maintainership
On September 23, 2019 8:42:04 AM UTC, Arthur Heymans wrote: >Hi > >Thanks for wanting to maintain this platform! > >There are a issues with the amdfam10 codebase that could be improved >upon. I'll try to list a few of them, to give an idea of what >maintaining this code in 2019 could mean. Awesome points, Arthur. Thanks a bunch! > >So first and foremost: >1) The amdfam10 codebase (terminology-wise this always means non-agesa >in this context) suffers from a romcc romstage past. This code is >derived from code that used to be compiled with romcc instead of >running >in CAR. The result of that is a big amount of romstage boilerplate code >and lots of #include *.c in the mainboard code, that is often not >mainboard specific. To give an example romstage spinlocks and memory >tests are implemented in the kgpe-d16 romstage.c file while not being >mainboard specific at all. These practices result in an unusually large >amount of unmaintained code in mainboard dirs with a fragile inclusion >order of headers (and *.c files!). > >Other issues pertain to coreboot wanting to move forward by mandating a >few features (relocatable ramstage, postcar >stage/no_car_global_migration, c environment bootblock): >2) relocatable ramstage: This is just a Kconfig switch to build the >ramstage as a relocatable stage instead of statically linking it to >execute at CONFIG_RAM_BASE. Typically you want to set up some caching >of >where cbmem is going to be to speed up ramstage, but on amd hardware >it's bit more complicated. Part of ramstage is to initialize AP's and >AP's >will eventually jump to ramstage code. On AMD hardware however there is >a TOP_MEM MTRR that creates a boundary between ram and mmio below 4G. >If >this is configured to be below cbmem AP's won't execute code. I see a >few proper solutions: >- AP's are also active during the romstage -> try to sync MTRR's at the > end of romstage. > - Use the parallel mp init code and modify the relocatable SIPI vector > stub to have the MTRR's as arguments instead of a pointer to the BSP > MTRR settings, in order to copy them. > >https://review.coreboot.org/c/coreboot/+/30063 is an atte On my side, I'm committing to spin the need of support into Libreboot communities and open source forums and security trainings I do for organisation for self hosting needs. I also commit of giving a margin of Insurgo profits following needs to cover part of the maintenance fees. Sorry to not have jumped in preciously, I'm crazy busy with Insurgo tasks and looking myself for collaboration to build a cooperative business platform and modify things so I can be completely replaceable into doing the whole production chain for the PrivacyBeast x230. Both from a Heads perspective and from a QubesOS perspective. Let me know what I can do to help on a community basis and what are the costs to cover. I'll do my best. Thanks a bunch for showing interest into keeping that platform alive. Thierry/Insurgo -- Sent from /e/ Mail ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Final calls for S3 suspend support on amdfam10-15
I could provide such resume logs for kgpe-d16. How do I produce them? On August 21, 2019 2:43:44 AM UTC, Matt B wrote: >Is a lack of C bootblock support common to all family 15h platforms? >(Including the G505s and any others?) >In other words, would it only need to be implemented once for all of >these >systems? > >Sincerely, >-Matthew Bradley > >On Thu, Aug 15, 2019 at 11:50 AM Kyösti Mälkki > >wrote: > >> Hi >> >> The decisions are out on 4.11 release requirements. Unless anyone >acts >> on it, amdfam10-15 boards will hit deprecation due to: >> * RELOCATABLE_RAMSTAGE=n >> * CAR_GLOBAL_MIGRATION=y >> * C_ENVIRONMENT_BOOTBLOCK=n >> >> To smooth down the path, should anyone want to attempt on fixing >> these, I have pushed a patchset [1] that removes S3 suspend support >> from said platform. Depending of what the response is, I hope to have >> that submitted already before 4.11 release. >> >> The latest info [2] I have is asus/kcma-d8 not working and >> asus/kgpe-d16 working in 4.6 but very slowly, for S3 resume boot, >that >> is. No resume logs have been brought to my knowledge for 12 months. I >> also had some suspicions that tests results were mistakenly from >> suspend-to-disk (S4). >> >> Affected boards are asus/kcma-d8 and asus/kgpe-d16. >> >> [1] https://review.coreboot.org/c/coreboot/+/15474 >> [2] >https://mail.coreboot.org/pipermail/coreboot/2018-June/086906.html >> >> Kind regards, >> Kyösti >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> -- Sent from /e/ Mail___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
