I wrote a test case for strnlena() and strndupa() and of course both
were off by one in the opposite directions...
... but the next patch obviates the need for them, hopefully, so this
will wind up getting dropped.
The license statements in our source files were getting to be a giant
mess, and mostly they all just say the same thing. I've switched most
of it to SPDX labels, but left copyright statements in place (where they
were not obviously incorrect copy-paste jobs that I did...).
If there's some change here you don't think is valid, let me know and
we can fix it up together.
Signed-off-by: Peter Jones <pjones@redhat.com>
Unfortunately GNU-EFI doesn't currently implement ascii versions of
strchr() or strchrnul(), and we kind of need them, so add an
implementation here for now.
Signed-off-by: Peter Jones <pjones@redhat.com>
Currently, all three invocations of the translate_slashes() function may
lead to writes to the string literal that is #defined with the
DEFAULT_LOADER_CHAR macro. According to ISO C99 6.4.5p6, this is undefined
behavior ("If the program attempts to modify such an array, the behavior
is undefined").
This bug crashes shim on e.g. the 64-bit ArmVirtQemu platform ("Data
abort: Permission fault"), where the platform firmware maps the .text
section (which contains the string literal) read-only.
Modify translate_slashes() so that it copies and translates characters
from an input array of "char" to an output array of "CHAR8".
While at it, fix another bug. Before this patch, if translate_slashes()
ever encountered a double backslash (translating it to a single forward
slash), then the output would end up shorter than the input. However, the
output was not NUL-terminated in-place, therefore the original string
length (and according trailing garbage) would be preserved. After this
patch, the NUL-termination on contraction is automatic, as the output
array's contents are indeterminate when entering the function, and so we
must NUL-terminate it anyway.
Fixes: 8e9124227d
Fixes: e62b69a5b0
Fixes: 3d79bcb265
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1795654
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Upstream-commit-id: 9813e8bc8b3
Right now we always look for e.g. "\grubx64.efi", which is completely
wrong. This makes it look for the path shim was loaded from and modify
that to end in a sanitized version of our default loader name.
Resolves: rhbz#1032583
Signed-off-by: Peter Jones <pjones@redhat.com>
