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