[PATCH v2] powerpc: increase MIN RMA size for CAS negotiation
Change RMA size from 512 MB to 768 MB which will result
in more memory at boot time for PowerPC. When vTPM, Secure Boot or
FADump are enabled on PowerPC, the 512 MB RMA memory is not sufficient for
booting. With this 512 MB RMA, GRUB2 runs out of memory and fails to
boot the machine. Sometimes even usage of CDROM which requires more
memory for installation along with the options mentioned above troubles
the boot memory and result in boot failures. Increasing the RMA size
will resolves multiple out of memory issues observed in PowerPC.
Failure details (GRUB2 debugs):
kern/ieee1275/init.c:550: mm requested region of size 8513000, flags 1
kern/ieee1275/init.c:563: Cannot satisfy allocation and retain minimum
runtime space
kern/ieee1275/init.c:550: mm requested region of size 8513000, flags 0
kern/ieee1275/init.c:563: Cannot satisfy allocation and retain minimum
runtime space
kern/file.c:215: Closing `/ppc/ppc64/initrd.img' ...
kern/disk.c:297: Closing
`ieee1275//vdevice/v-scsi@3067/disk@8300'...
kern/disk.c:311: Closing
`ieee1275//vdevice/v-scsi@3067/disk@8300' succeeded.
kern/file.c:225: Closing `/ppc/ppc64/initrd.img' failed with 3.
kern/file.c:148: Opening `/ppc/ppc64/initrd.img' succeeded.
error: ../../grub-core/kern/mm.c:552:out of memory.
Signed-off-by: Avnish Chouhan
---
grub-core/kern/ieee1275/init.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/grub-core/kern/ieee1275/init.c b/grub-core/kern/ieee1275/init.c
index dfbd0b8..34e9e13 100644
--- a/grub-core/kern/ieee1275/init.c
+++ b/grub-core/kern/ieee1275/init.c
@@ -852,7 +852,7 @@ grub_ieee1275_ibm_cas (void)
.vec1 = 0x80, /* ignore */
.vec2_size = 1 + sizeof (struct option_vector2) - 2,
.vec2 = {
- 0, 0, -1, -1, -1, -1, -1, 512, -1, 0, 48
+ 0, 0, -1, -1, -1, -1, -1, 768, -1, 0, 48
},
.vec3_size = 2 - 1,
.vec3 = 0x00e0, /* ask for FP + VMX + DFP but don't halt if unsatisfied */
@@ -889,6 +889,10 @@ grub_claim_heap (void)
{
grub_err_t err;
grub_uint32_t total = HEAP_MAX_SIZE;
+#if defined(__powerpc__)
+ grub_uint32_t ibm_ca_support_reboot = 0;
+ grub_ssize_t actual;
+#endif
err = grub_ieee1275_total_mem (&rmo_top);
@@ -901,11 +905,30 @@ grub_claim_heap (void)
grub_mm_add_region_fn = grub_ieee1275_mm_add_region;
#if defined(__powerpc__)
+ /* Check if it's a CAS reboot with below property. If so, we will skip CAS
call */
+ if (grub_ieee1275_get_integer_property (grub_ieee1275_chosen,
+
"ibm,client-architecture-support-reboot",
+ &ibm_ca_support_reboot,
+ sizeof (ibm_ca_support_reboot),
+ &actual) >= 0)
+grub_dprintf ("ieee1275", "ibm,client-architecture-support-reboot: %u\n",
+ ibm_ca_support_reboot);
+
if (grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_CAN_TRY_CAS_FOR_MORE_MEMORY))
{
- /* if we have an error, don't call CAS, just hope for the best */
- if (err == GRUB_ERR_NONE && rmo_top < (512 * 1024 * 1024))
- grub_ieee1275_ibm_cas ();
+ /*
+ * If we have an error or the reboot is detected as CAS reboot,
+ * don't call CAS, just hope for the best.
+ * Along with the above, if the rmo_top is 512 MB or above. We
+ * will skip the CAS call. Though if we call CAS, the rmo_top will
+ * be set to 768 MB via CAS Vector2. This condition is required to avoid
the
+ * issue where the older Linux kernels are still using rmo_top as 512 MB.
+ * If we call CAS where rmo_top is less then 768 MB, this will result in
an issue
+ * due to IBM CAS reboot feature and we won't be able to boot the newer
kernel.
+ * The machine will boot with the last booted kernel which has rmo_top
as 512 MB.
+ */
+ if (!ibm_ca_support_reboot && err == GRUB_ERR_NONE && rmo_top < (512 *
1024 * 1024))
+grub_ieee1275_ibm_cas ();
}
#endif
--
2.39.3
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 18/73] fs/ntfs: Implement attribute verification
On Sun, 02 Mar 2025 09:41:28 +0100 "Thomas Schmitt" wrote: > Hi, > > Glenn Washburn wrote: > > Seems like running them the tests before > > committing large patch series, like this security update, might be a > > good idea. > > I think that any change of the filesystem code should be tested as > much as possible. > But it is quite some hurdle that some of the tests need to be run as > superuser. Leaking temporary files further reduces the appeal. Yes, not ideal. I have spent an embarrassing amount of time developing scripts that do away with with root requirement, and it works. The way they are able to run the root required tests as an unprivileged user is by compiling a user mode linux kernel and running the tests in the UML process. Would you be interested in trying out these scripts? The leaking of temporary files is also annoying, but quite easy to remedy. One need only set the TMPDIR to a directory and delete the directory when done. > > I wonder what happened to the fixes for the file leaks of > grub_cmd_cryptomount which we discussed in > https://lists.gnu.org/archive/html/grub-devel/2024-09/msg00222.html > and follow-ups. The discussion went on until > https://lists.gnu.org/archive/html/grub-devel/2024-10/msg00054.html > I fail to see "grub_cmd_cryptomount" in git log since october 2024 > or a commit by Glenn Washburn which would address this issue. > > Was there a problem found of which i am not aware ? Thank you for the reminder. I suspect what happened is that Daniel read the thread and expected a v2 based on some changes discussed but not reflected in the series, and so chose not to review the patch series. I meant to send a v2, but hadn't gotten around to it. It is now sent and now that the security patches are out, hopefully Daniel will be able to get to them soon. Glenn > > > Have a nice day :) > > Thomas > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 5/6] tests/grub_cmd_cryptomount: Remove temporary directories if successful and debug is not on
From: Thomas Schmitt
grub_cmd_cryptomount creates a directory per subtest. If a subtest is
successful and debugging is not on, the directory should be empty. So it
can be deleted.
Signed-off-by: Glenn Washburn
---
tests/grub_cmd_cryptomount.in | 9 +
1 file changed, 9 insertions(+)
diff --git a/tests/grub_cmd_cryptomount.in b/tests/grub_cmd_cryptomount.in
index 8dc99127d39e..eaa187efad0a 100644
--- a/tests/grub_cmd_cryptomount.in
+++ b/tests/grub_cmd_cryptomount.in
@@ -54,6 +54,15 @@ _testcase() {
set -- "$@" $([ "${EXPECTEDRES}" -eq 1 ] && echo "--xfail")
output=`"$@" 2>&1` || res=$?
+if [ -z "$debug" ]; then
+if ! rmdir "$TMPDIR" >/dev/null 2>&1; then
+echo
+echo "Note: Temporary directory cannot be removed:"
+echo "$TMPDIR"
+echo " Please inspect and remove manually."
+echo
+fi
+fi
TMPDIR=$_TMPDIR
if [ "$res" -eq "$EXPECTEDRES" ]; then
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
GRUB Error: Couldn't Find Suitable Memory Target for 210MB Initramfs
Hi GRUB-devel team I encountered an issue with a 210MB initramfs where GRUB prints the following error: error: couldn't find suitable memory target. Below are parts of my memory layout: .. mmap/efi/mmap.c:63: EFI memory region 0xdf6e000-0x17238000: 7 mmap/efi/mmap.c:63: EFI memory region 0x17238000-0x23524000: 1 .. mmap/efi/mmap.c:63: EFI memory region 0x5de69000-0x6f80: 7 .. Here are the memory size: 0xdf6e000-0x17238000: 146.79 MB 0x17238000-0x23524000: 194.92 MB 0x5de69000-0x6f80: 281.59 MB Is it possible to merge the first two memory regions, and if so, how can this be achieved? Alternatively, how can I expand the memory region? My grub version is 2.06-1. There is sufficient memory in the region 0x5de69000-0x6f80, but the GRUB_LINUX_INITRD_MAX_ADDRESS is set to 0x37FF. I changed the max address to 0x7FFF and successfully booted the system using the memory in 0x5de69000-0x6f80. Are there any risks associated with this modification on an 64-bit machine? Thank you for your help. Best regards ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [SECURITY PATCH 18/73] fs/ntfs: Implement attribute verification
Hi, i wrote: > > it is quite some hurdle that some of the tests need to be run as > > superuser. Glenn Washburn wrote: > Yes, not ideal. I have spent an embarrassing amount of time developing > scripts that do away with with root requirement, and it works. The way > they are able to run the root required tests as an unprivileged user is > by compiling a user mode linux kernel and running the tests in the UML > process. Would you be interested in trying out these scripts? Yes, if you can describe the necessary activities for a dummy who sends a mail twice because a completely unrelated mail caused protests by the mail provider. (I stopped myself from sending a third mail with an apology.) > > I wonder what happened to the fixes for the file leaks of > > grub_cmd_cryptomount which we discussed in > > https://lists.gnu.org/archive/html/grub-devel/2024-09/msg00222.html > I meant to send a v2, but hadn't gotten around to it. It is now sent and > now that the security patches are out, hopefully Daniel will be able to > get to them soon. I will try to remember what we discussed and how these topics reflect in patch v2. (I will also have to revisit my patch from last summer which was meant to make error messages visible in the tests. When testing it, i ran into the grub_cmd_cryptomount leaks. The patch is archived as [PATCH 0/2] grub-fstest: Show error message if command causes grub_errno https://lists.gnu.org/archive/html/grub-devel/2024-06/msg00197.html of which the first motivating paragraph of the cover letter was eaten by git send-email and later added by https://lists.gnu.org/archive/html/grub-devel/2024-06/msg00201.html Especially i will have to compare it with your recent patch set [PATCH v6 0/6] More ls improvements https://lists.gnu.org/archive/html/grub-devel/2025-03/msg00012.html and check whether our patch sets overlap. ) Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 4/6] tests/grub_cmd_cryptomount: Default TMPDIR to /tmp
This fixes behavior where grub_cmd_cryptomount temporary files, which are
some times not cleaned up, are left in the / directory. Set TMPDIR if your
system does not have /tmp or it can not be used for some reason.
Reported-by: Thomas Schmitt
Signed-off-by: Glenn Washburn
---
tests/grub_cmd_cryptomount.in | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/grub_cmd_cryptomount.in b/tests/grub_cmd_cryptomount.in
index 2fba8a8e0e3a..8dc99127d39e 100644
--- a/tests/grub_cmd_cryptomount.in
+++ b/tests/grub_cmd_cryptomount.in
@@ -47,8 +47,9 @@ _testcase() {
shift 2
# Create a subdir in TMPDIR for each testcase
-_TMPDIR=$TMPDIR
-TMPDIR=$TMPDIR/`echo -n "$(date +%s).$LOGPREFIX" | sed -e 's,[ /],_,g' -e
's,:$,,g'`
+_TMPDIR=${TMPDIR:-/tmp}
+TMPDIR=${_TMPDIR}/`echo -n "$(date +%s).${LOGPREFIX}" | sed -e 's,[
/],_,g' -e 's,:$,,g'`
+export TMPDIR
mkdir -p "$TMPDIR"
set -- "$@" $([ "${EXPECTEDRES}" -eq 1 ] && echo "--xfail")
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 2/6] tests: Cleanup generated files on expected failure in grub_cmd_cryptomount
grub-shell-luks-tester only cleans up generated files when the test it
runs returns success. Sometimes tests are run that should fail. Add a
--xfail argument to grub-shell-luks-tester and pass it from
grub_cmd_cryptomount when invoking a test that is expected to fail.
Reported-by: Thomas Schmitt
Signed-off-by: Glenn Washburn
---
tests/grub_cmd_cryptomount.in| 1 +
tests/util/grub-shell-luks-tester.in | 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/tests/grub_cmd_cryptomount.in b/tests/grub_cmd_cryptomount.in
index f4d8f35473d0..63ed8e51bec3 100644
--- a/tests/grub_cmd_cryptomount.in
+++ b/tests/grub_cmd_cryptomount.in
@@ -48,6 +48,7 @@ _testcase() {
_TMPDIR=$TMPDIR
TMPDIR=$TMPDIR/`echo -n "$(date +%s).$LOGPREFIX" | sed -e 's,[ /],_,g' -e
's,:$,,g'`
mkdir -p "$TMPDIR"
+set -- "$@" $([ "${EXPECTEDRES}" -eq 1 ] && echo "--xfail")
output=`"$@" 2>&1` || res=$?
TMPDIR=$_TMPDIR
diff --git a/tests/util/grub-shell-luks-tester.in
b/tests/util/grub-shell-luks-tester.in
index 855ad39c19c3..abb0013e4387 100644
--- a/tests/util/grub-shell-luks-tester.in
+++ b/tests/util/grub-shell-luks-tester.in
@@ -36,6 +36,7 @@ keyfile=
keyfile_offset=
keyfile_size=
KEYFILE_SIZE_MAX=4096
+expected_res=0
debug="${GRUB_SHELL_LUKS_DEFAULT_DEBUG:-$GRUB_TEST_DEFAULT_DEBUG}"
GRUB_SHELL_LUKS_TIMEOUT=${GRUB_SHELL_LUKS_TIMEOUT:-${GRUB_SHELL_DEFAULT_TIMEOUT:-600s}}
@@ -58,6 +59,7 @@ running in a QEMU instance.
--detached-header Use a detached header
--keyfile[=FILE]Use a randomly generated key file of size
$KEYFILE_SIZE_MAX if not
given a FILE to use as the key file.
+ --xfail Expected failure, so cleanup as if on success
$0 creates a LUKS disk with cryptsetup, then verify that it is accessible by
grub running in a QEMU instance.
@@ -118,6 +120,8 @@ for option in "$@"; do
--disksize=*)
qs=`echo "$option" | sed -e 's/--disksize=//'`
disksize="$qs" ;;
+--xfail)
+expected_res=1 ;;
-*)
echo "Unrecognized option \`$option'" 1>&2
usage
@@ -147,7 +151,7 @@ cleanup() {
if [ -e "$luksdev" ]; then
cryptsetup close "$luksdev"
fi
-if [ -z "$debug" ] && [ "${RET:-1}" -eq 0 ]; then
+if [ -z "$debug" ] && [ "$RET" -eq "$expected_res" ]; then
rm -rf "$lukstestdir" || :
fi
}
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 6/6] tests/util/grub-shell: Remove the work directory on successful run and debug is not on
This removes alot of empty grub-shell working directories in the TMPDIR
directory.
Signed-off-by: Thomas Schmitt
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/util/grub-shell.in b/tests/util/grub-shell.in
index 15c5f45a5c30..af3d31ef4609 100644
--- a/tests/util/grub-shell.in
+++ b/tests/util/grub-shell.in
@@ -715,6 +715,7 @@ test -n "$debug" || rm -f "${isofile}"
test -n "$debug" || rm -rf "${rom_directory}"
test -n "$debug" || rm -f "${tmpfile}" "${cfgfile}" "${goutfile}"
test -n "$debug" || rm -f "$work_directory/run.sh"
+test -n "$debug" || rmdir "$work_directory"
exit $ret
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 1/6] tests/util/grub-shell-luks-tester: Add missing line to create RET variable in cleanup
Set the RET variable to the exit status of the script, as was assumed in the
cleanup() function.
Reported-by: Thomas Schmitt
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell-luks-tester.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/util/grub-shell-luks-tester.in
b/tests/util/grub-shell-luks-tester.in
index b2a8a91b41f2..855ad39c19c3 100644
--- a/tests/util/grub-shell-luks-tester.in
+++ b/tests/util/grub-shell-luks-tester.in
@@ -143,6 +143,7 @@ fi
# Make sure that the dm-crypto device is shutdown
cleanup() {
+RET=$?
if [ -e "$luksdev" ]; then
cryptsetup close "$luksdev"
fi
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 0/6] Various test fixes proposed by Thomas Schmitt
Thomas Schmitt proposed variations on these fixes[1]. I've broken his
patch into several patches with improvements.
Glenn
[1] https://lore.kernel.org/all/9956308756800479...@scdbackup.webframe.org/
v2:
* Add patch #2 to allow grub-shell-luks-tester to cleanup properly on expected
failure.
* Add patch #5 to remove empty directories left by the cryptomount tests.
Glenn Washburn (5):
tests/util/grub-shell-luks-tester: Add missing line to create RET
variable in cleanup
tests: Cleanup generated files on expected failure in
grub_cmd_cryptomount
tests/grub_cmd_cryptomount: Cleanup the cryptsetup script unless debug
is enabled
tests/grub_cmd_cryptomount: Default TMPDIR to /tmp
tests/util/grub-shell: Remove the work directory on successful run and
debug is not on
Thomas Schmitt (1):
tests/grub_cmd_cryptomount: Remove temporary directories if successful
and debug is not on
tests/grub_cmd_cryptomount.in| 18 --
tests/util/grub-shell-luks-tester.in | 7 ++-
tests/util/grub-shell.in | 1 +
3 files changed, 23 insertions(+), 3 deletions(-)
Range-diff against v1:
1: 50ea280aa138 = 1: e686c1848ab1 tests/util/grub-shell-luks-tester: Add
missing line to create RET variable in cleanup
-: > 2: f94ebf9f040e tests: Cleanup generated files on expected
failure in grub_cmd_cryptomount
2: 4d8fca393bfd ! 3: 1d1faee928cf tests: Cleaup the cryptsetup script in
grub_cmd_cryptomount unless debug is enabled
@@ Metadata
Author: Glenn Washburn
## Commit message ##
-tests: Cleaup the cryptsetup script in grub_cmd_cryptomount unless
debug is enabled
+tests/grub_cmd_cryptomount: Cleanup the cryptsetup script unless debug
is enabled
This fixes an issue where the grub_cmd_cryptomount test leaves a file
with an ambiguous name in the / directory when TMPDIR is not set.
3: e32175b06be6 ! 4: 5f1b424919b2 tests: Default TMPDIR to /tmp in
grub_cmd_cryptomount tests
@@ Metadata
Author: Glenn Washburn
## Commit message ##
-tests: Default TMPDIR to /tmp in grub_cmd_cryptomount tests
+tests/grub_cmd_cryptomount: Default TMPDIR to /tmp
This fixes behavior where grub_cmd_cryptomount temporary files, which
are
some times not cleaned up, are left in the / directory. Set TMPDIR if
your
@@ tests/grub_cmd_cryptomount.in: _testcase() {
+TMPDIR=${_TMPDIR}/`echo -n "$(date +%s).${LOGPREFIX}" | sed -e 's,[
/],_,g' -e 's,:$,,g'`
+export TMPDIR
mkdir -p "$TMPDIR"
+ set -- "$@" $([ "${EXPECTEDRES}" -eq 1 ] && echo "--xfail")
- output=`"$@" 2>&1` || res=$?
-: > 5: 779233064126 tests/grub_cmd_cryptomount: Remove
temporary directories if successful and debug is not on
4: 6ef75566e50b = 6: e9fc44e07539 tests/util/grub-shell: Remove the work
directory on successful run and debug is not on
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH v2 3/6] tests/grub_cmd_cryptomount: Cleanup the cryptsetup script unless debug is enabled
This fixes an issue where the grub_cmd_cryptomount test leaves a file
with an ambiguous name in the / directory when TMPDIR is not set.
Reported-by: Thomas Schmitt
Signed-off-by: Glenn Washburn
---
tests/grub_cmd_cryptomount.in | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/grub_cmd_cryptomount.in b/tests/grub_cmd_cryptomount.in
index 63ed8e51bec3..2fba8a8e0e3a 100644
--- a/tests/grub_cmd_cryptomount.in
+++ b/tests/grub_cmd_cryptomount.in
@@ -37,6 +37,8 @@ fi
COMMON_OPTS='${V:+--debug=$V} --cs-opts="--pbkdf-force-iterations 1000"'
+debug=${GRUB_SHELL_DEFAULT_DEBUG:-$GRUB_TEST_DEFAULT_DEBUG}
+
_testcase() {
local EXPECTEDRES=$1
local LOGPREFIX=$2
@@ -183,4 +185,5 @@ eval testcase "'LUKS2 test with second key slot and first
slot using different p
@builddir@/grub-shell-luks-tester $LUKS2_COMMON_OPTS $COMMON_OPTS \
"--cs-script='$csscript'"
+test -n "$debug" || rm "$csscript"
exit 0
--
2.34.1
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Feedback Request: Implement Fuzzers and Add to OSS-Fuzz
> On Feb 28, 2025, at 7:57 AM, Andrew Hamilton wrote: > > Yes that sounds great, I am back from vacation just now so will be generally > free any time between 0800 and 2100 Central Standard Time. I’m mostly available from 9am PT onward. Thanks, Lidong > > Thanks, > Andrew > On Fri, Feb 28, 2025 at 7:33 AM Daniel Kiper wrote: > Adding Daniel Axtens, Lidong and Nils... > > On Thu, Feb 27, 2025 at 01:22:15PM -0500, Andrew Hamilton wrote: > > Hello, > > > > I’m looking for feedback on whether there would be project interest / > > support > > on me creating an initial fuzz test suite for some core GRUB functions and > > then > > integrating these fuzzers into the OSS-Fuzz project that would run them and > > automate bug reporting to project owners / maintainers on some predefined > > periodic basis. > > https://github.com/google/oss-fuzz > > > > Fuzzing helps find program correctness issues like out of bounds accesses, > > use > > after free, crashes, etc. that can sometimes be used for malicious > > purposes. > > > > To get a sense of what a fuzzer suite looks like you could reference an > > existing project integrated into oss-fuzz like GNUTLS: > > https://gitlab.com/gnutls/gnutls/-/tree/master/fuzz?ref_type=heads > > > > There is some project setup as well in the oss-fuzz repo similar to: > > https://github.com/google/oss-fuzz/tree/master/projects/gnutls > > > > If there is favorable feedback I would perform the following general steps: > > 1. Identify core GRUB functions to fuzz first (likely those usable in > > lockdown > > and seen as most likely to be widely used at first, and that are seen as a > > possible source of untrusted input). > > 2. In a private fork of GRUB (with core GRUB maintainers invited): > > a. Get a fuzz target added to the build system. > > b. Implement fuzzers for the core features. > > c. Fix issues identified by the fuzzers, if any. > > d. Create docs around how to build the fuzzers, run them, and locally > > troubleshoot issues > >e. Submit patches to the maintainers and (if not sensitive due to > > uncovered > > vulnerabilities) to this mailing list for review. > >f. With maintainers support, get the fuzzers merged to GRUB mainline. > > 3. Open a new project request in the oss-fuzz repo following their > > documentation: > > a. > > https://github.com/google/oss-fuzz/blob/master/docs/getting-started/accepting_new_projects.md > > b. https://google.github.io/oss-fuzz/getting-started/new-project-guide/ > > 4. If the project approves I’d be willing to serve as the maintainer of the > > fuzzing and oss-fuzz components to ensure build failures are corrected and > > newly identified issues are worked and triaged. > > 5. Over time we can work to improve code coverage via the fuzzers. > > > > > > Pros: > > 1. Increase the code robustness > > 2. Quickly find robustness issues caused by future changes > > Cons: > > 1. Requires up front development to get going- I’m happy to do as much of > > this > > as I can but it will require support from the busy project maintainers for > > reviews and such > > 2. Requires staying on top of new fuzz failures prior to the oss-fuzz > > disclosure deadline (I’m happy to support this as much as I can) - ref > > https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/ > > > > Please let me know your thoughts. > > I think this is good idea! > > May I ask you to work with Daniel Axtens, Lidong and Nils on this? > They were or are looking at the GRUB fuzzing. So, it would be good > join the forces. I think it would be nice to setup a call when all > of you are OK to work on the project... > > Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/1] lib: Fix clang Build - Remove Duplicate Typedef in TSS
On Sun, Mar 02, 2025 at 10:54:04AM -0600, Andrew Hamilton wrote: > tss2_structs.h contains a duplicate typedef as follows: > typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF2_t; > > This causes a build failure when compiling with clang. > Remove the duplicate typedef which allows successfully > building GRUB with clang. > Oops. Thanks for fixing that. > Signed-off-by: Andrew Hamilton Reviewed-by: Gary Lin > --- > grub-core/lib/tss2/tss2_structs.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/grub-core/lib/tss2/tss2_structs.h > b/grub-core/lib/tss2/tss2_structs.h > index e5390ab56..2eefba87c 100644 > --- a/grub-core/lib/tss2/tss2_structs.h > +++ b/grub-core/lib/tss2/tss2_structs.h > @@ -275,7 +275,6 @@ typedef TPMS_SCHEME_HASH_t TPMS_ENC_SCHEME_OAEP_t; > typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF2_t; > typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_MGF1_t; > typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF1_SP800_56A_t; > -typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF2_t; > typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF1_SP800_108_t; > > /* TPMS_SCHEME_HMAC Type */ > -- > 2.39.5 > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH 1/1] lib: Fix clang Build - Remove Duplicate Typedef in TSS
On 3/2/25 8:54 AM, Andrew Hamilton wrote: tss2_structs.h contains a duplicate typedef as follows: typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF2_t; This causes a build failure when compiling with clang. Remove the duplicate typedef which allows successfully building GRUB with clang. Signed-off-by: Andrew Hamilton --- grub-core/lib/tss2/tss2_structs.h | 1 - 1 file changed, 1 deletion(-) diff --git a/grub-core/lib/tss2/tss2_structs.h b/grub-core/lib/tss2/tss2_structs.h index e5390ab56..2eefba87c 100644 --- a/grub-core/lib/tss2/tss2_structs.h +++ b/grub-core/lib/tss2/tss2_structs.h @@ -275,7 +275,6 @@ typedef TPMS_SCHEME_HASH_t TPMS_ENC_SCHEME_OAEP_t; typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF2_t; typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_MGF1_t; typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF1_SP800_56A_t; -typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF2_t; typedef TPMS_SCHEME_HASH_t TPMS_SCHEME_KDF1_SP800_108_t; /* TPMS_SCHEME_HMAC Type */ Yes I can see why that would cause problems... Reviewed-by: Ross Philipson ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
