The romentry structure is the container ADT with some
annotated meta-data such as 'included' or 'file' however
the substantive substructure is a 'flash_region'. Therefore
factor this out.
That is to say, the link list node 'romentry' is obscured by the implementation details of its use-case of 'flash_region' that we
clear up here.
BUG=b:260440773
BRANCH=none
TEST=flashrom_tester
Change-Id: I768742b73db901df5b5208fcbcb8a324a06014c2
CoAuthored-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69196
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It may be the case that a layout could not be derived which
would result in layout logic being fed a NULL pointer. Validate
this case and be defensive to validate the name argument as well.
BUG=b:247055486
TEST=builds
Change-Id: I2a19c0e586f8575b8b3c2c02b5afad312efacfc9
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67722
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
These functions [isspace, etc] check whether c [(the argument)], which
must have the value of an unsigned char or EOF, falls into a certain
character class according to the current locale.
Cast the argument from `char` to `unsigned char` to guarantee that
we don't pass illegal negative values. Some implementations actually
provide a warning to get heads up[1].
[1] https://man.netbsd.org/ctype.3#CAVEATS
TEST=Builds on Cygwin (Windows 10, amd64, gcc 11.3.0)
Change-Id: Ia48d5a19b0964bc28e5360edf06bdf287dad5945
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66548
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The doxygen documentation was in the libflashrom.c file. Move the
documentation to the libflashrom.h file. This allows foreign function
interface binding generators (eg rust bindgen) that operate on the .h
file to generate documentation for the target language. Some doxygen
errors were also corrected, mostly undocumented or wrongly labeled
parameters.
To test, I have diffed and inspected the doxygen documentation before
and after the change. All functions are documented the same, and the
structs and enums are now also included in the docs.
Change-Id: I856b74d5bfea13722539be15496755a95e701eea
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
While using the libflashrom API to read specific regions
there is no currently no general way to find the offset
into the read buffer of the expected region.
flashrom_layout_include_region() probably should have
returned the region offset and size if it was included.
However to avoid a change in API signature we can instead
hoist up get_region_range() into the API to be called after.
BUG=b:207808292
TEST=`make` && tested in porting cbfstool use-case.
Change-Id: I8cf95b5eaec943a51d0ea668f26a56bf6d6b4446
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
It initializes an empty layout. Currently the maximum number of entries
has to be specified, which will vanish once we use dynamic allocation
per entry.
We replace the two special cases `single_layout` and `ich_layout` with
dynamically allocated layouts. As a result, we have to take care to
release the `default_layout` in a flashctx once we are done with it.
Change-Id: I2ae7246493ff592e631cce924777925c7825e398
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Also, a `layout.c` internal version mutable_layout_next() that
allows to modify layout entries and a shorthand to look up an
entry by name, _layout_entry_by_name().
Use the new functions where applicable and the code is not
dropped later in this train, and also to compare the layouts
in flashrom_layout_read_from_ifd() in depth.
Change-Id: I284958471c61344d29d92c95d88475065a9ca9aa
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33542
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Spelling out the struct type name hurts readability and introduces
opportunities for bugs to happen when the pointer variable type is
changed but the corresponding sizeof is (are) not.
TEST=`make CONFIG_EVERYTHING=yes CONFIG_JLINK_SPI=no VERSION=none -j`
with and without this patch; the flashrom executable does not change.
Change-Id: Icc0b60ca6ef9f5ece6ed2a0e03600bb6ccd7dcc6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55266
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This change introduces a new option to extract all layout regions to
files with the name of each region (or with the provided filename via
-i region:file). It is implemented by mutating the flash layout to
include all regions and backfilling the entry->file with entry->name
(replacing spaces with underscores)
Signed-off-by: Daniel Campello <campello@chromium.org>
Change-Id: I8c69223fa92cf5b50abe070f1ab9f19d3b42f6ff
Reviewed-on: https://review.coreboot.org/c/flashrom/+/52450
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The field member 'included' is of type boolean and so keep to
using 'true, false' values over numerics like '0'. Get rid of
a unnecessary yet trivial tab at the end of layout.h while we
are here.
BUG=none
BRANCH=none
TEST=builds
Change-Id: Ib594de2834175482ae5e36d9dd354ef2555c53d5
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The full verification step was not accounting for sparse layouts.
Instead of the old contents, combine_image_by_layout() implicitly
assumed the new contents for unspecified regions.
Change-Id: I44e0cea621f2a3d4dc70fa7e93c52ed95e54014a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Add an option --ifd to read the ROM layout from an Intel Firmware
Descriptor (IFD). Works the same as the -l option, if given, -i
specifies the images to update.
v2: o Rebased on libflashrom, use libflashrom interface.
o Use functions from ich_descriptors.c.
v3: o Move ich_descriptors.o to LIB_OBJS, thus build it independent
of arch and programmers.
o Bail out if we aren't compiled for little endian.
o Update flashrom.8.tmpl.
v4: o Incorporated David's comments.
o Removed single-character `-d` option.
v5: Changed region names to match the output of `ifdtool --layout ...`
Change-Id: Ifafff2bf6d5c5e62283416b3269723f81fdc0fa3
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Introduce `struct flashrom_layout` and refactor layout.c a little, so
we can reuse the layout from there and have other sources of layouts
beside it.
I didn't want to clutter up flash.h any more. So things went into a new
layout.h.
Change-Id: Icea1a58c283131cc9c5fde6f16d783538dc1a4c7
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17944
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
An internal security audit of the flashrom project by
Carl-Daniel Hailfinger found a buffer overflow bug present in all
flashrom versions since the year 2005.
This bug was independently found and reported to flashrom.org by
Cosmin Gorgovan a few days ago.
A buffer on the stack and a buffer on the heap are affected by the
overflow caused by an incorrect fscanf format string.
The buffer overflow can only be triggered if the optional layout feature
is used and if the user manually specifies a specially crafted layout
file on the command line. Command line parsing and flash image handling
do not trigger the buggy code path.
Most usage of flashrom does not involve layout files.
The fix in this commit (changed fscanf format string) can be applied to
layout.c of all past flashrom versions.
Corresponding to flashrom svn r1953.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Even if fwrite() succeeds the data is not necessarily out of the clib's buffers
and writing it eventually could fail. Even if the data is flushed out (explicitly by
fflush() or implicitly by fclose()) the kernel might still hold a buffer.
Previously we have ignored this to a large extent - even in important cases
like writing the flash contents to a file. The results can be truncated
images that would brick the respective machine if written back as is (though
flashrom would not allow that due to a size mismatch). flashrom would not
indicate the problem in any output - so far we only check the return value
of fwrite() that is not conclusive.
This patch checks the return values of all related system calls like fclose()
unless we only read the file and are not really interested in output errors.
In the latter case the return value is casted to void to document this fact.
Additionally, this patch explicitly calls fflush() and fsync() (on regular files only)
to do the best we can to guarantee the read image reaches the disk safely
and at least inform the user if it did not work.
Corresponding to flashrom svn r1902.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Urja Rannikko <urjaman@gmail.com>
- Introduce a variable in doit() that allows to influence
read-before-write and its consequences.
- Modify build_new_image so that it still works even if the old content
is not read before.
- Add copy_old_content() to ease the pain for future patches.
Corresponding to flashrom svn r1851.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
This fixes a SEGFAULT if a layout entry is included that addresses memory
outside the current chip's address range. flashrom will only abort if the
offending region(s) is/are included else it will just warn.
It will print warnings for regions with negative or zero-length address ranges
and bail out after checking all of them.
Also, abort for non-write operations if a layout file is given because there is
no layout support for other operations yet.
Corresponding to flashrom svn r1751.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
