vboot/firmware
Julius Werner af02768dac cgptlib: Always zero-initialize GPT entries buffers
ClusterFuzz still managed to find cases where we try to CRC a GPT
entries buffer that wasn't initialized. Not that that's really an issue
or anything... but this patch should shut it up.

BRANCH=none
BUG=chromium:1155876
TEST=none

Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0b4f34693d87b66513f398dd13441aba543c3a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/vboot_reference/+/2580110
Reviewed-by: Joel Kitching <kitching@chromium.org>
2020-12-16 00:39:29 +00:00
..
2lib vboot2: Use TPM for hash acceleration allowance 2020-12-09 12:01:45 +00:00
include vboot: deprecate and remove legacy UI code 2020-12-04 13:13:26 +00:00
lib cgptlib: Always zero-initialize GPT entries buffers 2020-12-16 00:39:29 +00:00
lib20 vboot2: remove rsa from vb2_hwcrypto_rsa_allowed 2020-12-09 12:01:41 +00:00
stub vboot: deprecate and remove legacy UI code 2020-12-04 13:13:26 +00:00
README vboot: move vboot 2.1 functions and structs into host code 2020-02-11 02:04:10 +00:00

README

Here's what's what in the firmware/ directory.

include/
lib/

  These are the original structures and APIs used in the earliest
  Chromebooks and continuing through 2014. It never had a version as such to
  begin with, but we now refer to this implementation as "vboot1" or
  "vboot version 1.0".

linktest/
stub/

  These are stubs used to link the vboot1 libraries into host-side test
  executables so we can run some tests on the build machine instead of a
  Chromebook.

2lib/

  In 2014 we began work on a new vboot API. The first step was just a
  refactoring and renaming of the verification API. The public functions and
  external headers that are exported for use by the Chrome OS firmware (or
  anything else that wants to use vboot) live in here. The internal
  structures and implementations go elsewhere.

lib20/

  This is an early implementation of the public (2lib/) API. It is
  binary-compatible with vboot1, so although the interface details are
  different, any existing on-device structures or signatures created by the
  vboot1 tools can be validated using this implementation.

  This was deployed slightly before it was ready. That's not a problem,
  thanks to the binary compatibility, but this directory will be abandoned
  Real Soon Now, except for the product support branches.