Hi,
Lidong Chen wrote:
> I ran grub-fastest with both ce_loop ISO files. The endless loops were
> detected and Grub exited accordingly.
Good.
> I didn't know where the grub error message
> were stored in case of grub-fastest.
So you don't see an error message ?
I had the same problem a while
On Jan 20, 2023, at 3:49 AM, Thomas Schmitt
mailto:scdbac...@gmx.net>> wrote:
Hi,
Lidong Chen wrote:
I ran grub-fastest with both ce_loop ISO files. The endless loops were
detected and Grub exited accordingly.
Good.
I didn't know where the grub error message
were stored in case of grub-fast
If processing of a SUSP CE entry leads to a continuation area which
begins by entry CE or ST, then these entries were skipped without
interpretation. In case of CE this would lead to premature end of
processing the SUSP entries of the file. In case of ST this could
cause following non-SUSP bytes to
There is no check for the end of block when reading
directory extents. It resulted in read_node() always
read from the same offset in the while loop, thus
caused infinite loop. The fix added a check for the
end of the block and ensure the read is within directory
boundary.
Signed-off-by: Lidong Ch
This v3 patches set addressed v2 review comments for patch 5.
There is no changes to patch 1 to 4. Tested patch 5, the fixes
were able to detect the endless loop, and Grub exited accordingly.
Lidong Chen (5):
fs/iso9660: Add check to prevent infinite loop
fs/iso9660: Prevent read past the end
An SL entry consists of the entry info and the component area.
The entry info should take up 5 bytes instead of sizeof (*entry).
The area after the first 5 bytes is the component area. It is
incorrect to use the sizeof (*entry) to check the entry boundary.
Signed-off-by: Lidong Chen
Reviewed-by:
Added a check for the SP entry data boundary before reading it.
Signed-off-by: Lidong Chen
Reviewed-by: Thomas Schmitt
---
grub-core/fs/iso9660.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/grub-core/fs/iso9660.c b/grub-core/fs/iso9660.c
index 65c8862b6
In the code, the for loop advanced the entry pointer to the
next entry before checking if the next entry is within the
system use area boundary. Another issue in the code was that
there is no check for the size of system use area. For a
corrupted system, the size of system use area can be less than
This series unifies the linux loader for ARM64 & RISC-V. The linux loader
for ARM64 is pretty much arch independent. Thus, this series just moves
it to the common directory and update the make files.
This series also removes the arch specific kernel image haders for
ARM64 & RISC-V as suggested on
ARM64 linux loader code is written in such a way that it can be reused
across different architectures without much change. Move it to common
code so that RISC-V doesn't have to define a separate loader.
Signed-off-by: Atish Patra
Reviewed-by: Daniel Kiper
---
grub-core/Makefile.core.def
RISC-V doesn't have to do anything very different from other architectures
to loader EFI stub linux kernel. As a result, just use the common linux
loader instead of defining a RISC-V specific linux loader.
Signed-off-by: Atish Patra
Reviewed-by: Daniel Kiper
---
grub-core/Makefile.core.def|
The arch specific image header details are not very useful as
most of the grub just looks at the PE/COFF spec parameters (PE32 magic
and header offset).
Remove the arch specific images headers and define a generic
arch headers that provide enough PE/COFF fields for grub to parse kernel
images corr
Signed-off-by: Glenn Washburn
---
include/grub/misc.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/grub/misc.h b/include/grub/misc.h
index ddac3aae8b..6c9d56de92 100644
--- a/include/grub/misc.h
+++ b/include/grub/misc.h
@@ -335,8 +335,6 @@ char *EXPORT_FUNC(gr
This allows turning on shell tracing for grub-shell and grub-fs-tester when
its not practical or not possible to use commandline arguments (eg. from
`make check`). Turn on tracing when the envvar is an integer greater than 1,
since these can generate a lot of output. Since this change uses the
envi
Now it becomes trivial to re-run a test from the output in its working
directory. This also makes it easy to send a reproducible failing test to
the mailing list. This has allowed a refactor so that the duplicated code
to call QEMU has be condensed (eg. the use of timeout and file descriptor
redire
When re-running a failed test, even the non-standard grub-shell QEMU
arguments should be preserved in the run.sh to more precisely replay the
failed test run.
Signed-off-by: Glenn Washburn
---
tests/util/grub-shell.in | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/te
When a non-native (eg. grub-shell/qemu) test fails it can be useful to be
able to re-run the grub-shell invocation in at least two circumstances.
1. The tester wants to re-run the grub-shell invocation with extra args so
that QEMU starts in GDB attach mode for using GDB to debug the test case
2
The current qemu firmware paths for arm-efi and arm64-efi are not available
on Ubuntu/Debian but are hardcoded. Switch to first looking for firmware
files in the source directory and if not found, look for them in locations
where Debian installs them. Prefer to use the firmware file usable with the
18 matches
Mail list logo
