GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation/project_ideas: Update after 2019 

The coverity project is done, for the most part, so drop it. Expand
a bit on the scope of the toolchain binary project, and point out
that the Ghidra project already has code from GSoC 2019 but could be
developed further.

Change-Id: I7342cc3133494f69b175b11b1f8342a0f40840e7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This commit is contained in:
Patrick Georgi 2020-02-23 09:51:07 +01:00
parent c44d1e2c7c
commit 6a4f46ac5e
1 changed files with 8 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
Documentation/contributing/project_ideas.md
View File

@ -27,7 +27,9 @@ which is a bad experience when trying to build coreboot the first time.
Provide packages/installers of our compiler toolchain for Linux distros,
Windows, Mac OS. For Windows, this should also include the environment
(shell, make, ...).
(shell, make, ...). A student doesn't have to cover _all_ platforms, but
pick a set of systems that match their interest and knowledge and lay
out a plan on how to do this.
The scripts to generate these packages should be usable on a Linux
host, as that's what we're using for our automated build testing system
@ -131,26 +133,6 @@ their bug reports.
### Mentors
* Patrick Georgi <patrick@georgi.software>
## Make coreboot coverity clean
coreboot and several other of our projects are automatically tested
using Synopsys' free "Coverity Scan" service. While some fare pretty
good, like [em100](https://scan.coverity.com/projects/em100) at 0 known
defects, there are still many open issues in other projects, most notably
[coreboot](https://scan.coverity.com/projects/coreboot) itself (which
is also the largest codebase).
Not all of the reports are actual issues, but the project benefits a
lot if the list of unhandled reports is down to 0 because that provides
a baseline when future changes reintroduce new issues: it's easier to
triage and handle a list of 5 issues rather than more than 350.
This project would be going through all reports and handling them
appropriately: Figure out if reports are valid or not and mark them
as such. For valid reports, provide patches to fix the underlying issue.
### Mentors
* Patrick Georgi <patrick@georgi.software>
## Extend Ghidra to support analysis of firmware images
[Ghidra](https://ghidra-sre.org) is a recently released cross-platform
disassembler and decompiler that is extensible through plugins. Make it
@ -158,6 +140,11 @@ useful for firmware related work: Automatically parse formats (eg. by
integrating UEFITool, cbfstool, decompressors), automatically identify
16/32/64bit code on x86/amd64, etc.
This has been done in 2019 with [some neat
features](https://github.com/al3xtjames/ghidra-firmware-utils) being
developed, but it may be possible to expand support for all kinds of firmware
analyses.
## Learn hardware behavior from I/O and memory access logs
[SerialICE](https://www.serialice.com) is a tool to trace the behavior of
executable code like firmware images. One result of that is a long log file