2 ========================================================================
4 The coreboot 4.17 release was done on June 3, 2022.
6 Since the 4.16 release, we've had over 1300 new commits by around 150
7 contributors. Of those people, roughly 15 were first-time contributors.
9 As always, we appreciate everyone who has contributed and done the hard
10 work to make the coreboot project successful.
13 Major Bugfixes in this release
14 ------------------------------
15 * [CVE-2022-29264](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29264)
21 * Clevo L140MU / L141MU / L142MU
22 * Dell Precision T1650
28 * HP Z220 CMT Workstation
29 * Star Labs LabTop Mk III (i7-8550u)
30 * Star Labs LabTop Mk IV (i3-10110U and i7-10710U)
31 * Star Labs Lite Mk III (N5000)
32 * Star Labs Lite Mk IV (N5030)
41 Significant or interesting changes
42 ----------------------------------
44 These changes are a few that were selected as a sampling of particularly
48 ### CBMEM init hooks changed
50 Instead of having per stage x_CBMEM_INIT_HOOK, we now have only 2 hooks:
51 * CBMEM_CREATION_HOOK: Used only in the first stage that creates cbmem,
52 typically romstage. For instance code that migrates data from cache
53 as ram to dram would use this hook.
54 * CBMEM_READY_HOOK: Used in every stage that has cbmem. An example would
55 be initializing the cbmem console by appending to what previous stages
57 The reason for this change is improved flexibility with regards to which
58 stage initializes cbmem.
63 * SeaBIOS: Update stable release from 1.14.0 to 1.16.0
64 * iPXE: Update stable release from 2019.3 to 2022.1
65 * Add "GRUB2 atop SeaBIOS" aka "SeaGRUB" option, which builds GRUB2 as a
66 secondary payload for SeaBIOS with GRUB2 set as the default boot
67 entry. This allows GRUB2 to use BIOS callbacks provided by SeaBIOS as
68 a fallback method to access hardware that the native GRUB2 payload
70 * Add option to build SeaBIOS and GRUB2 as secondary payloads
71 * Add new coreDOOM payload. See commit message below.
74 ### payloads/external: Add support for coreDOOM payload
76 coreDOOM is a port of DOOM to libpayload, based on the doomgeneric
77 source port. It renders the game to the coreboot linear framebuffer,
78 and loads WAD files from CBFS.
81 ### cpu/x86/smm_module_load: Rewrite setup_stub
83 This code was hard to read as it did too much and had a lot of state
86 It also looks like the staggered entry points were first copied and
87 only later the parameters of the first stub were filled in. This
88 means that only the BSP stub is actually jumping to the permanent
89 smihandler. On the APs the stub would jump to wherever c_handler
90 happens to point to, which is likely 0. This effectively means that on
91 APs it's likely easy to have arbitrary code execution in SMM which is a
94 Note: This patch fixes CVE-2022-29264 for the 4.17 release.
97 ### cpu/x86/smm_module_loader.c: Rewrite setup
99 This code is much easier to read if one does not have to keep track of
102 This also fixes the alignment code on the TSEG smihandler setup code.
103 It was aligning the code upwards instead of downwards which would cause
104 it to encroach a part of the save state.
107 ### cpu/x86/smm: Add sinkhole mitigation to relocatable smmstub
109 The sinkhole exploit exists in placing the lapic base such that it
110 messes with GDT. This can be mitigated by checking the lapic MSR
111 against the current program counter.
114 ### cpu/x86/64bit: Generate static page tables from an assembly file
116 This removes the need for a tool to generate simple identity pages.
117 Future patches will link this page table directly into the stages on
118 some platforms so having an assembly file makes a lot of sense.
120 This also optimizes the size of the page of each 4K page by placing
121 the PDPE_table below the PDE.
124 ### cpu/x86/smm,lib/cbmem_console: Enable CBMEMC when using DEBUG_SMI
126 This change will allow the SMI handler to write to the cbmem console
127 buffer. Normally SMIs can only be debugged using some kind of serial
128 port (UART). By storing the SMI logs into cbmem we can debug SMIs using
129 'cbmem -1'. Now that these logs are available to the OS we could also
130 verify there were no errors in the SMI handler.
132 Since SMM can write to all of DRAM, we can't trust any pointers
133 provided by cbmem after the OS has booted. For this reason we store the
134 cbmem console pointer as part of the SMM runtime parameters. The cbmem
135 console is implemented as a circular buffer so it will never write
136 outside of this area.
139 ### security/tpm/crtm: Add a function to measure the bootblock on SoC level
141 On platforms where the bootblock is not included in CBFS anymore
142 because it is part of another firmware section (IFWI or a different
143 CBFS), the CRTM measurement fails.
145 This patch adds a new function to provide a way at SoC level to measure
146 the bootblock. Following patches will add functionality to retrieve the
147 bootblock from the SoC related location and measure it from there.
148 In this way the really executed code will be measured.
151 ### soc/amd/common/block/psp: Add platform secure boot support
153 Add Platform Secure Boot (PSB) enablement via the PSP if it is not
154 already enabled. Upon receiving psb command, PSP will program PSB fuses
155 as long as BIOS signing key token is valid.
156 Refer to the AMD PSB user guide doc# 56654, Revision# 1.00.
157 Unfortunately this document is only available with NDA customers.
160 ### drivers/intel/fsp2_0: Add native implementation for FSP Debug Handler
162 This patch implements coreboot native debug handler to manage the FSP
165 'FSP Event Handlers' feature introduced in FSP to generate event
166 messages to aid in the debugging of firmware issues. This eliminates
167 the need for FSP to directly write debug messages to the UART and FSP
168 might not need to know the board related UART port configuration.
169 Instead FSP signals the bootloader to inform it of a new debug message.
170 This allows the coreboot to provide board specific methods of reporting
171 debug messages, example: legacy UART or LPSS UART etc.
173 This implementation has several advantages as:
174 1. FSP relies on XIP 'DebugLib' driver even while printing FSP-S debug
175 messages, hence, without ROM being cached, post 'romstage' would
176 results into sluggish boot with FSP debug enabled.
177 This patch utilities coreboot native debug implementation which is
178 XIP during FSP-M and relocatable to DRAM based resource for FSP-S.
180 2. This patch simplifies the FSP DebugLib implementation and remove the
181 need to have serial port library. Instead coreboot 'printk' can be
182 used for display FSP serial messages. Additionally, unifies the debug
183 library between coreboot and FSP.
185 3. This patch is also useful to get debug prints even with FSP
186 non-serial image (refer to 'Note' below) as FSP PEIMs are now
187 leveraging coreboot debug library instead FSP 'NULL' DebugLib
188 reference for release build.
190 4. Can optimize the FSP binary size by removing the DebugLib dependency
191 from most of FSP PEIMs, for example: on Alder Lake FSP-M debug binary
192 size is reduced by ~100KB+ and FSP-S debug library size is also
193 reduced by ~300KB+ (FSP-S debug and release binary size is exactly
194 same with this code changes). The total savings is ~400KB for each
195 FSP copy, and in case of Chrome AP firmware with 3 copies, the total
196 savings would be 400KB * 3 = ~1.2MB.
198 Note: Need to modify FSP source code to remove 'MDEPKG_NDEBUG' as
199 compilation flag for release build and generate FSP binary with non-NULL
200 FSP debug wrapper module injected (to allow FSP event handler to execute
201 even with FSP non-serial image) in the final FSP.fd.
204 ### security/tpm: Add vendor-specific tis functions to read/write TPM regs
206 In order to abstract bus-specific logic from TPM logic, the prototype
207 for two vendor-specific tis functions are added in this
208 patch. tis_vendor_read() can be used to read directly from TPM
209 registers, and tis_vendor_write() can be used to write directly to TPM
213 ### arch/x86: Add support for catching null dereferences through debug regs
215 This commit adds support for catching null dereferences and execution
216 through x86's debug registers. This is particularly useful when running
217 32-bit coreboot as paging is not enabled to catch these through page
218 faults. This commit adds three new configs to support this feature:
219 DEBUG_HW_BREAKPOINTS, DEBUG_NULL_DEREF_BREAKPOINTS and
220 DEBUG_NULL_DEREF_HALT.
223 ### drivers/i2c/generic: Add support for i2c device detection
225 Add 'detect' flag which can be attached to devices which may or may not
226 be present at runtime, and for which coreboot should probe the i2c bus
227 to confirm device presence prior to adding an entry for it in the SSDT.
229 This is useful for boards which may utilize touchpads/touchscreens from
230 multiple vendors, so that only the device(s) present are added to the
231 SSDT. This relieves the burden from the OS to detect/probe if a device
232 is actually present and allows the OS to trust the ACPI _STA value.
235 ### util/cbmem: Add FlameGraph-compatible timestamps output
237 Flame graphs are used to visualize hierarchical data, like call stacks.
238 Timestamps collected by coreboot can be processed to resemble
239 profiler-like output, and thus can be feed to flame graph generation
242 Generating flame graph using https://github.com/brendangregg/FlameGraph:
245 FlameGraph/flamegraph.pl --flamechart trace.txt > output.svg
249 ### src/console/Kconfig: Add option to disable loglevel prefix
251 This patch adds an option to disable loglevel prefixes. This patch helps
252 to achieve clear messages when low loglevel is used and very few
253 messages are displayed on a terminal. This option also allows to
254 maintain compatibility with log readers and continuous integration
255 systems that depend on fixed log content.
257 If the code contains:
258 printk(BIOS_DEBUG, "This is a debug message!\n")
260 [DEBUG] This is a debug message!
261 but if the Kconfig contains:
262 CONFIG_CONSOLE_USE_LOGLEVEL_PREFIX=n
263 the same message will show up as
264 This is a debug message!
267 ### util/cbmem: add an option to append timestamp
269 Add an option to the cbmem utility that can be used to append an entry
270 to the cbmem timestamp table from userspace. This is useful for
271 bookkeeping of post-coreboot timing information while still being able
272 to use cbmem-based tooling for processing the generated data.
275 `-a | --add-timestamp ID: append timestamp with ID\n`
281 The following are changes across a number of patches, or changes worth
282 noting, but not needing a full description.
284 * As always, general documentation, code cleanup, and refactoring
285 * Remove doxygen config files and targets
286 * Get clang compile working for all x86 platforms
287 * Work on updating checkpatch to match the current Linux version
288 * Timestamps: Rename timestamps to make names more consistent
289 * Continue updating ACPI code to ASL 2.0
290 * Remove redundant or unnecessary headers from C files
291 * arch/x86/acpi_bert_storage.c: Use a common implementation
292 * Postcar stage improvements
293 * arch/x86/acpi: Consolidate POST code handling
294 * intel/common: Enable ROM caching in ramstage
295 * vendorcode/amd/agesa: Fix improper use of .data (const is important)
296 * sandybridge & gm45: Support setting PCI bars above 4G
299 Plans to move platform support to a branch:
300 -------------------------------------------
301 After the 4.18 release in November 2022, we plan to move support for any
302 boards still requiring RESOURCE_ALLOCATOR_V3 to the 4.18 branch. V4 was
303 introduced more than a year ago and with minor changes most platforms
304 were able to work just fine with it. A major difference is that V3 uses
305 just one continuous region below 4G to allocate all PCI memory BAR's. V4
306 uses all available space below 4G and if asked to, also above 4G too.
307 This makes it important that SoC code properly reports all fixed
310 Currently only AGESA platforms have issues with it. On Gerrit both
311 attempts to fix AMD AGESA codebases to use V4 and compatibility modes
312 inside the V4 allocator have been proposed, but both efforts seem
313 stalled. See the (not yet merged) documentation
314 [CR:43603](https://review.coreboot.org/c/coreboot/+/43603) on it's
315 details. It looks like properly reporting all fixed resources is the
318 At this point, we are not specifying which platforms this will include
319 as there are a number of patches to fix these issues in flight.
320 Hopefully, all platforms will end up being migrated to the V4 resource
321 allocator so that none of the platforms need to be supported on the
324 Additionally, even if the support for the platform is moved to a branch,
325 it can be brought back to ToT if they're fixed to support the V4
329 Plans for Code Deprecation
330 --------------------------
335 Intel Icelake is unmaintained. Also, the only user of this platform ever was
336 the CRB board. From the looks of it the code never was ready for production as
337 only engineering sample CPUIDs are supported.
339 Thus, to reduce the maintanence overhead for the community, it is deprecated
340 from this release on and support for the following components will be dropped
341 with the release 4.19.
344 * Intel Icelake RVP mainboard
349 As of release 4.18 (August 2022) we plan to deprecate LEGACY_SMP_INIT.
350 This also includes the codepath for SMM_ASEG. This code is used to start
351 APs and do some feature programming on each AP, but also set up SMM.
352 This has largely been superseded by PARALLEL_MP, which should be able to
353 cover all use cases of LEGACY_SMP_INIT, with little code changes. The
354 reason for deprecation is that having 2 codepaths to do the virtually
355 the same increases maintenance burden on the community a lot, while also
356 being rather confusing.
358 No platforms in the tree have any hardware limitations that would block
359 migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase.
365 - Total Commits: 1305
366 - Average Commits per day: 13.42
367 - Total lines added: 51422
368 - Average lines added per commit: 39.40
369 - Number of patches adding more than 100 lines: 59
370 - Average lines added per small commit: 24.73
371 - Total lines removed: 66206
372 - Average lines removed per commit: 50.73
373 - Total difference between added and removed: -14784