Re: x86: Apply microcode updates in GRUB?

[Paul Menzel]

Dear Dimitri,


Thank you for your answer.

Am 08.08.23 um 17:25 schrieb Dimitri John Ledkov:

On Sat, 29 Jul 2023 at 06:54, Paul Menzel wrote:



On x86 microcode updates often are recommended to be applied to fix
bugs. Just recently new microcode updates where published for AMD Zen 2
processors to fix “Zenbleed” [1].

Currently, these updates are shipped and applied by the firmware, and –
mainly due to the proprietary and closed source x86 firmware ecosystem
is slow to ship these updates and firmware updates are cumbersome to
apply in this ecosystem – the operating systems like the Linux kernel
[2] (but I believe also Microsoft Windows) also support to apply these
updates.

Should boot loaders be able to apply these updates, so these can be
applied on systems for operating systems without such a feature?


Most distributions already do this via early-initrd. For example, on
all ubuntu systems if you unpack initramfs with `unmkinitramfs`
command you will notice early1 and early2 uncompressed initrd portions
that contain Intel and AMD microcode. these are loaded and applied by
kernel early on, before unpacking the rest of the initrd or
initialising the system.

Specifically for Zenbleed, Ubuntu Security team has shipped
amd64-microcode package at CRD time, which is automatically installed
by all systems and thus a reboot has already applied those.


Does CRD mean Cargo Ready Date?

Thank you for the explanation. I was well aware of that. It is very 
GNU/Linux focused though, and GRUB also loads other programs. If the 
boot loader would do that, not all operating systems would need to 
implement that. Anyway, it’s present in the Linux kernel, so – as a 
Linux user – I can still use that.



This is a standard mechanism that is already implemented by all
distributions (i.e. Ubuntu, Ubuntu Core, Fedora, etc). If your
distribution/device doesn't install and doesn't generate early initrd,
please implement that. Reference implementations are available in
initramfs-tools (debian/ubuntu), core-initrd (ubuntu core), dracut,
and likely many others.


Back then, reading up on the choices, I do not like this, as you need 
the wrappers `lsinitramfs` and `unmkinitramfs` to easily deal with these 
files. For our distribution MarIuX we went the separate files for the 
microcode update archives, and let GRUB load them and pass to the Linux 
kernel [3].



It is a nice property to bundle this in the initrd, as sometimes there
are microcode regressions, thus booting old kernel abi, with an old
initrd, with an old microcode is desirable.


It’s a two-edged sword, as people do not know what microcode updates are 
going to be applied using older boot entries.



Kind regards,

Paul



[1]: https://lock.cmpxchg8b.com/zenbleed.html
[2]: https://docs.kernel.org/arch/x86/microcode.html[3]: 
https://github.molgen.mpg.de/mariux64/mxtools/pull/342


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v1] readd build dependency for startup_raw.S

[Paul Menzel]

Dear Glenn,


Am 16.08.23 um 21:33 schrieb Glenn Washburn:


There's an extra 'd' in read in the subject line.


I think it’s supposed to be “re-add”, that means to add it back.


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/1] configure.ac: Fix SDL2 typo by referencing value

[Paul Menzel]

Dear Michał,


Thank you for your patch.

Am 19.07.23 um 00:48 schrieb Michał Grzelak:

During configuration of SDL2, variable enable_grub_emu_sdl2 is checked
whether to throw an error message. Howerever, error could not happen


However


because two unequal strings were compared. Fix this by referencing
value of enable_grub_emu_sdl2, not name.

Fixes: 17d6ac1a7 (emu: Add SDL2 support)

Signed-off-by: Michał Grzelak 
---
  configure.ac | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 01500ffdf..27c5918fa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1609,7 +1609,7 @@ if test "$platform" = emu; then
  AC_SUBST(HAVE_SDL2)],
  [grub_emu_sdl2_excuse="libSDL2 libraries are required to build 
\`grub-emu' with SDL2 support"])
[fi]
-  if test x"enable_grub_emu_sdl2" = xyes && test x"$grub_emu_sdl2_excuse" != x 
; then
+  if test x"$enable_grub_emu_sdl2" = xyes && test x"$grub_emu_sdl2_excuse" != 
x ; then
  AC_MSG_ERROR([SDL2 support for grub-emu was explicitly requested but 
can't be compiled ($grub_emu_sdl2_excuse)])
fi
if test x"$grub_emu_sdl2_excuse" = x ; then


Reviewed-by: Paul Menzel 


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Red Hat job offer: Principal Software Engineer for bootloader

[Paul Menzel]

Dear GRUB folks,


I just read on Phoronix [1], that Red Hat published a job offer for a 
Principal Software Engineer working on the “Linux bootloader” [2]. One 
of the tasks:



Contribute to feature enhancements and bug fixes in projects
including the Linux kernel, grub2, shim, and associated tools and
toolchains


Kind regards,

Paul


[1]: https://www.phoronix.com/news/Red-Hat-Hiring-Bootloader
[2]: 
https://global-redhat.icims.com/jobs/100038/principal-software-engineer/job?mobile=false&width=1140&height=500&bga=true&needsRedirect=false&jan1offset=60&jun1offset=120


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

grub-core/lib/gnulib/argp.h:529:6: error: ‘_GL_ATTRIBUTE_SPEC_PRINTF_SYSTEM’ is an unrecognized format function type [-Werror=format=]

[Paul Menzel]

Dear GRUB folks,


On Debian sid/unstable with *gcc-12* 12.3.0-7, *gcc-13* 13.2.0-1, and 
*clang* 1:14.0-55.7, since commit 2b7902459803 (gnulib: Update gnulib 
version and drop most gnulib patches), I am unable to build GRUB for the 
platform *coreboot* [1]:


```
$ git clean -dfx && ./configure --with-platform=coreboot && make -j4 
default_payload.elf

[…]
***
GRUB2 will be compiled with following components:
Platform: i386-coreboot
With devmapper support: No (need libdevmapper header)
With memory debugging: No
With disk cache statistics: No
With boot time statistics: No
efiemu runtime: Yes
grub-mkfont: Yes
grub-mount: No (need fuse or fuse3 libraries)
starfield theme: No (No DejaVu found)
With libzfs support: No (need zfs library)
Build-time grub-mkfont: Yes
With unifont from /usr/share/fonts/X11/misc/unifont.pcf.gz
With liblzma from -llzma (support for XZ-compressed mips images)
With stack smashing protector: No
***

real0m23,192s
user0m15,074s
sys 0m6,481s
gcc -DHAVE_CONFIG_H -I.  -Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64 
-I./include -DGRUB_FILE=\"util/grub-mkstandalone.c\" -I. -I. -I. -I. 
-I./include -I./include -I./grub-core/lib/libgcrypt-grub/src/ 
-I./grub-core/lib/gnulib -I./grub-core/lib/gnulib 
-D_FILE_OFFSET_BITS=64 -std=gnu99 -fno-common  -Wall -W -Wshadow 
-Wpointer-arith -Wundef -Wchar-subscripts -Wcomment 
-Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero 
-Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k 
-Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wmain 
-Wmissing-braces -Wmissing-format-attribute -Wmultichar -Wparentheses 
-Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wswitch 
-Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label 
-Wunused-parameter -Wunused-value  -Wunused-variable -Wwrite-strings 
-Wnested-externs -Wstrict-prototypes -Wcast-align  -Wextra -Wattributes 
-Wendif-labels -Winit-self -Wint-to-pointer-cast -Winvalid-pch 
-Wmissing-field-initializers -Wnonnull -Woverflow -Wvla 
-Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros 
-Wvolatile-register-var -Wpointer-sign -Wmissing-include-dirs 
-Wmissing-prototypes -Wmissing-declarations -Wformat=2 -Werror 
-Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter 
-Wno-redundant-decls -Wno-unreachable-code -Wno-conversion   -MT 
util/grub_mkstandalone-grub-mkstandalone.o -MD -MP -MF 
util/.deps-util/grub_mkstandalone-grub-mkstandalone.Tpo -c -o 
util/grub_mkstandalone-grub-mkstandalone.o `test -f 
'util/grub-mkstandalone.c' || echo './'`util/grub-mkstandalone.c

In file included from util/grub-mkstandalone.c:29:
./grub-core/lib/gnulib/argp.h:529:6: error: 
‘_GL_ATTRIBUTE_SPEC_PRINTF_SYSTEM’ is an unrecognized format function 
type [-Werror=format=]

  529 |  ;
  |  ^
./grub-core/lib/gnulib/argp.h:537:6: error: 
‘_GL_ATTRIBUTE_SPEC_PRINTF_SYSTEM’ is an unrecognized format function 
type [-Werror=format=]

  537 |  ;
  |  ^
./grub-core/lib/gnulib/argp.h:555:6: error: 
‘_GL_ATTRIBUTE_SPEC_PRINTF_SYSTEM’ is an unrecognized format function 
type [-Werror=format=]

  555 |  ;
  |  ^
./grub-core/lib/gnulib/argp.h:564:6: error: 
‘_GL_ATTRIBUTE_SPEC_PRINTF_SYSTEM’ is an unrecognized format function 
type [-Werror=format=]

  564 |  ;
  |  ^
cc1: all warnings being treated as errors
make: *** [Makefile:10872: util/grub_mkstandalone-grub-mkstandalone.o] 
Fehler 1

```

Building the default platform first

git clean -dfx && ./bootstrap && ./configure && make

then the build for the platform *coreboot* succeeds:

make clean && ./configure --with-platform=coreboot && make


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

x86: Apply microcode updates in GRUB?

[Paul Menzel]

Dear GRUB folks,


On x86 microcode updates often are recommended to be applied to fix 
bugs. Just recently new microcode updates where published for AMD Zen 2 
processors to fix “Zenbleed” [1].


Currently, these updates are shipped and applied by the firmware, and – 
mainly due to the proprietary and closed source x86 firmware ecosystem 
is slow to ship these updates and firmware updates are cumbersome to 
apply in this ecosystem – the operating systems like the Linux kernel 
[2] (but I believe also Microsoft Windows) also support to apply these 
updates.


Should boot loaders be able to apply these updates, so these can be 
applied on systems for operating systems without such a feature?



Kind regards,

Paul


[1]: https://lock.cmpxchg8b.com/zenbleed.html
[2]: https://docs.kernel.org/arch/x86/microcode.html

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] docs: Improve initrd documentation

[Paul Menzel]

Dear Glenn,


Thank you for all your work on GRUB.

Am 28.06.23 um 12:12 schrieb Glenn Washburn:

Remove reference to "initial ramdisk" and replace with "initrd". This then
covers the case of ramdisk and ramfs, which is the usual method with kernels
2.6 and greater. Add sentence with URL to initrd documentation Linux kernel.
Also, add a section documenting how to have the initrd command generate a
new-style initrd via a specially crafted argument and include an example.


(I’d format this as a list.)



Update initrd16 to refer to the initrd section and make note that initrd16
is only on the pc platform.

Signed-off-by: Glenn Washburn 
---
  docs/grub.texi | 46 --
  1 file changed, 40 insertions(+), 6 deletions(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index b39b72230c6f..bea86669191b 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4076,10 +4076,43 @@ load a defective boot loader, such as SCO UnixWare 7.1.
  @subsection initrd
  
  @deffn Command initrd file [file @dots{}]

-Load, in order, all initial ramdisks for a Linux kernel image, and set
-the appropriate parameters in the Linux setup area in memory.  This may only
-be used after the @command{linux} command (@pxref{linux}) has been run.  See
-also @ref{GNU/Linux}.
+Load, in order, all initrds for a Linux kernel image, and set the
+appropriate parameters in the Linux setup area in memory.  This may only
+be used after the @command{linux} command (@pxref{linux}) has been run.
+See @ref{GNU/Linux} for more info on booting GNU/Linux.  For more
+information on initrds see the GNU/Linux kernel
+@uref{https://docs.kernel.org/filesystems/ramfs-rootfs-initramfs.html,
+documentation} on them.


The “on them” at the end sounds like a leftover. But I am no native speaker.


+
+A new-style initrd (for kernels greater than 2.6) containing one file
+with leading path components can also be generated at run time. This
+can be done by prefixing an argument with @code{newc:} followed by the
+path of the file in the new initrd, a @code{:}, and then the GRUB file
+path to the file data to be be included.
+
+For example:
+@example
+initrd newc:/etc/ssh/config:(hd0,2)/home/user/.ssh/config \
+   newc:/etc/ssh/ssh_host_rsa_key:/etc/ssh/ssh_host_rsa_key \
+   /boot/initrd.gz \
+   newc:/init:/home/user/init.fixed
+@end example
+
+This command will generate two new-style initrds on the fly. The first
+contains the path @samp{/etc/ssh/config} with the contents of
+@samp{(hd0,2)/home/user/.ssh/config} and the path
+@samp{/etc/ssh/ssh_host_rsa_key} with the contents of
+@samp{/etc/ssh/ssh_host_rsa_key} on the @var{root} device. Parent directory
+paths will automatically be generated as needed. This first generated initrd
+will then have @samp{/boot/initrd.gz} concatenated after it. Next, another
+new-style archive will be generated with the contents of 
@samp{/home/user/init.fixed}
+in the path @samp{/init} and appended to the previous concatenation. Finally,
+the result will be sent to the kernel when booted.
+
+Keep in mind that paths that comes later will take precendence. So in the


1.  come later
2.  precedence


+example above, the generated path @samp{/init} will overwrite any @samp{/init}
+in @samp{/boot/initrd.gz}. This can be useful when changing the main initrd
+is undesirable or difficult.
  @end deffn


(Today I learned something new. Nice feature.)

  
  
@@ -4090,9 +4123,10 @@ also @ref{GNU/Linux}.

  Load, in order, all initial ramdisks for a Linux kernel image to be booted in
  16-bit mode, and set the appropriate parameters in the Linux setup area in
  memory.  This may only be used after the @command{linux16} command
-(@pxref{linux16}) has been run.  See also @ref{GNU/Linux}.
+(@pxref{linux16}) has been run.  See also @ref{GNU/Linux} and the 
@command{initrd}
+(@pxref{initrd}) for more details.
  
-This command is only available on x86 systems.

+This command is only available on the pc platform for x86 systems.
  @end deffn


Reviewed-by: Paul Menzel 


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

All Systems Go! 2023 (Berlin, 13/14. 09. 23): Call for Participation ends July 7th

[Paul Menzel]

Dear GRUB folks,



All Systems Go! 2023 Call for Proposals

The Call for Participation (CFP) for All Systems Go! 2023 is now
open! Please submit your proposals for consideration.

The CFP will close on July 7th, 2023. A response will be sent to all
submitters on or before July 14th, 2023. The conference takes place
in 🗺️ Berlin, Germany 🇩🇪 on Sept. 13-14th.

All Systems Go! 2023 is all about foundational open-source Linux
technologies. We are primarily looking for deeply technical talks by
and for developers, engineers and other technical roles.

We focus on the userspace side of things, so while kernel topics are
welcome they must have clear, direct relevance to userspace. The
following is a non-comprehensive list of topics encouraged for 2023
submissions:

 *  Image-Based Linux 🖼️ 
 *  Secure and Measured Boot 📏 
 *  TPM-Based Local/Remote Attestation, Encryption, Authentication 🔑 
 *  Low-level container executors and infrastructure ⚙️. 
 *  IoT, embedded and server Linux infrastructure 
 *  Reproducible builds 🔧 
 *  Package management, OS, container 📦, image delivery and updating 
 *  Building Linux devices and applications 🏗️ 
 *  Low-level desktop 💻 technologies 
 *  Networking 🌐 
 *  System and service management 🚀 
 *  Tracing and performance measuring 🔍 
 *  IPC and RPC systems 🦜 
 *  Security 🔐 and Sandboxing 🏖️ 


Format: submissions must be in one of three formats: 35min talk + 5
min Q&A, 20min talk + 5 min Q&A, and 5min lightning talks.

Please familiarize yourself with our Code of Conduct as all speakers
and attendees are expected to abide by it.

You can enter proposals until 2023-07-07 23:59 (UTC)


It’d be great if you could participate to communicate with the other 
projects and also present GRUB.



Kind regards,

Paul


[1]: https://cfp.all-systems-go.io/all-systems-go-2023/cfp

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] docs: Consistently spell *boot loader* with space in paragraph

[Paul Menzel]

Signed-off-by: Paul Menzel 
---
 docs/grub.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index 50c811a88..1c94cf192 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -925,7 +925,7 @@ magic.
 
 GRUB has three distinct boot methods: loading an operating system
 directly, using kexec from userspace, and chainloading another
-bootloader. Generally speaking, the first two are more desirable
+boot loader. Generally speaking, the first two are more desirable
 because you don't need to install or maintain other boot loaders and
 GRUB is flexible enough to load an operating system from an arbitrary
 disk/partition. However, chainloading is sometimes required, as GRUB
-- 
2.38.1


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Lagging cursor in GRUB menu with HiDPI display

[Paul Menzel]

Dear GRUB folks,


Trying to navigate the GRUB menu on a HiDPI display (GOP driver), in 
this case a Dell XPS 13 9370, the cursor response is quite lagging. 
Especially in the edit mode (c) moving around a line is quite slow. Each 
step takes, I’d say, half a second.


Using a font with a bigger size, it’s still reproducible.

Is that a known problems, and do you know of workarounds?


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH RESEND v3 2/2] term/gfxterm: Preliminary HiDPI support

[Paul Menzel]

Dear Zhang,


Thank you for your patches for a much needed feature.

Maybe make the commit message summary/title a statement:

term/gfxterm: Add preliminary HiDPI support

Am 27.06.22 um 11:35 schrieb Zhang Boyang:

Currently GRUB's default font is too small to see on a HiDPI monitor.
This patch adds preliminary HiDPI support to gfxterm. It introduces a
new environment variable 'gfxterm_scale'. If set to 0, and a high
resolution monitor is detected, it will scale the font size
automatically. If set to other number, that number will be the scale
factor, overriding automatic scale factor calculation.


Trying to work around the issue, I found the answer to *How can I change 
the resolution of the GRUB menu?* [1] saying to create bigger fonts, 
referencing *Increase Font in GRUB for High DPI Screens* [2]:


sudo grub-mkfont --output=/boot/grub/fonts/DejaVuSansMono24.pf2 \
  --size=24 /usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf

GRUB_FONT=/boot/grub/fonts/DejaVuSansMono24.pf2

Can you elaborate how your scaling approach works quality wise? (I have 
no idea about the font format (pixel, vector?).)



Signed-off-by: Zhang Boyang 
---
  docs/grub.texi   | 11 ++
  grub-core/gfxmenu/view.c |  1 +
  grub-core/term/gfxterm.c | 72 
  include/grub/gfxterm.h   |  3 +-
  4 files changed, 64 insertions(+), 23 deletions(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index 9b902273c..8f82061f6 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3274,6 +3274,7 @@ These variables have special meaning to GRUB.
  * gfxmode::
  * gfxpayload::
  * gfxterm_font::
+* gfxterm_scale::
  * grub_cpu::
  * grub_platform::
  * icondir::
@@ -3548,6 +3549,16 @@ If this variable is set, it names a font to use for text 
on the
  available font.
  
  
+@node gfxterm_scale

+@subsection gfxterm_scale
+
+If this variable is not set, or set to @samp{0}, the @samp{gfxterm}
+graphical terminal will scale the font automatically when a high resolution


*the* graphical terminal

How will it be scaled?


+monitor is detected.  If set to other number, the font scale factor will be
+forced to that number.  Set this to @samp{1} if user don't want


… if the user doesn’t want …


+@samp{gfxterm} to scale the font on screen.
+
+
  @node grub_cpu
  @subsection grub_cpu
  
diff --git a/grub-core/gfxmenu/view.c b/grub-core/gfxmenu/view.c

index 6358004b2..94b9ef4db 100644
--- a/grub-core/gfxmenu/view.c
+++ b/grub-core/gfxmenu/view.c
@@ -546,6 +546,7 @@ init_terminal (grub_gfxmenu_view_t view)
 view->terminal_rect.height,
 view->double_repaint,
 terminal_font,
+   1,
 view->terminal_border);
grub_gfxterm_decorator_hook = grub_gfxmenu_draw_terminal_box;
  }
diff --git a/grub-core/term/gfxterm.c b/grub-core/term/gfxterm.c
index 4512dee6f..df2d3f86b 100644
--- a/grub-core/term/gfxterm.c
+++ b/grub-core/term/gfxterm.c
@@ -82,6 +82,7 @@ struct grub_virtual_screen
  
/* Font settings. */

grub_font_t font;
+  unsigned int scale;
  
/* Terminal color settings.  */

grub_uint8_t standard_color_setting;
@@ -204,7 +205,7 @@ grub_virtual_screen_free (void)
  static grub_err_t
  grub_virtual_screen_setup (unsigned int x, unsigned int y,
 unsigned int width, unsigned int height,
-  grub_font_t font)
+  grub_font_t font, unsigned int scale)
  {
unsigned int i;
  
@@ -213,6 +214,7 @@ grub_virtual_screen_setup (unsigned int x, unsigned int y,
  
/* Initialize with default data.  */

virtual_screen.font = font;
+  virtual_screen.scale = scale;
virtual_screen.width = width;
virtual_screen.height = height;
virtual_screen.offset_x = x;
@@ -220,9 +222,9 @@ grub_virtual_screen_setup (unsigned int x, unsigned int y,
virtual_screen.normal_char_width =
  calculate_normal_character_width (virtual_screen.font);
virtual_screen.normal_char_height =
-grub_font_get_max_char_height (virtual_screen.font);
+grub_font_get_max_char_height (virtual_screen.font) * virtual_screen.scale;
if (virtual_screen.normal_char_height == 0)
-virtual_screen.normal_char_height = 16;
+virtual_screen.normal_char_height = 16 * virtual_screen.scale;
virtual_screen.cursor_x = 0;
virtual_screen.cursor_y = 0;
virtual_screen.cursor_state = 1;
@@ -297,7 +299,8 @@ grub_err_t
  grub_gfxterm_set_window (struct grub_video_render_target *target,
 int x, int y, int width, int height,
 int double_repaint,
-grub_font_t font, int border_width)
+grub_font_t font, int scale,
+int border_width)
  {
/* Clean up any prior instance.  */
destroy_window ();
@@ -306,10 +309,10 @@ grub_gfxterm_set_window (struct grub_video_render_target 
*target,

Re: [PATCH 2/2] docs: Add documentation for the efitextmode command

[Paul Menzel]

Dear Glenn,


Am 13.05.22 um 00:46 schrieb Glenn Washburn:

On Thu, 12 May 2022 08:08:32 +0200 Paul Menzel wrote:


[…]


Am 12.05.22 um 05:07 schrieb Glenn Washburn:

Signed-off-by: Glenn Washburn 


*Add documentation for …* could be abbreviated to *Document …* in the
git commit message summary.


---
   docs/grub.texi | 23 +++
   1 file changed, 23 insertions(+)

diff --git a/docs/grub.texi b/docs/grub.texi
index 3b5522b0a..50ef28edd 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4202,6 +4202,7 @@ you forget a command, you can run the command 
@command{help}
  * distrust::Remove a pubkey from trusted keys
  * drivemap::Map a drive to another
  * echo::Display a line of text
+* efitextmode:: Set/Get text output mode resolution
  * eval::Evaluate agruments as GRUB commands
  * export::  Export an environment variable
  * false::   Do nothing, unsuccessfully
@@ -4638,6 +4639,28 @@ character will print that character.
   @end deffn
   
   
+@node efitextmode

+@subsection efitextmode
+
+@deffn Command efitextmode [min | max | mode_num]
+When used with no arguments displays all available text output modes. The
+set mode determines the columns and rows of the text display when in
+text mode. An asterisk, @samp{*}, will be at the end of the line of the
+currently set mode.
+
+Otherwise the command only takes a single parameter, which can be
+@samp{min}, @samp{max}, or a mode number given by the listing when run
+with no arguments. These arguments set the mode to the minimum, maximum,
+and particular mode respectively.
+
+By default GRUB will start in whatever mode the EFI firmware defaults to.
+There are firmwares known to setup the default mode such that output


The verb *set up* is spelled with a space.


+behaves strangely. Setting the mode can fix this.


Should your device be mentioned in the documentation, and one of the
strangeness be described?


I deliberately was vague here because I don't think the specifics
matter. The point I wanted to get across is that if your text mode
EFI console is behaving strangely (define it how ever you want), that a
mode switch may fix things. This is not to presume that other
strangeness can't be fixed by doing a mode switch. Perhaps I could add
after "strangely", ", for example your cursor in the grub shell never
reaches the bottom of the screen or when typing input characters from
previous command output are overwritten". I don't think my device need
be mentioned.


Yes, I like your suggestion.

[…]


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/2] efi: Add efitextmode command for getting/setting the text mode resolution

[Paul Menzel]

Dear Glenn,


Am 12.05.22 um 20:29 schrieb Glenn Washburn:


On Thu, 12 May 2022 08:10:56 +0200 Paul Menzel wrote:



Am 12.05.22 um 05:07 schrieb Glenn Washburn:

This command is meant to behave similarly to the 'mode' command of the EFI
Shell application. One difference is that to set the mode the mode number
is given, not the rows and columns of the desired mode. Also supported are
the arguments "min" and "max", which set the mode to the minimum and
maximum mode respectively as calculated by the columns * rows of that mode.


Did you test this also with QEMU and OVMF?


Yes, although with QEMU with -nographic and the output going through
serial, though not using GRUB's serial terminal. So its still using the
efi console. Is there a reason you're asking? Something not working as
expected?


No, I haven’t tested the patch. I just wanted to know, how the patch was 
tested besides the HP device.


[…]


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/2] efi: Add efitextmode command for getting/setting the text mode resolution

[Paul Menzel]

Dear Glenn,


Thank you for the patch.

Am 12.05.22 um 05:07 schrieb Glenn Washburn:

This command is meant to behave similarly to the 'mode' command of the EFI
Shell application. One difference is that to set the mode the mode number
is given, not the rows and columns of the desired mode. Also supported are
the arguments "min" and "max", which set the mode to the minimum and
maximum mode respectively as calculated by the columns * rows of that mode.


Did you test this also with QEMU and OVMF?


Kind regards,

Paul



Signed-off-by: Glenn Washburn 
---
  grub-core/Makefile.core.def  |   6 ++
  grub-core/commands/efi/efitextmode.c | 118 +++
  2 files changed, 124 insertions(+)
  create mode 100644 grub-core/commands/efi/efitextmode.c

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 726f51be7..b22e48f0f 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -813,6 +813,12 @@ module = {
enable = efi;
  };
  
+module = {

+  name = efitextmode;
+  efi = commands/efi/efitextmode.c;
+  enable = efi;
+};
+
  module = {
name = blocklist;
common = commands/blocklist.c;
diff --git a/grub-core/commands/efi/efitextmode.c 
b/grub-core/commands/efi/efitextmode.c
new file mode 100644
index 0..fb72aa6f3
--- /dev/null
+++ b/grub-core/commands/efi/efitextmode.c
@@ -0,0 +1,118 @@
+/* efitextmode.c - command to get/set text mode resolution */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2003,2005,2006,2007,2009  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+GRUB_MOD_LICENSE ("GPLv3+");
+
+static grub_err_t
+grub_cmd_efitextmode (grub_command_t cmd __attribute__ ((unused)),
+ int argc, char **args)
+{
+  grub_efi_simple_text_output_interface_t *o;
+  unsigned long mode;
+  const char *p = NULL;
+  grub_efi_status_t status;
+  grub_efi_uintn_t columns, rows;
+  grub_efi_int32_t i;
+
+  if (argc > 1)
+return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("at most one argument 
expected"));
+
+  o = grub_efi_system_table->con_out;
+
+  if (argc == 1)
+{
+  if (grub_strcmp (args[0], "min") == 0)
+   mode = 0;
+  else if (grub_strcmp (args[0], "max") == 0)
+   mode = o->mode->max_mode - 1;
+  else
+   {
+ mode = grub_strtoul (args[0], &p, 0);
+
+ if (grub_errno != GRUB_ERR_NONE)
+   return grub_errno;
+
+ if (*args[0] == '\0' || *p != '\0')
+   return grub_error (GRUB_ERR_BAD_ARGUMENT,
+  N_("non-numeric or invalid mode `%s'"),
+  args[0]);
+   }
+
+  if (mode < (unsigned long) o->mode->max_mode)
+   {
+ if (mode != (unsigned long) o->mode->mode)
+   {
+ status = efi_call_2 (o->set_mode, o, (grub_efi_int32_t) mode);
+ if (status == GRUB_EFI_SUCCESS)
+   ;
+ else if (status == GRUB_EFI_DEVICE_ERROR)
+   return grub_error (GRUB_ERR_BAD_DEVICE,
+  N_("device error: could not set requested"
+ " mode"));
+ else if (status == GRUB_EFI_UNSUPPORTED)
+   return grub_error (GRUB_ERR_OUT_OF_RANGE,
+  N_("invalid mode: number not valid"));
+ else
+   return grub_error (GRUB_ERR_BAD_OS,
+  N_("unexpected EFI error number: `%u'"),
+  (unsigned) status);
+   }
+   }
+  else
+   return grub_error (GRUB_ERR_BAD_ARGUMENT,
+  N_("invalid mode: `%lu' is greater than maximum"
+ " mode `%lu'"),
+  mode, (unsigned long) o->mode->max_mode);
+}
+
+  if (argc == 0)
+{
+  grub_printf_ (N_("Available modes for console output device.\n"));
+
+  for (i=0; i < o->mode->max_mode; i++)
+   if (GRUB_EFI_SUCCESS == efi_call_4 (o->query_mode, o, i,
+   &columns, &rows))
+ grub_printf_ (N_(" [%lu]  Col %5u Row %5u %c\n"),
+   (unsigned long) i, (unsigned) columns, (unsigned) rows,
+   (i == o->mode->mode) ? '*

Re: [PATCH 2/2] docs: Add documentation for the efitextmode command

[Paul Menzel]

Dear Glenn,


Thank you for the patch. Two small nits.

Am 12.05.22 um 05:07 schrieb Glenn Washburn:

Signed-off-by: Glenn Washburn 


*Add documentation for …* could be abbreviated to *Document …* in the 
git commit message summary.



---
  docs/grub.texi | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/docs/grub.texi b/docs/grub.texi
index 3b5522b0a..50ef28edd 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4202,6 +4202,7 @@ you forget a command, you can run the command 
@command{help}
 * distrust::Remove a pubkey from trusted keys
 * drivemap::Map a drive to another
 * echo::Display a line of text
+* efitextmode:: Set/Get text output mode resolution
 * eval::Evaluate agruments as GRUB commands
 * export::  Export an environment variable
 * false::   Do nothing, unsuccessfully
@@ -4638,6 +4639,28 @@ character will print that character.
  @end deffn
  
  
+@node efitextmode

+@subsection efitextmode
+
+@deffn Command efitextmode [min | max | mode_num]
+When used with no arguments displays all available text output modes. The
+set mode determines the columns and rows of the text display when in
+text mode. An asterisk, @samp{*}, will be at the end of the line of the
+currently set mode.
+
+Otherwise the command only takes a single parameter, which can be
+@samp{min}, @samp{max}, or a mode number given by the listing when run
+with no arguments. These arguments set the mode to the minimum, maximum,
+and particular mode respectively.
+
+By default GRUB will start in whatever mode the EFI firmware defaults to.
+There are firmwares known to setup the default mode such that output


The verb *set up* is spelled with a space.


+behaves strangely. Setting the mode can fix this.


Should your device be mentioned in the documentation, and one of the 
strangeness be described?



+
+Note: This command is only available on EFI platforms.
+@end deffn
+
+
  @node eval
  @subsection eval



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] grub-mkconfig linux: Fix quadratic algorithm for sorting menu items

[Paul Menzel]

Dear Mathieu,


Am 03.05.22 um 16:42 schrieb Mathieu Desnoyers:

- On May 3, 2022, at 4:47 AM, Paul Menzel pmen...@molgen.mpg.de wrote:



Am 02.05.22 um 16:14 schrieb Mathieu Desnoyers:

The current implementation of the 10_linux script implements its menu
items sorting in bash with a quadratic algorithm, calling "sed", "sort",
head, and grep to compare versions between individual lines, which is
annoyingly slow for kernel developers who can easily end up with 50-100
kernels in /boot.

As an example, on a Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, running:

/usr/sbin/grub-mkconfig > /dev/null

With 44 kernels in /boot, this command takes 10-15 seconds to complete.
After this fix, the same command runs in 5 seconds.

With 116 kernels in /boot, this command takes 40 seconds to complete.
After this fix, the same command runs in 8 seconds.

For reference, the quadratic algorithm here is:

while [ "x$list" != "x" ] ; do  <--- outer loop
linux=`version_find_latest $list`
  version_find_latest()
for i in "$@" ; do<--- inner loop
  version_test_gt()
fork+exec sed
  version_test_numeric()
version_sort
  fork+exec sort
fork+exec head -n 1
fork+exec grep
list=`echo $list | tr ' ' '\n' | fgrep -vx "$linux" | tr '\n' ' '`
  tr
  fgrep
  tr

So all commands executed under version_test_gt() are executed
O(n^2) times where n is the number of kernel images in /boot.

I notice that the same quadratic sorting is done for other supported
OSes, so I suspect similar gains can be obtained there, but I limit the
scope of this patch to Linux because this is the platform on which I can
test.


Wow, thank you very much. Can you add a paragraph describing the new
algorithm, and what runtime it has O(n)?


How does the following paragraph sound ?


Here is the improved algorithm proposed:

- Prepare a list with all the relevant information for ordering by a single
   sort(1) execution. This is done by renaming ".old" suffixes by " 1" and
   by suffixing all other files with " 2", thus making sure the ".old" entries
   will follow the non-old entries in reverse-sorted-order.
- Call version_reverse_sort on the list (sort -r -V): A single execution of
   sort(1) will reverse-sort the list in O(n*log(n)) with a merge sort.
- Replace the " 1" suffixes by ".old", and remove the " 2" suffixes.
- Iterate on the reverse-sorted list to output each menu entry item.

Therefore, the algorithm proposed has O(n*log(n)) complexity compared to
the prior O(n^2) complexity. Moreover, the constant time required for each
list entry is much less because sorting is done within a single execution
of sort(1) rather than requiring O(n^2) executions of sed(1), sort(1),
head(1), and grep(1) in sub-shells.
^


Sounds perfect. Thank you.


Please let me know if you want me to re-send an updated patch or if you want
to add the text to the current patch's commit message as it is committed.


As the maintainers are pretty busy, I guess it’s better you send a v2.

[…]


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] grub-mkconfig linux: Fix quadratic algorithm for sorting menu items

[Paul Menzel]

Dear Mathieu,


Am 02.05.22 um 16:14 schrieb Mathieu Desnoyers:

The current implementation of the 10_linux script implements its menu
items sorting in bash with a quadratic algorithm, calling "sed", "sort",
head, and grep to compare versions between individual lines, which is
annoyingly slow for kernel developers who can easily end up with 50-100
kernels in /boot.

As an example, on a Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, running:

   /usr/sbin/grub-mkconfig > /dev/null

With 44 kernels in /boot, this command takes 10-15 seconds to complete.
After this fix, the same command runs in 5 seconds.

With 116 kernels in /boot, this command takes 40 seconds to complete.
After this fix, the same command runs in 8 seconds.

For reference, the quadratic algorithm here is:

while [ "x$list" != "x" ] ; do  <--- outer loop
   linux=`version_find_latest $list`
 version_find_latest()
   for i in "$@" ; do<--- inner loop
 version_test_gt()
   fork+exec sed
 version_test_numeric()
   version_sort
 fork+exec sort
   fork+exec head -n 1
   fork+exec grep
   list=`echo $list | tr ' ' '\n' | fgrep -vx "$linux" | tr '\n' ' '`
 tr
 fgrep
 tr

So all commands executed under version_test_gt() are executed
O(n^2) times where n is the number of kernel images in /boot.

I notice that the same quadratic sorting is done for other supported
OSes, so I suspect similar gains can be obtained there, but I limit the
scope of this patch to Linux because this is the platform on which I can
test.


Wow, thank you very much. Can you add a paragraph describing the new 
algorithm, and what runtime it has O(n)?



Kind regards,

Paul



Signed-off-by: Mathieu Desnoyers 
---
  util/grub-mkconfig_lib.in | 18 ++
  util/grub.d/10_linux.in   | 12 
  2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/util/grub-mkconfig_lib.in b/util/grub-mkconfig_lib.in
index 301d1ac22..f1a09f4c9 100644
--- a/util/grub-mkconfig_lib.in
+++ b/util/grub-mkconfig_lib.in
@@ -218,6 +218,24 @@ version_sort ()
 esac
  }
  
+version_reverse_sort ()

+{
+  case $version_reverse_sort_sort_has_v in
+yes)
+  LC_ALL=C sort -r -V;;
+no)
+  LC_ALL=C sort -r -n;;
+*)
+  if sort -r -V  /dev/null 2>&1; then
+version_reverse_sort_sort_has_v=yes
+LC_ALL=C sort -r -V
+  else
+version_reverse_sort_sort_has_v=no
+LC_ALL=C sort -r -n
+  fi;;
+   esac
+}
+
  version_test_numeric ()
  {
version_test_numeric_a="$1"
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index ca068038e..23d4bb741 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -195,9 +195,15 @@ title_correction_code=
  # yet, so it's empty. In a submenu it will be equal to '\t' (one tab).
  submenu_indentation=""
  
+# Perform a reverse version sort on the entire list.

+# Temporarily replace the '.old' suffix by ' 1' and append ' 2' for all
+# other files to order the '.old' files after their non-old counterpart
+# in reverse-sorted order.
+
+reverse_sorted_list=$(echo $list | tr ' ' '\n' | sed -e 's/$/ 2/' | sed -e 
's/.old 2/ 1/' | version_reverse_sort | sed 's/ 1$/.old/' | sed 's/ 2$//')
+
  is_top_level=true
-while [ "x$list" != "x" ] ; do
-  linux=`version_find_latest $list`
+for linux in $reverse_sorted_list; do
gettext_printf "Found linux image: %s\n" "$linux" >&2
basename=`basename $linux`
dirname=`dirname $linux`
@@ -293,8 +299,6 @@ while [ "x$list" != "x" ] ; do
  linux_entry "${OS}" "${version}" recovery \
  "${GRUB_CMDLINE_LINUX_RECOVERY} ${GRUB_CMDLINE_LINUX}"
fi
-
-  list=`echo $list | tr ' ' '\n' | fgrep -vx "$linux" | tr '\n' ' '`
  done
  
  # If at least one kernel was found, then we need to


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH RFC 1/3] efi: provide definitions of DXE services table

[Paul Menzel]

Dear Baskov,


Thank you for your patches.


Am 07.04.22 um 05:32 schrieb Baskov Evgeniy:

DXE services can be used to change memory attributes
on systems where EFI use stricter policies about memory
access rights and sets NX flag on some pages required by
grub to executable.


If you resend, please use (at least) 72 characters per line.

For the UEFI ignorant, could you please reference the UEFI specification 
name, revision, and section needed for review?


[…]


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

clang build fails with `../grub-core/lib/gnulib/regex.h:682:20: error: variable length array used [-Werror,-Wvla]`

[Paul Menzel]

Dear GRUB folks,


On Debian sid/unstable clang 13.0.1 fails to build GRUB due to a problem 
in Gnulib:


```
$ git log --oneline -1 --no-decorate
7c316e183 term/efi/console: Do not set cursor until the first text output
$ ./configure --with-platform=coreboot CC=clang && make
[…]
clang -DHAVE_CONFIG_H -I. -I..  -Wall -W  -DGRUB_MACHINE_COREBOOT=1 
-DGRUB_MACHINE=I386_COREBOOT -m32 -msoft-float -Xclang -msoft-float 
-Xclang -no-implicit-float -nostdinc -isystem 
/usr/lib/llvm-13/lib/clang/13.0.1/include -I../include -I../include 
-DGRUB_FILE=\"commands/regexp.c\" -I. -I. -I.. -I.. -I../include 
-I../include -I../grub-core/lib/libgcrypt-grub/src/ 
-I../grub-core/lib/posix_wrap -I../grub-core/lib/gnulib 
-I../grub-core/lib/gnulib  -D_FILE_OFFSET_BITS=64 -std=gnu99 -fno-common 
-Os -m32 -Wall -W -Wshadow -Wpointer-arith -Wundef -Wchar-subscripts 
-Wcomment -Wdeprecated-declarations -Wdisabled-optimization 
-Wdiv-by-zero -Wfloat-equal -Wformat-extra-args -Wformat-security 
-Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int 
-Wmain -Wmissing-braces -Wmissing-format-attribute -Wmultichar 
-Wparentheses -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare 
-Wswitch -Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function 
-Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable 
-Wwrite-strings -Wnested-externs -Wstrict-prototypes -g 
-Wredundant-decls -Wmissing-prototypes -Wmissing-declarations  -Wextra 
-Wattributes -Wendif-labels -Winit-self -Wint-to-pointer-cast 
-Winvalid-pch -Wmissing-field-initializers -Wnonnull -Woverflow -Wvla 
-Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros 
-Wvolatile-register-var -Wpointer-sign -Wmissing-include-dirs 
-Wmissing-prototypes -Wmissing-declarations -Wformat=2 -march=i386 
-falign-functions=1 -freg-struct-return -mno-mmx -mno-sse -mno-sse2 
-mno-sse3 -mno-3dnow -fno-dwarf2-cfi-asm -mno-stack-arg-probe 
-fno-asynchronous-unwind-tables -fno-unwind-tables -fno-ident -Qn 
-Qunused-arguments -fno-stack-protector -Werror   -ffreestanding 
-fno-builtin -Wno-undef -Wno-sign-compare -Wno-unused 
-Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code 
-Wno-conversion   -MT commands/regexp_module-regexp.o -MD -MP -MF 
commands/.deps-core/regexp_module-regexp.Tpo -c -o 
commands/regexp_module-regexp.o `test -f 'commands/regexp.c' || echo 
'./'`commands/regexp.c

In file included from commands/regexp.c:28:
../grub-core/lib/gnulib/regex.h:682:20: error: variable length array 
used [-Werror,-Wvla]

_REGEX_NELTS (__nmatch)],
  ^~~~
../grub-core/lib/gnulib/regex.h:528:27: note: expanded from macro 
'_REGEX_NELTS'

#  define _REGEX_NELTS(n) n
  ^
1 error generated.
make[3]: *** [Makefile:41321: commands/regexp_module-regexp.o] Fehler 1
```

I tried to use latest Gnulib (not the one defined in `bootstrap.conf`), 
but the error remains.


How to deal with that, if I am unsure how to fix it? Report it to the 
Gnulib folks?



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] configure: Fix default -O2 being added when CFLAGS not set

[Paul Menzel]

Dear Glenn,


Thank you for your tireless awesome work on GRUB.

Am 24.03.22 um 23:31 schrieb Glenn Washburn:

Autoconf will set a default CFLAGS of "-g -O2" if CFLAGS is not set. CFLAGS
was defaulted to "" early in configure to prevent this. Apparently something
changed in autoconf and now AC_USE_SYSTEM_EXTENSIONS, which is before the
default setting of CFLAGS, will pull in this check. Move the default
setting of CFLAGS to before this so that if will see CFLAGS as set and not
give it a default.


Could you please mention the Autoconf version you use? I guess, it’d be 
great to know, when this behavior started, so to make sure, that the 
last X years all the tests were done like this, and reverting the 
behavior would actually break things (though shouldn’t).


With Debian sid/unstable and GNU Autoconf 2.71 I can reproduce your 
behavior:


$ grep '^CFLAGS=' config.log
CFLAGS='-g -O2'


Signed-off-by: Glenn Washburn 
---
  configure.ac | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 3ffbc7c57b..c1e50c9d75 100644
--- a/configure.ac
+++ b/configure.ac
@@ -36,12 +36,12 @@ dnl description of the relationships between them.
  
  AC_INIT([GRUB],[2.11],[bug-g...@gnu.org])
  
-AC_USE_SYSTEM_EXTENSIONS

-AC_CONFIG_AUX_DIR([build-aux])
-
  # We don't want -g -O2 by default in CFLAGS
  : ${CFLAGS=""}
  
+AC_USE_SYSTEM_EXTENSIONS

+AC_CONFIG_AUX_DIR([build-aux])
+
  # Checks for build, host and target systems.
  AC_CANONICAL_BUILD
  AC_CANONICAL_HOST


Tested-by: Paul Menzel 

$ git am … && ./autogen.sh && ./configure --with-platform=coreboot
$ grep '^CFLAGS=' config.log
CFLAGS=''


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 2/6] loader/i386/bsd: Initialize ptr variable in grub_bsd_add_meta()

[Paul Menzel]

Dear Daniel,


Am 11.03.22 um 00:35 schrieb Daniel Kiper:

Latest GCC may complain in that way:


Just for the record, what is the latest GCC for you? 12?


   In file included from ../include/grub/disk.h:31,
from ../include/grub/file.h:26,
from ../include/grub/loader.h:23,
from loader/i386/bsd.c:19:
   loader/i386/bsd.c: In function ‘grub_cmd_openbsd’:
   ../include/grub/misc.h:71:10: error: ‘ptr’ may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
  71 |   return grub_memmove (dest, src, n);
 |  ^~~
   loader/i386/bsd.c:266:9: note: ‘ptr’ was declared here
 266 |   void *ptr;
 | ^~~

So, let's fix it by assigning NULL to ptr in grub_bsd_add_meta().

Signed-off-by: Daniel Kiper 
---
  grub-core/loader/i386/bsd.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/grub-core/loader/i386/bsd.c b/grub-core/loader/i386/bsd.c
index 5f3290ce1..346c4f14a 100644
--- a/grub-core/loader/i386/bsd.c
+++ b/grub-core/loader/i386/bsd.c
@@ -263,7 +263,7 @@ grub_err_t
  grub_bsd_add_meta (grub_uint32_t type, const void *data, grub_uint32_t len)
  {
grub_err_t err;
-  void *ptr;
+  void *ptr = NULL;
  
err = grub_bsd_add_meta_ptr (type, &ptr, len);

if (err)


It’s a bogus warning though, as `grub_bsd_add_meta_ptr()` return an 
error when ptr wasn’t initialized yet, right?



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 3/3] reed_solomon: Fix array subscript 0 is outside array bounds

[Paul Menzel]

Dear Michael,


Thank you for working on that.


Am 17.03.22 um 07:43 schrieb Michael Chang via Grub-devel:

The grub_absolute_pointer() is a compound expression that can only work
within a function. We are out of luck here when the pointer variables
require global definition due to ATTRIBUTE_TEXT that have to use fully
initialized global definition because of the way linkers work.

  static gf_single_t * const gf_powx ATTRIBUTE_TEXT = (void *) 0x10;

For the reason given above, use gcc diagnostic pragmas to suppress the
array-bounds warning.


Can you please share the exact GCC warning messages?


Kind regards,

Paul



Signed-off-by: Michael Chang 
---
  grub-core/lib/reed_solomon.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/grub-core/lib/reed_solomon.c b/grub-core/lib/reed_solomon.c
index 82779a296b..562bd2e3e3 100644
--- a/grub-core/lib/reed_solomon.c
+++ b/grub-core/lib/reed_solomon.c
@@ -102,6 +102,11 @@ static gf_single_t errvals[256];
  static gf_single_t eqstat[65536 + 256];
  #endif
  
+#if __GNUC__ == 12

+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
+#endif
+
  static gf_single_t
  gf_mul (gf_single_t a, gf_single_t b)
  {
@@ -319,6 +324,10 @@ decode_block (gf_single_t *ptr, grub_size_t s,
  }
  }
  
+#if __GNUC__ == 12

+#pragma GCC diagnostic pop
+#endif
+
  #if !defined (STANDALONE)
  static void
  encode_block (gf_single_t *ptr, grub_size_t s,


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 6/6] INSTALL: Add more cross-compiling Debian packages

[Paul Menzel]

Dear Daniel,


Am 11.03.22 um 00:36 schrieb Daniel Kiper:

The mingw-w64-tools is especially important because with out it some


without


Windows builds may fail due to lack of proper pkg-config.

Signed-off-by: Daniel Kiper 
---
  INSTALL | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/INSTALL b/INSTALL
index a64f63723..aff44f75c 100644
--- a/INSTALL
+++ b/INSTALL
@@ -52,7 +52,8 @@ need the following.
  
  Your distro may package cross-compiling toolchains such as the following

  incomplete list on Debian: gcc-aarch64-linux-gnu, gcc-arm-linux-gnueabihf,
-gcc-mipsel-linux-gnu, and mingw-w64.
+gcc-mips-linux-gnu, gcc-mipsel-linux-gnu, gcc-powerpc64-linux-gnu,
+gcc-riscv64-linux-gnu, gcc-sparc64-linux-gnu, mingw-w64 and mingw-w64-tools.
  
  More cross compiling toolchains can be found at the following trusted sites:
  


Acked-by: Paul Menzel 


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2] i386: Make pmtimer tsc calibration not take 51 seconds to fail

[Paul Menzel]

Dear Javier, Peter,


Am 29.05.20 um 12:08 schrieb Javier Martinez Canillas:

From: Peter Jones 

On my laptop running at 2.4GHz, if I run a VM where tsc calibration
using pmtimer will fail presuming a broken pmtimer, it takes ~51 seconds
to do so (as measured with the stopwatch on my phone), with a tsc delta
of 0x1cd1c85300, or around 125 billion cycles.

If instead of trying to wait for 5-200ms to show up on the pmtimer, we try
to wait for 5-200us, it decides it's broken in ~0x2626aa0 TSCs, aka ~2.4
million cycles, or more or less instantly.

Additionally, this reading the pmtimer was returning 0x anyway,
and that's obviously an invalid return.  I've added a check for that and
0 so we don't bother waiting for the test if what we're seeing is dead
pins with no response at all.

If "debug" is includes "pmtimer", you will see one of the following


s/is includes/includes/ ?


three outcomes.  If pmtimer gives all 0 or all 1 bits, you will see:

pmtimer: 0xff bad_reads: 1
pmtimer: 0xff bad_reads: 2
pmtimer: 0xff bad_reads: 3
pmtimer: 0xff bad_reads: 4
pmtimer: 0xff bad_reads: 5
pmtimer: 0xff bad_reads: 6
pmtimer: 0xff bad_reads: 7
pmtimer: 0xff bad_reads: 8
pmtimer: 0xff bad_reads: 9
pmtimer: 0xff bad_reads: 10
timer is broken; giving up.

This outcome was tested using qemu+kvm with UEFI (OVMF) firmware and
these options: -machine pc-q35-2.10 -cpu Broadwell-noTSX

If pmtimer gives any other bit patterns but is not actually marching
forward fast enough to use for clock calibration, you will see:

pmtimer delta is 0x0 (1904 iterations)
tsc delta is implausible: 0x2626aa0

This outcome was tested using grub compiled with GRUB_PMTIMER_IGNORE_BAD_READS
defined (so as not to trip the bad read test) using qemu+kvm with UEFI
(OVMF) firmware, and these options: -machine pc-q35-2.10 -cpu Broadwell-noTSX

If pmtimer actually works, you'll see something like:

pmtimer delta is 0xdff
tsc delta is 0x278756

This outcome was tested using qemu+kvm with UEFI (OVMF) firmware, and
these options: -machine pc-i440fx-2.4 -cpu Broadwell-noTSX

I've also tested this outcome on a real Intel Xeon E3-1275v3 on an Intel
Server Board S1200V3RPS using the SDV.RP.B8 "Release" build here:
https://firmware.intel.com/sites/default/files/UEFIDevKit_S1200RP_vB8.zip

Signed-off-by: Peter Jones 
Signed-off-by: Javier Martinez Canillas 
---

Hello Daniel,

I think that addressed all the issues you pointed out to Peter in
https://lists.gnu.org/archive/html/grub-devel/2018-02/msg00078.html

Please let me know if I missed anything.

Best regards,
Javier

Changes in v2:
- Address issues pointed out by Daniel Kiper on previously posted version.

  grub-core/kern/i386/tsc_pmtimer.c | 112 --
  1 file changed, 92 insertions(+), 20 deletions(-)

diff --git a/grub-core/kern/i386/tsc_pmtimer.c 
b/grub-core/kern/i386/tsc_pmtimer.c
index c9c36169978..d9b3765b018 100644
--- a/grub-core/kern/i386/tsc_pmtimer.c
+++ b/grub-core/kern/i386/tsc_pmtimer.c
@@ -28,40 +28,104 @@
  #include 
  #include 
  
+/*

+ * Define GRUB_PMTIMER_IGNORE_BAD_READS if you're trying to test a timer that's
+ * present but doesn't keep time well.
+ */
+// #define GRUB_PMTIMER_IGNORE_BAD_READS


So GRUB needs to be rebuild for both cases? Could it be configured at 
runtime with a config option, or is the TSC calibration happening too early?



Kind regards,

Paul



  grub_uint64_t
  grub_pmtimer_wait_count_tsc (grub_port_t pmtimer,
 grub_uint16_t num_pm_ticks)
  {
grub_uint32_t start;
-  grub_uint32_t last;
-  grub_uint32_t cur, end;
+  grub_uint64_t cur, end;
grub_uint64_t start_tsc;
grub_uint64_t end_tsc;
-  int num_iter = 0;
+  unsigned int num_iter = 0;
+#ifndef GRUB_PMTIMER_IGNORE_BAD_READS
+  int bad_reads = 0;
+#endif
  
-  start = grub_inl (pmtimer) & 0xff;

-  last = start;
+  /*
+   * Some timers are 24-bit and some are 32-bit, but it doesn't make much
+   * difference to us.  Caring which one we have isn't really worth it since
+   * the low-order digits will give us enough data to calibrate TSC.  So just
+   * mask the top-order byte off.
+   */
+  cur = start = grub_inl (pmtimer) & 0x00ffUL;
end = start + num_pm_ticks;
start_tsc = grub_get_tsc ();
while (1)
  {
-  cur = grub_inl (pmtimer) & 0xff;
-  if (cur < last)
-   cur |= 0x100;
-  num_iter++;
+  cur &= 0xff00ULL;
+  /*
+   * Only take the low-order 24-bit for the reason explained above.
+   */
+  cur |= grub_inl (pmtimer) & 0x00ffUL;
+
+  end_tsc = grub_get_tsc();
+
+#ifndef GRUB_PMTIMER_IGNORE_BAD_READS
+  /*
+   * If we get 10 reads in a row that are obviously dead pins, there's no
+   * reason to do this thousands of times.
+   */
+  if (cur == 0xffUL || cur == 0)
+   {
+ bad_reads++;
+ grub_dprintf ("pmtimer",
+   "pmtimer: 0x%"PRIxGRUB_UINT64_T" bad_r

Re: [PATCH 08/10] grub-shell: Boot PowerPC using PMU instead of CUDA for power management

[Paul Menzel]

Dear Glenn,


Thank you. I noticed two small typos.

Am 18.09.21 um 01:04 schrieb Glenn Washburn:

At some point it looks like the defualt machine for qemu-system-ppc started


default


using CUDA as a backend for power management. This causes the machine to
throw an exception and not actually power down the VM[1]. Switching to PMU
allows power downs and reboots to work as expceted.


expected


[1] https://gitlab.com/qemu-project/qemu/-/issues/624


Thank you for reporting this upstream.


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 93e9f5148..5354d8678 100644
--- a/tests/util/grub-shell.in
+++ b/tests/util/grub-shell.in
@@ -84,6 +84,7 @@ case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" in
serial_null="-serial null"
netbootext=elf
trim=1
+   qemuopts="-M mac99,via=pmu $qemuopts"
;;
  
  sparc64-ieee1275)




Reviewed-by: Paul Menzel 


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] templates: Add GRUB_CMDLINE_LINUX_RECOVERY

[Paul Menzel]

[Cc: +Kyle]

Am 14.09.21 um 21:25 schrieb ch...@z9.de:

From: Chris Vogel 

When generating grub.cfg using grub-mkconfig and the scripts 10_linux and
20_linux_xen there is no way to add kernel command line parameters _only_ to
the recovery entries generated.

This is needed to e.g. start a debug shell in installations using systemd
using the kernel command line parameter "systemd.debug-shell" or to recover
in a system with encrypted root in situations where the decryption of the
root filesystem per crypttab in the intiramfs image is broken and the recovery
entry should contain informations about how to decrypt the rootfs (cryptopts=).

This patch does not change the default behaviour of grub if
GRUB_CMDLINE_LINUX_RECOVERY is not set.

If GRUB_CMDLINE_LINUX_RECOVERY is set and the generated recovery entry should
include the kernel parameter 'single' the parameter must be explicitly included
in GRUB_CMDLINE_LINUX_RECOVERY.

As far as I know all credits for the idea and the initial implementation go to
Kyle Ranking of Purism.

Signed-off-by: Chris Vogel 
---
  docs/grub.texi  | 8 
  util/grub-mkconfig.in   | 1 +
  util/grub.d/10_linux.in | 6 +-
  util/grub.d/20_linux_xen.in | 6 +-
  4 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index f8b4b3b21..8b5482ee1 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -1411,6 +1411,14 @@ entry for recovery mode.  This option lists command-line 
arguments to add
  only to the default menu entry, after those listed in
  @samp{GRUB_CMDLINE_LINUX}.
  
+@item GRUB_CMDLINE_LINUX_RECOVERY

+Unless @samp{GRUB_DISABLE_RECOVERY} is set to @samp{true}, two menu
+entries will be generated for each Linux kernel: one default entry and one
+entry for recovery mode.
+This option lists command-line arguments to add only to the recovery menu
+entry, before those listed in @samp{GRUB_CMDLINE_LINUX}.
+The default is @samp{single}.
+
  @item GRUB_CMDLINE_NETBSD
  @itemx GRUB_CMDLINE_NETBSD_DEFAULT
  As @samp{GRUB_CMDLINE_LINUX} and @samp{GRUB_CMDLINE_LINUX_DEFAULT}, but for
diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index f8cbb8d7a..c3ea7612e 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -225,6 +225,7 @@ export GRUB_DEFAULT \
GRUB_DISTRIBUTOR \
GRUB_CMDLINE_LINUX \
GRUB_CMDLINE_LINUX_DEFAULT \
+  GRUB_CMDLINE_LINUX_RECOVERY \
GRUB_CMDLINE_XEN \
GRUB_CMDLINE_XEN_DEFAULT \
GRUB_CMDLINE_LINUX_XEN_REPLACE \
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index e8b01c0d0..af51ae2f7 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -43,6 +43,10 @@ case ${GRUB_DEVICE} in
;;
  esac
  
+if [ "x${GRUB_CMDLINE_LINUX_RECOVERY}" = "x" ] ; then

+  GRUB_CMDLINE_LINUX_RECOVERY='single'
+fi
+
  # Default to disabling partition uuid support to maintian compatibility with
  # older kernels.
  GRUB_DISABLE_LINUX_PARTUUID=${GRUB_DISABLE_LINUX_PARTUUID-true}
@@ -287,7 +291,7 @@ while [ "x$list" != "x" ] ; do
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
if [ "x${GRUB_DISABLE_RECOVERY}" != "xtrue" ]; then
  linux_entry "${OS}" "${version}" recovery \
-"single ${GRUB_CMDLINE_LINUX}"
+"${GRUB_CMDLINE_LINUX_RECOVERY} ${GRUB_CMDLINE_LINUX}"
fi
  
list=`echo $list | tr ' ' '\n' | fgrep -vx "$linux" | tr '\n' ' '`

diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index 3b1f47049..992363c3e 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -43,6 +43,10 @@ case ${GRUB_DEVICE} in
;;
  esac
  
+if [ "x${GRUB_CMDLINE_LINUX_RECOVERY}" = "x" ] ; then

+  GRUB_CMDLINE_LINUX_RECOVERY='single'
+fi
+
  # Default to disabling partition uuid support to maintian compatibility with
  # older kernels.
  GRUB_DISABLE_LINUX_PARTUUID=${GRUB_DISABLE_LINUX_PARTUUID-true}
@@ -343,7 +347,7 @@ while [ "x${xen_list}" != "x" ] ; do
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" 
"${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}"
if [ "x${GRUB_DISABLE_RECOVERY}" != "xtrue" ]; then
linux_entry "${OS}" "${version}" "${xen_version}" recovery \
-   "single ${GRUB_CMDLINE_LINUX}" "${GRUB_CMDLINE_XEN}"
+   "${GRUB_CMDLINE_LINUX_RECOVERY} ${GRUB_CMDLINE_LINUX}" 
"${GRUB_CMDLINE_XEN}"
fi
  
  	list=`echo $list | tr ' ' '\n' | fgrep -vx "$linux" | tr '\n' ' '`




___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: feature request + patch: GRUB_CMDLINE_LINUX_RECOVERY

[Paul Menzel]

Dear Chris,


Am 11.09.21 um 19:23 schrieb Chris Vogel:


I'd like to propose a patch to add a configuration parameter called 
GRUB_CMDLINE_LINUX_RECOVERY.

All credits for the initial idea and first implementation (as far as I know) go 
to Kyle Rankin at Purism. I used his improvement without being aware that it is 
not a standard feature inluded in original grub. His implementation can be 
found here https://source.puri.sm/pureos/packages/smartcard-key-luks.

There are situations when it would be helpfull to be able to set command line 
options to use only when generating a recovery entry for grub.cfg, e.g.

- when using systemd starting a debug shell using "systemd.debug-shell"
- when using luks disk encryption as shown in the work of Kyle

The inclusion of GRUB_CMDLINE_LINUX_RECOVERY as in the patch below shouldn't 
change the behaviour of grub at all if not used in a configuration. Users not 
setting the variable shouldn't see any difference.

Chris


diff --git a/docs/grub.texi b/docs/grub.texi
index f8b4b3b21..8b5482ee1 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -1411,6 +1411,14 @@ entry for recovery mode.  This option lists command-line 
arguments to add
  only to the default menu entry, after those listed in
  @samp{GRUB_CMDLINE_LINUX}.
  
+@item GRUB_CMDLINE_LINUX_RECOVERY

+Unless @samp{GRUB_DISABLE_RECOVERY} is set to @samp{true}, two menu
+entries will be generated for each Linux kernel: one default entry and one
+entry for recovery mode.
+This option lists command-line arguments to add only to the recovery menu
+entry, before those listed in @samp{GRUB_CMDLINE_LINUX}.
+The default is @samp{single}.
+
  @item GRUB_CMDLINE_NETBSD
  @itemx GRUB_CMDLINE_NETBSD_DEFAULT
  As @samp{GRUB_CMDLINE_LINUX} and @samp{GRUB_CMDLINE_LINUX_DEFAULT}, but for
diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index f8cbb8d7a..c3ea7612e 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -225,6 +225,7 @@ export GRUB_DEFAULT \
GRUB_DISTRIBUTOR \
GRUB_CMDLINE_LINUX \
GRUB_CMDLINE_LINUX_DEFAULT \
+  GRUB_CMDLINE_LINUX_RECOVERY \
GRUB_CMDLINE_XEN \
GRUB_CMDLINE_XEN_DEFAULT \
GRUB_CMDLINE_LINUX_XEN_REPLACE \
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index e8b01c0d0..af51ae2f7 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -43,6 +43,10 @@ case ${GRUB_DEVICE} in
;;
  esac
  
+if [ "x${GRUB_CMDLINE_LINUX_RECOVERY}" = "x" ] ; then

+  GRUB_CMDLINE_LINUX_RECOVERY='single'
+fi
+
  # Default to disabling partition uuid support to maintian compatibility with
  # older kernels.
  GRUB_DISABLE_LINUX_PARTUUID=${GRUB_DISABLE_LINUX_PARTUUID-true}
@@ -287,7 +291,7 @@ while [ "x$list" != "x" ] ; do
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
if [ "x${GRUB_DISABLE_RECOVERY}" != "xtrue" ]; then
  linux_entry "${OS}" "${version}" recovery \
-"single ${GRUB_CMDLINE_LINUX}"
+"${GRUB_CMDLINE_LINUX_RECOVERY} ${GRUB_CMDLINE_LINUX}"
fi
  
list=`echo $list | tr ' ' '\n' | fgrep -vx "$linux" | tr '\n' ' '`

diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index 3b1f47049..992363c3e 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -43,6 +43,10 @@ case ${GRUB_DEVICE} in
;;
  esac
  
+if [ "x${GRUB_CMDLINE_LINUX_RECOVERY}" = "x" ] ; then

+  GRUB_CMDLINE_LINUX_RECOVERY='single'
+fi
+
  # Default to disabling partition uuid support to maintian compatibility with
  # older kernels.
  GRUB_DISABLE_LINUX_PARTUUID=${GRUB_DISABLE_LINUX_PARTUUID-true}
@@ -343,7 +347,7 @@ while [ "x${xen_list}" != "x" ] ; do
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}" 
"${GRUB_CMDLINE_XEN} ${GRUB_CMDLINE_XEN_DEFAULT}"
if [ "x${GRUB_DISABLE_RECOVERY}" != "xtrue" ]; then
linux_entry "${OS}" "${version}" "${xen_version}" recovery \
-   "single ${GRUB_CMDLINE_LINUX}" "${GRUB_CMDLINE_XEN}"
+   "${GRUB_CMDLINE_LINUX_RECOVERY} ${GRUB_CMDLINE_LINUX}" 
"${GRUB_CMDLINE_XEN}"
fi
  
  	list=`echo $list | tr ' ' '\n' | fgrep -vx "$linux" | tr '\n' ' '`


Thank you for upstreaming downstream feature. Please send it as git 
formatted patch (and maybe `git send-email`) with a commit message [1] 
and Signed-off-by lines to the list with the maintainers in Cc.



Kind regards,

Paul


[1]: https://chris.beams.io/posts/git-commit/

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Resurrecting the UEFI Watchdog

[Paul Menzel]

Dear Erwan,


Am 30.08.21 um 11:14 schrieb Erwan Velu:

As per Paul Menzel email, I'm adding the 4 maintainers in CC of this
original email.


I am sorry for the misunderstanding. *it* referred to the patch.


I can offer to refresh & resent this patch to the mailing list if this
helps its adoption.


Yes, that is what I meant and would be preferred.


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Resurrecting the UEFI Watchdog

[Paul Menzel]

Dear Erwan,


Am 27.08.21 um 17:23 schrieb Erwan Velu:


I'd like to share again a patch that got posted a long while ago here and
never seen to get attention on it:
https://lists.gnu.org/archive/html/grub-devel/2015-09/msg00065.html

I found this patch useful as it allows my servers to reboot automatically
if grub is unable to boots within a defined time. Yes, some of my servers
don't have the hardware bios watchdog.

I can share here the patch is working fine on the infra I'm working on,
using it for 8 months in production. 50K servers are using it with success.

I get the patch downstream but think it would have its place upstream too.

If anyone wants to get a look at it, I'd be happy to help.


Please repost it to the mailing list with the maintainers in Cc.


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 2/2] configure: Check -falign-jumps=1 -falign-functions=1 beside -falign-loops=1

[Paul Menzel]

Dear Fāng-ruì,


Am 24.08.21 um 08:18 schrieb Fangrui Song via Grub-devel:

Clang does not support -falign-jumps and only recently gained support
for -falign-loops. Test all the alignment options to avoid passing
unrecognized options to Clang:

 clang-14: error: optimization flag '-falign-jumps=1' is not supported 
[-Werror,-Wignored-optimization-argument]

When compiled with older Clang, the alignment options are not added, so
just avoid the complexity for each option.

Signed-off-by: Fangrui Song 
---
  configure.ac | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 9a12151bd..8625e6776 100644
--- a/configure.ac
+++ b/configure.ac
@@ -798,8 +798,9 @@ fi
  
  # Force no alignment to save space on i386.

  if test "x$target_cpu" = xi386; then
-  AC_CACHE_CHECK([whether -falign-loops works], [grub_cv_cc_falign_loop], [
-CFLAGS="$TARGET_CFLAGS -falign-loops=1 -Werror"
+  AC_CACHE_CHECK([whether -falign-jumps=1 -falign-loops=1 -falign-functions=1 
works],
+[grub_cv_cc_falign_loop], [
+CFLAGS="$TARGET_CFLAGS -falign-jumps=1 -falign-loops=1 -falign-functions=1 
-Werror"
  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
  [grub_cv_cc_falign_loop=yes],
[grub_cv_cc_falign_loop=no])



Acked-by: Paul Menzel 


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/2] configure: Remove obsoleted -malign-{jumps, loops, functions}

[Paul Menzel]

Dear Fāng-ruì,


Am 24.08.21 um 08:18 schrieb Fangrui Song via Grub-devel:

GCC warns `cc1: warning: ‘-malign-loops’ is obsolete, use ‘-falign-loops’`.
Clang silently ignores -malign-{jumps,loops,functions}.

The preferred -falign-* forms have been supported since GCC 3.2, so just
remove -malign-{jumps,loops,functions}.


In `INSTALL` under *The Requirements* at least GCC 5.1 is required.


* GCC 5.1.0 or later
  Experimental support for clang 3.8.0 or later (results in much bigger 
binaries)
  for i386, x86_64, arm (including thumb), arm64, mips(el), powerpc, sparc64


So, this works.


Signed-off-by: Fangrui Song 
---
  configure.ac | 9 -
  1 file changed, 9 deletions(-)

diff --git a/configure.ac b/configure.ac
index bee28dbeb..9a12151bd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -805,17 +805,8 @@ if test "x$target_cpu" = xi386; then
[grub_cv_cc_falign_loop=no])
])
  
-  AC_CACHE_CHECK([whether -malign-loops works], [grub_cv_cc_malign_loop], [

-CFLAGS="$TARGET_CFLAGS -malign-loops=1 -Werror"
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
-[grub_cv_cc_malign_loop=yes],
-   [grub_cv_cc_malign_loop=no])
-  ])
-
if test "x$grub_cv_cc_falign_loop" = xyes; then
  TARGET_CFLAGS="$TARGET_CFLAGS -falign-jumps=1 -falign-loops=1 
-falign-functions=1"
-  elif test "x$grub_cv_cc_malign_loop" = xyes; then
-TARGET_CFLAGS="$TARGET_CFLAGS -malign-jumps=1 -malign-loops=1 
-malign-functions=1"
fi
  fi
  


Acked-by: Paul Menzel 


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2] configure: Check -falign-jumps=1 -falign-functions=1 beside -falign-loops=1

[Paul Menzel]

Dear Fāng-ruì,


Am 24.08.21 um 07:53 schrieb Fangrui Song via Grub-devel:

Clang does not support -falign-jumps and only recently gained support
for -falign-loops. Test all the alignment options to avoid passing
unrecognized options to Clang:

 clang-14: error: optimization flag '-falign-jumps=1' is not supported 
[-Werror,-Wignored-optimization-argument]

When compiled with older Clang, the alignment options are not added, so
just avoid the complexity for each option.

While here, remove checks for the obsoleted -malign-* forms.
GCC has supported the preferred -falign-* forms since 3.2.


Thank you for the cleanup. Could you put this in a separate commit 
please (and maybe order it first)?



Signed-off-by: Fangrui Song 
---
  configure.ac | 14 +++---
  1 file changed, 3 insertions(+), 11 deletions(-)


[…]


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] configure: Check -falign-jumps=1 -falign-functions=1 beside -falign-loops=1

[Paul Menzel]

Dear Fangrui,


Am 16.08.21 um 21:06 schrieb Fangrui Song via Grub-devel:

Clang 14.0.0 has implemented -falign-loops=1 but -falign-jumps=1 is
still unsupported. The check should test all flags which may be added


“alignment” flags?


into CFLAGS.

Signed-off-by: Fangrui Song 
---
  configure.ac | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index bee28dbeb..b2fd0c3e4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -799,14 +799,14 @@ fi
  # Force no alignment to save space on i386.
  if test "x$target_cpu" = xi386; then
AC_CACHE_CHECK([whether -falign-loops works], [grub_cv_cc_falign_loop], [
-CFLAGS="$TARGET_CFLAGS -falign-loops=1 -Werror"
+CFLAGS="$TARGET_CFLAGS -falign-jumps=1 -falign-loops=1 -falign-functions=1 
-Werror"


I guess the `AC_CACHE_CHECK` description needs to be updated too?

Please mention in the commit message, why a separate check for each 
switch is not useful.



  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
  [grub_cv_cc_falign_loop=yes],
[grub_cv_cc_falign_loop=no])
])
  
AC_CACHE_CHECK([whether -malign-loops works], [grub_cv_cc_malign_loop], [

-CFLAGS="$TARGET_CFLAGS -malign-loops=1 -Werror"
+CFLAGS="$TARGET_CFLAGS -malign-jumps=1 -malign-loops=1 -malign-functions=1 
-Werror"
  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
  [grub_cv_cc_malign_loop=yes],
[grub_cv_cc_malign_loop=no])



When you sent the v2, please include the maintainers listed in 
`MAINTAINERS` in the recipient list.



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 2/2] grub2: use stat instead of udevadm for partition lookup

[Paul Menzel]

Dear Petr, dear Jeff,


Am 08.07.21 um 17:55 schrieb Petr Vorel:

From: Jeff Mahoney 

sysfs_partition_path calls udevadm to resolve the sysfs path for
a block device. That can be accomplished by stating the device node
and using the major/minor to follow the symlinks in /sys/dev/block/.

This cuts the execution time of grub2-mkconfig from 10s to 2s on
my system.


Petr, where you able to reproduce this issue? Could the specifications 
of Jeff’s system be added to the commit message?



Signed-off-by: Jeff Mahoney 
[ pvorel: include grub/osdep/major.h ]
Signed-off-by: Petr Vorel 
---
  grub-core/osdep/linux/hostdisk.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/grub-core/osdep/linux/hostdisk.c b/grub-core/osdep/linux/hostdisk.c
index da62f924e..43dc4b0ba 100644
--- a/grub-core/osdep/linux/hostdisk.c
+++ b/grub-core/osdep/linux/hostdisk.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -105,6 +106,13 @@ sysfs_partition_path (const char *dev, const char *entry)
char *buf = NULL;
size_t len = 0;
char *path = NULL;
+  struct stat st;
+  int ret;
+
+  ret = stat(dev, &st);
+  if (ret == 0 && S_ISBLK(st.st_mode))
+return xasprintf ("/sys/dev/block/%u:%u/%s",
+ major (st.st_rdev), minor (st.st_rdev), entry);
  
argv[0] = "udevadm";

argv[1] = "info";


Now the non-block device case has one stat call more executed each time.


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 2/2] efi: Print an error if boot to firmware setup is not supported

[Paul Menzel]

Dear Javier,


Thank you for this patch.


Am 06.07.21 um 11:02 schrieb Javier Martinez Canillas:

The "fwsetup" command is only registered if the firmware supports booting
to the firmware setup UI. But it could be possible that the GRUB config
already contains a "fwsetup" entry, because it was generated in a machine
that has support for this feature.

To prevent users getting a "can't find command `fwsetup`" error if it is
not supported by the firmware, let's just always register the command but
print a more accurate message if the firmware doesn't support this option.


(I’d always paste the message in the commit message too.)


Signed-off-by: Javier Martinez Canillas 
---

  grub-core/commands/efi/efifwsetup.c | 43 +++--
  1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/grub-core/commands/efi/efifwsetup.c 
b/grub-core/commands/efi/efifwsetup.c
index eaca0328388..328c45e82e0 100644
--- a/grub-core/commands/efi/efifwsetup.c
+++ b/grub-core/commands/efi/efifwsetup.c
@@ -27,6 +27,25 @@
  
  GRUB_MOD_LICENSE ("GPLv3+");
  
+static grub_efi_boolean_t

+efifwsetup_is_supported (void)
+{
+  grub_efi_uint64_t *os_indications_supported = NULL;
+  grub_size_t oi_size = 0;
+  grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
+
+  grub_efi_get_variable ("OsIndicationsSupported", &global, &oi_size,
+(void **) &os_indications_supported);
+
+  if (!os_indications_supported)
+return 0;
+
+  if (*os_indications_supported & GRUB_EFI_OS_INDICATIONS_BOOT_TO_FW_UI)
+return 1;
+
+  return 0;
+}
+
  static grub_err_t
  grub_cmd_fwsetup (grub_command_t cmd __attribute__ ((unused)),
  int argc __attribute__ ((unused)),
@@ -38,6 +57,10 @@ grub_cmd_fwsetup (grub_command_t cmd __attribute__ 
((unused)),
grub_size_t oi_size;
grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
  
+  if (!efifwsetup_is_supported ())

+ return grub_error (GRUB_ERR_INVALID_COMMAND,
+N_("Reboot to firmware setup is not supported"));
+


I’d add: “… by the current firmware”, so it’s clear where to look.


Kind regards,

Paul



grub_efi_get_variable ("OsIndications", &global, &oi_size,
 (void **) &old_os_indications);
  
@@ -56,28 +79,8 @@ grub_cmd_fwsetup (grub_command_t cmd __attribute__ ((unused)),
  
  static grub_command_t cmd = NULL;
  
-static grub_efi_boolean_t

-efifwsetup_is_supported (void)
-{
-  grub_efi_uint64_t *os_indications_supported = NULL;
-  grub_size_t oi_size = 0;
-  grub_efi_guid_t global = GRUB_EFI_GLOBAL_VARIABLE_GUID;
-
-  grub_efi_get_variable ("OsIndicationsSupported", &global, &oi_size,
-(void **) &os_indications_supported);
-
-  if (!os_indications_supported)
-return 0;
-
-  if (*os_indications_supported & GRUB_EFI_OS_INDICATIONS_BOOT_TO_FW_UI)
-return 1;
-
-  return 0;
-}
-
  GRUB_MOD_INIT (efifwsetup)
  {
-  if (efifwsetup_is_supported ())
  cmd = grub_register_command ("fwsetup", grub_cmd_fwsetup, NULL,
 N_("Reboot into firmware setup menu."));
  



___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [SECURITY PATCH 100/117] kern/parser: Fix a stack buffer overflow

[Paul Menzel]

Dear Daniel, dear Chris,


Am 10.06.21 um 13:55 schrieb Paul Menzel:


Am 02.03.21 um 19:01 schrieb Daniel Kiper:

From: Chris Coulson 

grub_parser_split_cmdline() expands variable names present in the 
supplied

command line in to their corresponding variable contents and uses a 1 kiB
stack buffer for temporary storage without sufficient bounds checking. If
the function is called with a command line that references a variable 
with

a sufficiently large payload, it is possible to overflow the stack
buffer via tab completion, corrupt the stack frame and potentially
control execution.

Fixes: CVE-2020-27749

Reported-by: Chris Coulson 
Signed-off-by: Chris Coulson 
Signed-off-by: Darren Kenny 
Reviewed-by: Daniel Kiper 
---
  grub-core/kern/parser.c | 110 +---
  1 file changed, 67 insertions(+), 43 deletions(-)

diff --git a/grub-core/kern/parser.c b/grub-core/kern/parser.c
index e010eaa1f..6ab7aa427 100644
--- a/grub-core/kern/parser.c
+++ b/grub-core/kern/parser.c
@@ -18,6 +18,7 @@
   */
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -107,8 +108,8 @@ check_varstate (grub_parser_state_t s)
  }
-static void
-add_var (char *varname, char **bp, char **vp,
+static grub_err_t
+add_var (grub_buffer_t varname, grub_buffer_t buf,
   grub_parser_state_t state, grub_parser_state_t newstate)
  {
    const char *val;
@@ -116,31 +117,41 @@ add_var (char *varname, char **bp, char **vp,
    /* Check if a variable was being read in and the end of the name
   was reached.  */
    if (!(check_varstate (state) && !check_varstate (newstate)))
-    return;
+    return GRUB_ERR_NONE;
-  *((*vp)++) = '\0';
-  val = grub_env_get (varname);
-  *vp = varname;
+  if (grub_buffer_append_char (varname, '\0') != GRUB_ERR_NONE)
+    return grub_errno;
+
+  val = grub_env_get ((const char *) grub_buffer_peek_data (varname));
+  grub_buffer_reset (varname);
    if (!val)
-    return;
+    return GRUB_ERR_NONE;
    /* Insert the contents of the variable in the buffer.  */
-  for (; *val; val++)
-    *((*bp)++) = *val;
+  return grub_buffer_append_data (buf, val, grub_strlen (val));
  }
-static void
-terminate_arg (char *buffer, char **bp, int *argc)
+static grub_err_t
+terminate_arg (grub_buffer_t buffer, int *argc)
  {
-  if (*bp != buffer && *((*bp) - 1) != '\0')
-    {
-  *((*bp)++) = '\0';
-  (*argc)++;
-    }
+  grub_size_t unread = grub_buffer_get_unread_bytes (buffer);
+
+  if (unread == 0)
+    return GRUB_ERR_NONE;
+
+  if (*(const char *) grub_buffer_peek_data_at (buffer, unread - 1) 
== '\0')

+    return GRUB_ERR_NONE;
+
+  if (grub_buffer_append_char (buffer, '\0') != GRUB_ERR_NONE)
+    return grub_errno;
+
+  (*argc)++;
+
+  return GRUB_ERR_NONE;
  }
  static grub_err_t
-process_char (char c, char *buffer, char **bp, char *varname, char **vp,
+process_char (char c, grub_buffer_t buffer, grub_buffer_t varname,
    grub_parser_state_t state, int *argc,
    grub_parser_state_t *newstate)
  {
@@ -153,12 +164,13 @@ process_char (char c, char *buffer, char **bp, 
char *varname, char **vp,

 * not describe the variable anymore, write the variable to
 * the buffer.
 */
-  add_var (varname, bp, vp, state, *newstate);
+  if (add_var (varname, buffer, state, *newstate) != GRUB_ERR_NONE)
+    return grub_errno;
    if (check_varstate (*newstate))
  {
    if (use)
-    *((*vp)++) = use;
+    return grub_buffer_append_char (varname, use);
  }
    else if (*newstate == GRUB_PARSER_STATE_TEXT &&
 state != GRUB_PARSER_STATE_ESC && grub_isspace (use))
@@ -167,10 +179,10 @@ process_char (char c, char *buffer, char **bp, 
char *varname, char **vp,

 * Don't add more than one argument if multiple
 * spaces are used.
 */
-  terminate_arg (buffer, bp, argc);
+  return terminate_arg (buffer, argc);
  }
    else if (use)
-    *((*bp)++) = use;
+    return grub_buffer_append_char (buffer, use);
    return GRUB_ERR_NONE;
  }
@@ -181,19 +193,22 @@ grub_parser_split_cmdline (const char *cmdline,
 int *argc, char ***argv)
  {
    grub_parser_state_t state = GRUB_PARSER_STATE_TEXT;
-  /* XXX: Fixed size buffer, perhaps this buffer should be dynamically
- allocated.  */
-  char buffer[1024];
-  char *bp = buffer;
+  grub_buffer_t buffer, varname;
    char *rd = (char *) cmdline;
    char *rp = rd;
-  char varname[200];
-  char *vp = varname;
-  char *args;
    int i;
    *argc = 0;
    *argv = NULL;
+
+  buffer = grub_buffer_new (1024);
+  if (buffer == NULL)
+    return grub_errno;
+
+  varname = grub_buffer_new (200);
+  if (varname == NULL)
+    goto fail;
+
    do
  {
    if (rp == NULL || *rp == '\0')
@@ -219,7 +234,7 @@ grub_parser_split_cmdline (const char *cmdline,
  {
    grub_parser_state_t newstate;
-  if (process_ch

Re: [SECURITY PATCH 100/117] kern/parser: Fix a stack buffer overflow

[Paul Menzel]

Dear Daniel, dear Chris,


Am 02.03.21 um 19:01 schrieb Daniel Kiper:

From: Chris Coulson 

grub_parser_split_cmdline() expands variable names present in the supplied
command line in to their corresponding variable contents and uses a 1 kiB
stack buffer for temporary storage without sufficient bounds checking. If
the function is called with a command line that references a variable with
a sufficiently large payload, it is possible to overflow the stack
buffer via tab completion, corrupt the stack frame and potentially
control execution.

Fixes: CVE-2020-27749

Reported-by: Chris Coulson 
Signed-off-by: Chris Coulson 
Signed-off-by: Darren Kenny 
Reviewed-by: Daniel Kiper 
---
  grub-core/kern/parser.c | 110 +---
  1 file changed, 67 insertions(+), 43 deletions(-)

diff --git a/grub-core/kern/parser.c b/grub-core/kern/parser.c
index e010eaa1f..6ab7aa427 100644
--- a/grub-core/kern/parser.c
+++ b/grub-core/kern/parser.c
@@ -18,6 +18,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -107,8 +108,8 @@ check_varstate (grub_parser_state_t s)
  }
  
  
-static void

-add_var (char *varname, char **bp, char **vp,
+static grub_err_t
+add_var (grub_buffer_t varname, grub_buffer_t buf,
 grub_parser_state_t state, grub_parser_state_t newstate)
  {
const char *val;
@@ -116,31 +117,41 @@ add_var (char *varname, char **bp, char **vp,
/* Check if a variable was being read in and the end of the name
   was reached.  */
if (!(check_varstate (state) && !check_varstate (newstate)))
-return;
+return GRUB_ERR_NONE;
  
-  *((*vp)++) = '\0';

-  val = grub_env_get (varname);
-  *vp = varname;
+  if (grub_buffer_append_char (varname, '\0') != GRUB_ERR_NONE)
+return grub_errno;
+
+  val = grub_env_get ((const char *) grub_buffer_peek_data (varname));
+  grub_buffer_reset (varname);
if (!val)
-return;
+return GRUB_ERR_NONE;
  
/* Insert the contents of the variable in the buffer.  */

-  for (; *val; val++)
-*((*bp)++) = *val;
+  return grub_buffer_append_data (buf, val, grub_strlen (val));
  }
  
-static void

-terminate_arg (char *buffer, char **bp, int *argc)
+static grub_err_t
+terminate_arg (grub_buffer_t buffer, int *argc)
  {
-  if (*bp != buffer && *((*bp) - 1) != '\0')
-{
-  *((*bp)++) = '\0';
-  (*argc)++;
-}
+  grub_size_t unread = grub_buffer_get_unread_bytes (buffer);
+
+  if (unread == 0)
+return GRUB_ERR_NONE;
+
+  if (*(const char *) grub_buffer_peek_data_at (buffer, unread - 1) == '\0')
+return GRUB_ERR_NONE;
+
+  if (grub_buffer_append_char (buffer, '\0') != GRUB_ERR_NONE)
+return grub_errno;
+
+  (*argc)++;
+
+  return GRUB_ERR_NONE;
  }
  
  static grub_err_t

-process_char (char c, char *buffer, char **bp, char *varname, char **vp,
+process_char (char c, grub_buffer_t buffer, grub_buffer_t varname,
  grub_parser_state_t state, int *argc,
  grub_parser_state_t *newstate)
  {
@@ -153,12 +164,13 @@ process_char (char c, char *buffer, char **bp, char 
*varname, char **vp,
 * not describe the variable anymore, write the variable to
 * the buffer.
 */
-  add_var (varname, bp, vp, state, *newstate);
+  if (add_var (varname, buffer, state, *newstate) != GRUB_ERR_NONE)
+return grub_errno;
  
if (check_varstate (*newstate))

  {
if (use)
-   *((*vp)++) = use;
+return grub_buffer_append_char (varname, use);
  }
else if (*newstate == GRUB_PARSER_STATE_TEXT &&
   state != GRUB_PARSER_STATE_ESC && grub_isspace (use))
@@ -167,10 +179,10 @@ process_char (char c, char *buffer, char **bp, char 
*varname, char **vp,
 * Don't add more than one argument if multiple
 * spaces are used.
 */
-  terminate_arg (buffer, bp, argc);
+  return terminate_arg (buffer, argc);
  }
else if (use)
-*((*bp)++) = use;
+return grub_buffer_append_char (buffer, use);
  
return GRUB_ERR_NONE;

  }
@@ -181,19 +193,22 @@ grub_parser_split_cmdline (const char *cmdline,
   int *argc, char ***argv)
  {
grub_parser_state_t state = GRUB_PARSER_STATE_TEXT;
-  /* XXX: Fixed size buffer, perhaps this buffer should be dynamically
- allocated.  */
-  char buffer[1024];
-  char *bp = buffer;
+  grub_buffer_t buffer, varname;
char *rd = (char *) cmdline;
char *rp = rd;
-  char varname[200];
-  char *vp = varname;
-  char *args;
int i;
  
*argc = 0;

*argv = NULL;
+
+  buffer = grub_buffer_new (1024);
+  if (buffer == NULL)
+return grub_errno;
+
+  varname = grub_buffer_new (200);
+  if (varname == NULL)
+goto fail;
+
do
  {
if (rp == NULL || *rp == '\0')
@@ -219,7 +234,7 @@ grub_parser_split_cmdline (const char *cmdline,
{
  grub_parser_state_t newstate;
  
-	  if (process_char (*rp, buffer, &bp, varname, &vp, state, argc,

+ if (process_char (*rp, buffer, varname, state, argc,
 

Re: [PATCH v2 1/2] MAINTAINERS: Add MAINTAINERS file

[Paul Menzel]

Dear Daniel,


Am 07.06.21 um 20:07 schrieb Daniel Kiper:

The MAINTAINERS file provides basic information about the GRUB project
and its maintainers.

Signed-off-by: Alex Burmashev 
Signed-off-by: Vladimir Serbinenko 
Signed-off-by: Daniel Kiper 
---
v2 - suggestions/fixes:
- mention the MAINTAINERS file in the README file
  (suggested by Paul Menzel),
- s/http/https/
  (suggested by Paul Menzel).
---
  MAINTAINERS | 31 +++
  README  |  2 ++
  2 files changed, 33 insertions(+)
  create mode 100644 MAINTAINERS

diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 0..9eff2b8ab
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,31 @@
+List of current GRUB maintainers and some basic information about the project
+=
+
+Here is the list of current GRUB maintainers:
+  - Daniel Kiper  and ,
+  - Alex Burmashev ,
+  - Vladimir 'phcoder' Serbinenko .
+
+The maintainers drive and overlook the GRUB development.
+
+The GRUB development happens on the grub-devel mailing list [1]. The latest
+GRUB source code is available at Savannah git repository [2].
+
+Users can ask for help on the help-grub mailing list [3].
+
+
+List of past GRUB maintainers and people who strongly contributed to the 
project
+
+
+Here is the list, sorted alphabetically, of past GRUB maintainers and people 
who
+strongly contributed to the project:
+  - Andrei Borzenkov,
+  - Bryan Ford,
+  - Erich Stefan Boleyn,
+  - Gordon Matzigkeit,
+  - Yoshinori K. Okuji.
+
+
+[1] https://lists.gnu.org/mailman/listinfo/grub-devel
+[2] https://git.savannah.gnu.org/gitweb/?p=grub.git&view=view+git+repository
+[3] https://lists.gnu.org/mailman/listinfo/help-grub
diff --git a/README b/README
index 685b01657..b1aa79723 100644
--- a/README
+++ b/README
@@ -7,6 +7,8 @@ See the file NEWS for a description of recent changes to GRUB 2.
  See the file INSTALL for instructions on how to build and install the
  GRUB 2 data and program files.
  
+See the file MAINTAINERS for information about the GRUB maintainers, etc.

+


I still think, it’s a little confusing to have the information about the 
list and the source code URL in the file `MAINTAINERS`.



  Please visit the official web page of GRUB 2, for more information.
  The URL is <http://www.gnu.org/software/grub/grub.html>.
  


Otherwise this looks good.


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 2/2] SECURITY: Add SECURITY file

[Paul Menzel]

Dear Daniel,


Am 01.06.21 um 18:13 schrieb Daniel Kiper:

The SECURITY file describes the GRUB project security policy.

It is based on https://github.com/wireapp/wire/blob/master/SECURITY.md

Signed-off-by: Alex Burmashev 
Signed-off-by: Vladimir Serbinenko 
Signed-off-by: Daniel Kiper 
---
  MAINTAINERS |  3 +++
  SECURITY| 61 +
  2 files changed, 64 insertions(+)
  create mode 100644 SECURITY

diff --git a/MAINTAINERS b/MAINTAINERS
index 41fdf5a04..3d5d1ae97 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8,6 +8,9 @@ Here is the list of current GRUB maintainers:
  
  The maintainers drive and overlook the GRUB development.
  
+If you found a security vulnerability in the GRUB please check the SECURITY file to

+get more information how to properly report this kind of bugs to the 
maintainers.
+


I’d put this into the file `README`.


  The GRUB development happens on the grub-devel mailing list [1]. The latest
  GRUB source code is available at Savannah git repository [2].
  
diff --git a/SECURITY b/SECURITY

new file mode 100644
index 0..abe1a2fe4
--- /dev/null
+++ b/SECURITY
@@ -0,0 +1,61 @@
+Security Policy
+===
+
+To report a vulnerability see "Reporting a Vulnerability" below.
+
+
+Security Incident Policy
+
+
+Security bug reports are treated with special attention and are handled
+differently from normal bugs. In particular, security sensitive bugs are not
+handled in public but in private. Information about the bug and access to it
+is restricted to people in the security bug group, the individual engineers


Who is the “security bug group”?


+that work on fixing it, and any other person who needs to be involved for
+organisational reasons. The process is handled by the security team, which
+decides on the people involved in order to fix the issue. It is also
+guaranteed that the person reporting the issue has visibility into the process
+of fixing it. Any security issue gets prioritized according to its security
+rating. The issue is opened up to the public in coordination with the release
+schedule and the reporter.
+
+
+Disclosure Policy
+=
+
+Everyone involved in the handling of a security issue - including the reporter 
-
+is required to adhere to the following policy. Any information related to


Are you sure you can put these restrictions on the reporter?


+a security issue must be treated as confidential and only shared with trusted
+partners if necessary, for example to coordinate a release or manage exposure
+of clients to the issue. No information must be disclosed to the public before
+the embargo ends. The embargo time is agreed upon by all involved parties. It
+should be as short as possible without putting any users at risk.
+
+
+Supported Versions
+==
+
+Only the most recent version of the GRUB is supported.
+
+While there's currently no bug bounty program we appreciate every report.
+
+
+Reporting a Vulnerability
+=
+
+The security report has to be encrypted with the PGP keys and send to ALL email


s/has to be/should be/

I guess you will look at these reports even if they are not encrypted?


+addresses listed below. Every vulnerability report will be assessed within
+72 hours of receiving it. If the outcome of the assessment is that the report
+describes a security issue, the report will be transferred into an issue on the
+internal vulnerability project for further processing. The reporter is updated
+on each step of the process.
+
+* Contact: Daniel Kiper  and
+   Daniel Kiper 
+* PGP Key Fingerprint: BE5C 2320 9ACD DACE B20D  B0A2 8C81 89F1 988C 2166
+
+* Contact: Alex Burmashev 
+* PGP Key Fingerprint: 50A4 EC06 EF7E B84D 67E0  3BB6 2AE2 C87E 28EF 2E6E
+
+* Contact: Vladimir 'phcoder' Serbinenko 
+* PGP Key Fingerprint: E53D 497F 3FA4 2AD8 C9B4  D1E8 35A9 3B74 E82E 4209



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/2] MAINTAINERS: Add MAINTAINERS file

[Paul Menzel]

Dear Daniel,


Thank you for creating this

Am 01.06.21 um 18:13 schrieb Daniel Kiper:

The MAINTAINERS file provides basic information about the GRUB project
and its maintainers.

Signed-off-by: Alex Burmashev 
Signed-off-by: Vladimir Serbinenko 
Signed-off-by: Daniel Kiper 
---
  MAINTAINERS | 31 +++
  1 file changed, 31 insertions(+)
  create mode 100644 MAINTAINERS

diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 0..41fdf5a04
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,31 @@
+List of current GRUB maintainers and some basic information about the project
+=


In my opinion the basic information should go into the file `README`.


+
+Here is the list of current GRUB maintainers:
+  - Daniel Kiper  and ,
+  - Alex Burmashev ,
+  - Vladimir 'phcoder' Serbinenko .
+


My personal preference would be to remove the , and dot/period from the 
items [4].



Capitalization and punctuation are optional when using single words
or phrases in bulleted form. If each bullet or numbered point is a
complete sentence, capitalize the first word and end each sentence
with proper ending punctuation. The rule of thumb is to be
consistent.




+The maintainers drive and overlook the GRUB development.
+
+The GRUB development happens on the grub-devel mailing list [1]. The latest
+GRUB source code is available at Savannah git repository [2].
+
+Users can ask for help on the help-grub mailing list [3].
+
+


As written above, I’d put the two paragraphs above in the file `README`.


+List of past GRUB maintainers and people who strongly contributed to the 
project
+
+
+Here is the list, sorted alphabetically, of past GRUB maintainers and people 
who
+strongly contributed to the project:
+  - Andrei Borzenkov,
+  - Bryan Ford,
+  - Erich Stefan Boleyn,
+  - Gordon Matzigkeit,
+  - Yoshinori K. Okuji.
+
+
+[1] https://lists.gnu.org/mailman/listinfo/grub-devel
+[2] http://git.savannah.gnu.org/gitweb/?p=grub.git&view=view+git+repository


Why not the HTTPS URL?


+[3] https://lists.gnu.org/mailman/listinfo/help-grub


Whatever you decide, you also might want to reference this file in the 
file `README` as other files are referenced there too.



Kind regards,

Paul


[4]: https://www.grammarbook.com/blog/colons/colons/

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [SECURITY PATCH 000/117] Multiple GRUB2 vulnerabilities - 2021/03/02 round

[Paul Menzel]

Dear Darren, dear Darren,


Am 02.03.21 um 19:00 schrieb Daniel Kiper:

Thank you very much for finding and fixing all these issues, and 
coordinating the publication.


[…]


  .../lib/gnulib-patches/fix-null-state-deref.patch  |  12 +
  .../gnulib-patches/fix-regcomp-uninit-token.patch  |  15 +
  .../gnulib-patches/fix-regexec-null-deref.patch|  12 +
  .../lib/gnulib-patches/fix-uninit-structure.patch  |  11 +
  .../lib/gnulib-patches/fix-unused-value.patch  |  14 +

Just a small question, if all these fixes were sent and applied upstream.


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [SECURITY PATCH 029/117] zstd: Initialize seq_t structure fully

[Paul Menzel]

Dear Darren, dear Daniel,


Am 02.03.21 um 19:00 schrieb Daniel Kiper:

From: Darren Kenny 

While many compilers will initialize this to zero, not all will,


Which ones do not?


so it is better to be sure that fields not being explicitly set are at known
values, and there is code that checks this fields value elsewhere in the
code.

Fixes: CID 292440


What is the exact error? Is there a code flow, where one element does 
not get set. (The commit message would be incorrect if this is not the 
case.)


Lastly, this is imported from upstream. I created an issue upstream [1].


Signed-off-by: Darren Kenny 
Reviewed-by: Daniel Kiper 
---
  grub-core/lib/zstd/zstd_decompress.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/grub-core/lib/zstd/zstd_decompress.c 
b/grub-core/lib/zstd/zstd_decompress.c
index 711b5b6d7..e4b5670c2 100644
--- a/grub-core/lib/zstd/zstd_decompress.c
+++ b/grub-core/lib/zstd/zstd_decompress.c
@@ -1325,7 +1325,7 @@ typedef enum { ZSTD_lo_isRegularOffset, 
ZSTD_lo_isLongOffset=1 } ZSTD_longOffset
  FORCE_INLINE_TEMPLATE seq_t
  ZSTD_decodeSequence(seqState_t* seqState, const ZSTD_longOffset_e longOffsets)
  {
-seq_t seq;
+seq_t seq = {0};
  U32 const llBits = 
seqState->stateLL.table[seqState->stateLL.state].nbAdditionalBits;
  U32 const mlBits = 
seqState->stateML.table[seqState->stateML.state].nbAdditionalBits;
  U32 const ofBits = 
seqState->stateOffb.table[seqState->stateOffb.state].nbAdditionalBits;



I once read, that compilers cannot warn you, if you miss setting an 
element if you initialize structures to 0 in the beginning.



Kind regards,

Paul


[1]: https://github.com/facebook/zstd/issues/2545

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 1/8] linux/arm: fix ARM Linux header layout

[Paul Menzel]

Dear Dimitri,


Am 11.03.21 um 12:44 schrieb Dimitri John Ledkov:

The patch from 
https://lists.gnu.org/archive/html/grub-devel/2020-10/msg00122.html

Is still not applied, and yet it is required to boot armhf linux
kernel in qemu OVMF with grub.


Please give the example command line, and maybe even add a test.


It is applied in rhboot/grub2
https://src.fedoraproject.org/rpms/grub2/blob/rawhide/f/0143-Make-linux_arm_kernel_header.hdr_offset-be-at-the-ri.patch

And it is applied in OpenSUSE too
https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/0005-Make-linux_arm_kernel_header.hdr_offset-be-at-the-ri.patch?expand=1

I want to apply it in Ubuntu too.

It is still not present in grub2 mainline, and applies cleanly.

Can it please be applied?


I guess you could have sent v3, or kept the threading. ;-)


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Threading of patch series (was: [PATCH v6 00/14] error: Do compile-time format string checking on grub>)

[Paul Menzel]

Dear Glenn,


Am 06.03.21 um 00:15 schrieb Glenn Washburn:

On Fri, 5 Mar 2021 17:27:01 +0100 Daniel Kiper wrote:


[…]


By the way, my I ask you once again to send each patch series as
separate thread. Now you are attaching all patch sets to one cover
letter which is confusing. Please stop doing that.


How do you pull patch series from the mailing list? I'm curious if this
is messing with that. Also what email client do you use?

You are correct that I'm attaching all new versions of the patch series
to one cover letter, but each patch series also has its own cover
letter. So I don't consider the cover letter that is the root of the
thread to be the cover letter for the new patch series.

I can't find our prior correspondence. I recall saying that the
patchset series in question had been not done in a less than ideal way
because I had start by replying to the cover letter of the prior
patchset and then switched to replying to a particular patchset cover
letter. This was because with experience I determined that attaching to
the thread of the next version of a patchset to the cover letter of the
first version of the patchset looked much nicer in my browser. I
also recall saying that I'd do this in the future to see if it worked
well doing it properly from the start.

My goal is to keep all versions of a patchset together in a client
with tree view of threads (eg. my mail client claws-mail). This makes
it easy to go back to a prior patchset to look at comments. I also
wanted to meet this goal in an aesthetically pleasing way. The first
attempt which attached a new version of a patchset to its priors cover
letter did not meet this because it created a deep tree for patchsets
with lots of revisions. However, attaching each new patchset to the
cover letter of the first patchset, keeps thread tree to a minimum.  It
also makes it to collapse only certain patchset versions (aside from
the first). Also, since I have threads sorted by thread date, I see
patchsets ordered from most recent to least recent, which it how I like
to order all my emails.

The current case does not strictly adhere to these rules because I'm
taking v4 as the initial patchset, which perhaps may be the source of
some confusion. Other than that I think its worked out nicely.

So I'm curious if this is causing some issue with tooling. And I'm
curious what exactly is causing confusion? In my browser its fairly
obvious that the root of the thread is the cover letter for v4 of the
patch series and that the cover letters of attached patch series are
different, noted by a different version number.


At least here, Mozilla Thunderbird 78.8.0 is only able to collapse the 
top thread and not sub threads.


The mailing list archive does not seem to care [1], though that might be 
because the v4 patch set cover letter is in a different month.


Anyway, as *displaying* of threading is not defined and different 
between user agents, maybe it’s better to not rely on that.



Kind regards,

Paul


[1]: https://lists.gnu.org/archive/html/grub-devel/2021-03/threads.html

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] disk/pata: Suppress error message "no device connected"

[Paul Menzel]

Dear Glenn,


Am 01.03.21 um 20:36 schrieb Glenn Washburn:

This error message comes from the grub_print_error in
grub_pata_device_initialize, which does not pass on the error, and is
raised in check_device. The function check_device needs to return this as
an error because check_device is also used in grub_pata_open, which does
pass on this error to indicate that the device can not be used.

This is actually not an error when displayed by grub_pata_device_initialize
because it just indicates that there are no pata devices seen. This may be
confusing to end users who do not have pata devices yet are loading the
pata module (perhaps implicitly via nativedisk). This also causes unnessary
output which may need to be accounted for in functional testing.

Instead print to the debug log when check_device raises this "error" and pop
the error from the error stack. If there is another error on the stack then
print the error stack as those should be real errors.

Signed-off-by: Glenn Washburn 
---
  grub-core/disk/pata.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/grub-core/disk/pata.c b/grub-core/disk/pata.c
index 23eef2be1..b15aeaa13 100644
--- a/grub-core/disk/pata.c
+++ b/grub-core/disk/pata.c
@@ -331,6 +331,12 @@ grub_pata_device_initialize (int port, int device, int 
addr)
*devp = dev;
  
err = check_device (dev);

+  if (err == GRUB_ERR_UNKNOWN_DEVICE)
+{
+  grub_dprintf ("pata", "%s\n", grub_errmsg);
+  grub_error_pop();
+}
+


(The indentation looks wrong in Mozilla Thunderbird, but applying the 
patch, everything is fine. The non-changed lines are indented by two 
spaces too much.)



if (err)
  grub_print_error ();



Acked-by: Paul Menzel 


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] disk/pata: Prepend log message with PATA

[Paul Menzel]

Seeing

no device connected

it’s not clear, what component this belongs to. So prepend it to log:

PATA: no device connected

Signed-off-by: Paul Menzel 
---
 grub-core/disk/pata.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/grub-core/disk/pata.c b/grub-core/disk/pata.c
index 23eef2be1..f9a3d3132 100644
--- a/grub-core/disk/pata.c
+++ b/grub-core/disk/pata.c
@@ -294,7 +294,7 @@ check_device (struct grub_pata_device *dev)
   grub_uint8_t sec = grub_pata_regget (dev, GRUB_ATA_REG_SECTORS);
   grub_dprintf ("ata", "sectors=0x%x\n", sec);
   if (sec != 0x5A)
-return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "no device connected");
+return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "PATA: no device connected");
 
   /* The above test may detect a second (slave) device
  connected to a SATA controller which supports only one
-- 
2.30.1


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2 2/2] efi: SPI NOR flash command line

[Paul Menzel]

Dear Michael,


Am 12.02.21 um 10:20 schrieb Michael Lawnick:


Note: There is a bug in code below which will let this code fail on
BIOS-UEFI and requires a v3 as soon as basic discussion whether this
sort of functionality is accepted at all is done.
I don't want to disturb thread by a v3 thread.


Thank you for preparing and upstreaming the patches.

I think, I read, that the maintainers should be added to Cc for patches, 
but as written, and as seen from the thread *RFC: Grub project 
management*, GRUB definitely has some resource problems. So, if you 
could send the v3 with the maintainers in Cc, that would be great.


[…]


Am 05.02.2021 um 10:02 schrieb Michael Lawnick:

Add SPI NOR flash to command line
Based on patch '[PATCH 1/2] efi: SPI NOR flash support'
add command line functionality for interactive access
to SPI NOR flash.

Supported commands:
spi_nor
   init  - establish communication to a flash part
   read  - read from flash part to memory or print hexdump
   write - write to flash part from memory
   erase - erase some erase blocks


Please name the system (board and firmware) you tested this with, and 
maybe give an example, how to test this. Is QEMU able to emulate a SPI 
NOR flash chip?



Signed-off-by: Michael Lawnick 
---
[Patch v2 2/2]: no change
---
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 4d775e5f6..403a5432f 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -659,6 +659,7 @@ module = {
   module = {
 name = efi_spi_nor;
 common = bus/spi/efi_spi_nor.c;
+  common = commands/efi/spinorcmd.c;
 enable = efi;
   };

diff --git a/grub-core/commands/efi/spinorcmd.c
b/grub-core/commands/efi/spinorcmd.c
new file mode 100644
index 0..c55a900aa
--- /dev/null
+++ b/grub-core/commands/efi/spinorcmd.c
@@ -0,0 +1,253 @@
+/*  spinorcmd.c  - Give access to SPI NOR flash on command line.
+ *  Copyright 2021 Nokia
+ *  Licensed under the GNU General Public License v3.0 only
+ *  SPDX-License-Identifier: GPL-3.0-only
+ *
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2008  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+GRUB_MOD_LICENSE ("GPLv3+");
+
+static void *cli_spi_flash_device = NULL;
+
+static void
+usage (void)
+{
+    grub_printf("spi_nor - access SPI NOR flash through UEFI API\n");
+    grub_printf("Usage:\n");
+    grub_printf("  spi_nor init|read|write|format \n");
+    grub_printf("  init [-id ] [-cnt ]\n");
+    grub_printf(" to be called once before operation on a 
device.\n");
+    grub_printf("     : optional up to 3 bytes flash 
identifier\n");
+    grub_printf("   to match against\n");
+    grub_printf("  : use n-th occurance of  device\n");
+    grub_printf("   (can be combined with )\n");
+    grub_printf("  read   []\n");
+    grub_printf(" read and dump/save bytes\n");
+    grub_printf("  write   \n");
+    grub_printf(" write bytes from  to flash\n");
+    grub_printf("  erase  \n");
+    grub_printf(" format area \n");
+    grub_printf(" ( and  must be erase block 
alligned)\n");


aligned


+    grub_printf("\n");
+}
+
+/*  get_init_args - return index and number of -id and/or -cnt arguments
+    handle 4 possible inputs:
+    - spi_nor init -id   -cnt 
+    - spi_nor init -cnt  -id 
+    - spi_nor init -cnt 
+    - spi_nor init -id   
+*/
+static int get_init_args(int argc, char **args, int *id_idx, int
*id_cnt, int *cnt_idx)
+{
+    int opt_idx = 1;
+    *id_idx = 0;
+    *cnt_idx = 0;
+    *id_cnt = 0;
+
+    while (opt_idx < argc) {
+    if (!grub_strcmp(args[opt_idx],"-id")) {


Please add a space after the comma.


+    opt_idx++;
+    *id_idx = opt_idx;
+
+    while ((opt_idx < argc)
+    && (grub_strcmp(args[opt_idx], "-cnt"))
+    && (*id_cnt < 3)) {
+    opt_idx++;
+    *id_cnt = *id_cnt + 1;
+    }
+
+    if (*id_cnt == 0)
+    return 1;
+    } else if (!grub_strcmp(args[opt_idx],"-cnt")) {
+    if (argc > opt_idx + 1) {
+    *cnt_idx = opt_idx + 1;
+    opt_idx += 2;

Re: Re: [PATCH v2 1/2] efi: SPI NOR flash support

[Paul Menzel]

Sehr geehrte Damen und Herren,


vielen Dank für Ihre Nachricht, die ich nach dem 12. Februar 2021 lesen werde.


Freundliche Grüße

Paul Menzel

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/1] docs: luks2: Mention key derival function support

[Paul Menzel]

Dear Petr,


Thank you for your patch.

Am 03.02.21 um 12:02 schrieb Petr Vorel:

To give users hint why Argon2 (the default in cryptsetup for LUKS2)
does not work.

Signed-off-by: Petr Vorel 
---


[…]


  docs/grub.texi | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index eeac9b2ce..7360da128 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4291,7 +4291,8 @@ devices; option @option{-b} configures all geli 
containers that have boot flag s
  
  GRUB suports devices encrypted using LUKS, LUKS2 and geli. Note that necessary

  modules (@var{luks}, @var{luks2} and @var{geli}) have to be loaded manually
-before this command can be used.
+before this command can be used. For LUKS2 only the PBKDF2 key derival
+function is supported (Argon2 is not yet supported).


Nit: I’d get rid of the parentheses.


For LUKS2 only the PBKDF2 key derival function is supported, as
Argon2 is not yet supported.


Either way:

Acked-by: Paul Menzel 


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [RFC] efi spi flash support - where to place

[Paul Menzel]

Dear Michael,


Am 01.02.21 um 10:46 schrieb Michael Lawnick:

Am 22.01.2021 um 16:58 schrieb Paul Menzel:

I'm not (yet) in sync with grub timeline, when is next release planned
(last commit date)?


March *last* year sometime? ;-) I think the current date is March,
though re-reading the list posts, do not hold your breath, that it will
be committed, as the maintainers won’t have time to apply the commit.


:-)

My commit is currently in approval process for upstream by company.
Hope to get a 'go' next week.


Awesome. Thank you for going the extra mile to upstream the stuff.


In parallel I am now working on EFI_PCI_IO_CONTROL and run into a
problem while trying to find a common API:


[…]

Please start a new thread with a new descriptive subject line for this 
issue to increase your chances of getting a response, and to follow the 
mailing list netiquette.



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [RFC] efi spi flash support - where to place

[Paul Menzel]

Dear Michael,


Am 22.01.21 um 10:42 schrieb Michael Lawnick:

Am 22.01.2021 um 07:51 schrieb Paul Menzel:

Am 19.01.21 um 11:38 schrieb Michael Lawnick:
Q: where to place the efi driver, where to place the command line 
handler.


Currently I'd say
- create grub-core/flash/efispinor.c for the driver


I guess, that would be fine, but I found,
`grub-core/bus/spi/rk3288_spi.c`, so I suggest to place it there.


I'll check for a move before sending the patch set.
Version to patch against is 6213184b26689fa2e3db297b54cf4eb1713bcad1 ,
right?


Sounds right – whatever is at the top in master. I don’t expect 
conflicts, these are new files.



- create grub-core/commands/efi/efispinor.c for the command line tool.


Can you please elaborate on the usage? Couldn’t it be some generic tool,
and it doesn’t matter, what interface in the background?


efispinor.c contains commands 'spinor init|read|write|erase'. i.e.
commands to work with flash through efi.


But the command is generic, isn’t it? Shouldn’t that go into 
`grub-core/commands/flash/spinor.c` at least?



Adding a SPI bus driver like rk3288_spi.c into this implies an
additional SPI flash layer which then bases on the SPI bus controller.
This is something I wouldn't be able to test due to missing H/W and adds
a huge amount of work (which I guess my company isn't interested in to
pay ;-) )
If there were already a flash command layer there wouldn't be any issue
to integrate into that. But I didn't see it.
May be in flow of discussion we can rearrange my code in such way that
it easily integrates to a possibly upcoming flash command frame work.


Yes, please post the patch first.


I am looking forward to this patch. I have no idea, if it will get into
the next release. But as it’s a new driver and command not affecting
existing stuff, an exception could be made.


I'm not (yet) in sync with grub timeline, when is next release planned
(last commit date)?


March *last* year sometime? ;-) I think the current date is March, 
though re-reading the list posts, do not hold your breath, that it will 
be committed, as the maintainers won’t have time to apply the commit.



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [RFC] efi spi flash support - where to place

[Paul Menzel]

Dear Michael,


Am 19.01.21 um 11:38 schrieb Michael Lawnick:


first of all, I am new to this group/grub. So please be patient if I
violate some group internal rules, just point it out.
Formerly I worked many years on U-Boot.


Welcome to GRUB, and no worries. Plain text emails, and polite. What 
more can we wish for. ;-)



I have made a driver and command line tool for accessing SPI NOR flash
via EFI interface which I would like to upstream.


Very nice.


Q: where to place the efi driver, where to place the command line handler.

Currently I'd say
- create grub-core/flash/efispinor.c for the driver


I guess, that would be fine, but I found, 
`grub-core/bus/spi/rk3288_spi.c`, so I suggest to place it there.



- create grub-core/commands/efi/efispinor.c for the command line tool.


Can you please elaborate on the usage? Couldn’t it be some generic tool, 
and it doesn’t matter, what interface in the background?


[…]

I am looking forward to this patch. I have no idea, if it will get into 
the next release. But as it’s a new driver and command not affecting 
existing stuff, an exception could be made.



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Make EFI minimum heap size configurable via --enable-efi-min-heap-mb

[Paul Menzel]

Dear Hanson,


Am 04.01.21 um 20:34 schrieb Char, Hanson via Grub-devel:

When booted in UEFI mode, Grub would fail to load a ramdisk of size larger than 
"(total_pages >> 2)" with

 "error: out of memory"

(https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/kern/efi/mm.c#n616)

This proposed patch adds a new option that can be used to specify the "EFI min heap 
size" in MB.  For example,

 ./configure --with-platform=efi --target=x86_64 
--enable-efi-min-heap-mb=600

The patch has been successfully tested to load large ramdisk with size that 
would otherwise fail.


Thank you for the patch and description. Could you please add it as the 
git commit message, and send a v2, maybe even using `git send-email`?



 From 9bd4220a6b0fe2d49c6aed347f5d2bbff5fb2d8d Mon Sep 17 00:00:00 2001
From: Hanson Char 
Date: Thu, 31 Dec 2020 12:49:33 -0800
Subject: [PATCH] Make EFI minimum heap size configurable via 
--enable-efi-min-heap-mb


Please excuse my ignorance, but I do not fully understand the problem 
and solution yet. What has the minimum heap size to do with the problem, 
and why does increasing it fixes it?


```
  /* By default, request a quarter of the available memory.  */
  total_pages = get_total_pages (filtered_memory_map, desc_size,
 filtered_memory_map_end);
  required_pages = (total_pages >> 2);
  if (required_pages < BYTES_TO_PAGES (MIN_HEAP_SIZE))
required_pages = BYTES_TO_PAGES (MIN_HEAP_SIZE);
  else if (required_pages > BYTES_TO_PAGES (MAX_HEAP_SIZE))
required_pages = BYTES_TO_PAGES (MAX_HEAP_SIZE);
```

Currently, MIN_HEAP_SIZE is 1 MB, and setting it to 600 MB fixes the 
issue for you. If `required_pages` is smaller than “1 MB pages” it’s 
also smaller than “600 MB pages“, isn’t it?



Kind regards,

Paul


---
config.h.in |  2 ++
configure.ac| 18 ++
grub-core/kern/efi/mm.c |  2 +-
3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/config.h.in b/config.h.in
index 9e8f9911b..413287410 100644
--- a/config.h.in
+++ b/config.h.in
@@ -13,6 +13,8 @@
#define DISK_CACHE_STATS @DISK_CACHE_STATS@
#define BOOT_TIME_STATS @BOOT_TIME_STATS@

+#define EFI_MIN_HEAP_MB @EFI_MIN_HEAP_MB@
+
/* We don't need those.  */
#define MINILZO_CFG_SKIP_LZO_PTR 1
#define MINILZO_CFG_SKIP_LZO_UTIL 1
diff --git a/configure.ac b/configure.ac
index 7c10a4db7..8c4bb820e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1934,6 +1934,21 @@ AC_SUBST(HOST_CCASFLAGS)

AC_SUBST(BUILD_LIBM)

+#
+# EFI minimum heap size in MB ranging from 1 to 1600.  Default is 1.
+#
+AC_ARG_ENABLE([efi-min-heap-mb],
+  [AS_HELP_STRING([--enable-efi-min-heap-mb=SIZE_IN_MB],
+  [set the EFI minimum heap size in MB between 1 
and 1600 inclusive])])
+AS_IF([test x"$enable_efi_min_heap_mb" = x -o x"$enable_efi_min_heap_mb" = 
xno],
+  [EFI_MIN_HEAP_MB=1],
+  [AS_IF([test x"${enable_efi_min_heap_mb//@<:@0-9@:>@/}" != x \
+   || test "$enable_efi_min_heap_mb" -lt 1 -o 
"$enable_efi_min_heap_mb" -gt 1600],
+ [AC_MSG_ERROR([EFI minimum heap size must be between 1 and 1600 
inclusive])],
+ [EFI_MIN_HEAP_MB=$enable_efi_min_heap_mb])])
+
+AC_SUBST([EFI_MIN_HEAP_MB])
+
#
# Automake conditionals
#
@@ -2132,5 +2147,8 @@ echo "Without liblzma (no support for XZ-compressed mips 
images) ($liblzma_excus
else
echo "With liblzma from $LIBLZMA (support for XZ-compressed mips images)"
fi
+if [ x"$enable_efi_min_heap_mb" != x ]; then
+echo efi-min-heap-mb: $EFI_MIN_HEAP_MB
+fi
echo "***"
]
diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
index 457772d57..ac5112b57 100644
--- a/grub-core/kern/efi/mm.c
+++ b/grub-core/kern/efi/mm.c
@@ -39,7 +39,7 @@
#define MEMORY_MAP_SIZE 0x3000

/* The minimum and maximum heap size for GRUB itself.  */
-#define MIN_HEAP_SIZE  0x10
+#define MIN_HEAP_SIZE  (EFI_MIN_HEAP_MB * 0x10)
#define MAX_HEAP_SIZE   (1600 * 0x10)

static void *finish_mmap_buf = 0;
--
2.29.2


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Interrupt boot and display menu with `GRUB_TIMEOUT=0`?

[Paul Menzel]

Dear GRUB folks,


Setting the GRUB timeout to 0

`GRUB_TIMEOUT=0`

is it possible to interrupt the boot somehow for example by holding a 
key done? There are some posts on the WWW claiming it was once possible 
using the shift key [1], but it didn’t work in my tests with Debian 
bullseye/testing.



Kind regards,

Paul


[1]: https://centosfaq.org/centos/display-boot-menu-with-grub_timeout0/

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [SPECIFICATION RFC] The firmware and bootloader log specification

[Paul Menzel]

Dear Wim, dear Daniel,


First, thank you for including all parties in the discussion.
Am 04.12.20 um 13:52 schrieb Wim Vervoorn:


I agree with you. Using an existing standard is better than inventing
a new one in this case. I think using the coreboot logging is a good
idea as there is indeed a lot of support already available and it is
lightweight and simple.
In my opinion coreboot’s format is lacking, that it does not record the 
timestamp, and the log level is not stored as metadata, but (in 
coreboot) only used to decide if to print the message or not.


I agree with you, that an existing standard should be used, and in my 
opinion it’s Linux message format. That is most widely supported, and 
existing tools could then also work with pre-Linux messages.


Sean Hudson from Mentor Graphics presented that idea at Embedded Linux 
Conference Europe 2016 [1]. No idea, if anything came out of that 
effort. (Unfortunately, I couldn’t find an email. Does somebody have 
contacts at Mentor to find out, how to reach him?)



Kind regards,

Paul


[1]: 
http://events17.linuxfoundation.org/sites/events/files/slides/2016-10-12%20-%20ELCE%20-%20Shared%20Logging%20-%20Part%20Deux.pdf


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Fwd: [coreboot] Upcoming virtual OSFC 2020

[Paul Menzel]

Dear GRUB folks,


Maybe some of you are interested in Open Source Firmware Conference.


Kind regards,

Paul
--- Begin Message ---
Hello people,

This is a last reminder on the upcoming OSFC 2020 (www.osfc.io) which will 
start tomorrow noon CET.
If you are interested in attending the conference, please get your tickets via 
https://hopin.com/events/osfc-2020

Best regards,
Philipp
___
coreboot mailing list -- coreb...@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
--- End Message ---
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Universal Payload Project

[Paul Menzel]

Dear coreboot, GRUB, and SeaBIOS folks,


In #coreb...@irc.freenode.net somebody mentioned the Universal Payload
Project [1].


The goal of this project is to define an interface between a first
stage platform initialization bootloader and a second stage payload.


As there also is a specification [2], I just wanted to make you aware of 
it, in case you have comments. Please keep in mind, that I do not know 
more details, so please do not jump to conclusions.



Kind regards,

Paul


[1]: https://github.com/universalpayload/Introduction
[2]: https://universalpayload.github.io/documentation/spec/spec.html

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Funding for OSS security improvements by Google

[Paul Menzel]

Dear GRUB folks,


From *Announcing updates to our Patch Rewards program in 2020 * [1]:


Projects in scope

Any open source project can be nominated for support. When selecting
projects, the panel will put an emphasis on projects that either are
vital to the health of the Internet or are end-user projects with a
large user base.



What do we expect in return?

We expect to see security improvements to open source software.
Ideally, the project can provide us with a short blurb or pointers to
some of the completed work that was possible because of our support.
We don’t want to add bureaucracy, but would like to measure the
success of the program.


GRUB is widely used. Maybe some individuals and organizations working on 
GRUB could be paid for some of their great GRUB work they are doing.



Kind regards,

Paul


[1]: 
https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] tests: F2FS test should use MOUNTDEVICE like other tests.

[Paul Menzel]

Dear Glenn,


Am 29.08.20 um 01:30 schrieb Glenn Washburn:

LODEVICES is not an array variable and should not be accessed as such. This
allows the f2fs test to pass as it was failing because a device name had a
space prepended to the path.

Signed-off-by: Glenn Washburn 
---
  tests/util/grub-fs-tester.in | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/util/grub-fs-tester.in b/tests/util/grub-fs-tester.in
index bc14a05ca..bfc425e1f 100644
--- a/tests/util/grub-fs-tester.in
+++ b/tests/util/grub-fs-tester.in
@@ -796,7 +796,7 @@ for LOGSECSIZE in $(range "$MINLOGSECSIZE" "$MAXLOGSECSIZE" 
1); do
MOUNTFS=ext2
"mkfs.ext2" -L "$FSLABEL" -q "${MOUNTDEVICE}"  ;;
xf2fs)
-   "mkfs.f2fs" -l "$FSLABEL" -q "${LODEVICES[0]}" ;;
+   "mkfs.f2fs" -l "$FSLABEL" -q "${MOUNTDEVICE}" ;;
xnilfs2)
    "mkfs.nilfs2" -L "$FSLABEL" -b $BLKSIZE  -q 
"${MOUNTDEVICE}" ;;
xext2_old)


Tested-by: Paul Menzel 


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] shim_lock: Enable module for all EFI platforms

[Paul Menzel]

Dear Tianjia,


Thank you for your patch and your reply.


Am 18.09.20 um 07:08 schrieb Tianjia Zhang:


On 9/17/20 10:58 PM, Daniel Kiper wrote:

On Wed, Jul 29, 2020 at 03:11:09PM +0800, Tianjia Zhang wrote:

Like tpm, the module is only enabled for x86_64, but there's nothing
specific to x86_64 in the implementation and can be enabled for all
EFI platforms.

Signed-off-by: Tianjia Zhang 
---
  grub-core/Makefile.core.def | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 166b444c7..b5f47fc41 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -950,7 +950,7 @@ module = {
  module = {
    name = shim_lock;
    common = commands/efi/shim_lock.c;
-  enable = x86_64_efi;
+  enable = efi;


Did you test this with x86 32-bit EFI builds and e.g. ARM64 EFI builds?


It is tested on x86_64-efi and arm64-efi platforms. I don’t have an 
environment for x86 32-bit EFI, and I haven’t tested on this platform.


Please always mention that in the commit message. Please also be 
specific about the device you used (mainboard name, firmware 
name/version and TPM used) and the command you run for the test.


It’d be great if you could test 32-bit EFI with QEMU.


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Quoting issues in Bash script `grub-fs-tester` causes F2FS test failure

[Paul Menzel]

Dear GRUB folks,


Running `sudo env make -e check VERBOSE=yes SUBDIRS=` the F2FS is one of 
the two tests failing. It returns 255.


Running only the specific test

sudo env TESTS=f2fs_test make -e check VERBOSE=yes SUBDIRS=

which runs

sudo ./grub-fs-tester f2fs

and using `set -ex` in `grub-fs-tester` the call below has quoting issues.

xf2fs)
"mkfs.f2fs" -l "$FSLABEL" -q "${LODEVICES[0]}"

fails due to the loop device being passed in single quotes, which does 
not exist with the leading space.


 + LODEVICE=/dev/loop11
 + LODEVICES=' /dev/loop11'

 + mkfs.f2fs -l 
'grub_;/testé䏌䐓䏕киритiurewfceniuewruewnuuireurevueurnievrewfnerfcnevirivinrewvnirewnivrewiuvcrewvnuewvrrrewniuerwreiuviurewiuviurewnuvewnvrenurnunuvrevuurerejiremvreijnvvcreivire 
nverivnreivrevnureiorfnfrvoeoiroireoireoifrefoieroifoirvcreivire 
nverivnreivrevnureiorfnfrvoeoiroireoireoifrefoieroifoircreivire 
nverivnreivrevnureiorfnfrvoeoiroireoireoifrefoieroifoireoifoiq' -q ' 
/dev/loop11'

 FAIL f2fs_test (exit status: 255)

Is there a Bash expert in here, able to fix it?


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Clear background in GNU/Linux (was: Request for a feature)

[Paul Menzel]

Dear Brian,


Am 12.06.20 um 02:33 schrieb Brian Kaye:

I have been able to have grub2 display a background image on my
fedora linux system. It works as long as I don't use secure boot.
After I have my selection the image remains on the screen until the
boot is complete and I see a login screen. Fedora adds a spinner
during this process. What I would like to see is the framebuffer
cleared to black (zeroed??) similar to the code in
gfxterm_background.c
   


if (grub_gfxterm_background.bitmap)
 {
   grub_video_bitmap_destroy (grub_gfxterm_background.bitmap);
   grub_gfxterm_background.bitmap = 0;
   grub_gfxterm_background.blend_text_bg = 0;

   /* Mark whole screen as dirty.  */
   grub_gfxterm_schedule_repaint ();
 }


Just don't know where to put the code and what the real code would be.


I do not fully understand, what you want to accomplish.

But, you can disable ACPI BGRT in the Linux kernel with by adding 
`bgrt_disable` to the Linux command line.


Otherwise, you should probably look into Plymouth, on how to configure 
the background in GNU/Linux [1].


[…]


Kind regards,

Paul


[1]: https://wiki.archlinux.org/index.php/plymouth

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] docs/grub: Fix typo in *preferred*

[Paul Menzel]

---
 docs/grub.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index 8e6f9acec..ba1169487 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4729,7 +4729,7 @@ be reloaded after using this command (@pxref{module}).
 Some kernels have known problems. You need to specify --quirk-* for those.
 --quirk-bad-kludge is a problem seen in several products that they include
 loading kludge information with invalid data in ELF file. GRUB prior to 0.97
-and some custom builds prefered ELF information while 0.97 and GRUB 2
+and some custom builds preferred ELF information while 0.97 and GRUB 2
 use kludge. Use this option to ignore kludge.
 Known affected systems: old Solaris, SkyOS.
 
-- 
2.26.0


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH v2] docs/grub: Fix typo in *preferred*

[Paul Menzel]

Signed-off-by: Paul Menzel 
---
Add Signed-off-by line.

 docs/grub.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index 8e6f9acec..ba1169487 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4729,7 +4729,7 @@ be reloaded after using this command (@pxref{module}).
 Some kernels have known problems. You need to specify --quirk-* for those.
 --quirk-bad-kludge is a problem seen in several products that they include
 loading kludge information with invalid data in ELF file. GRUB prior to 0.97
-and some custom builds prefered ELF information while 0.97 and GRUB 2
+and some custom builds preferred ELF information while 0.97 and GRUB 2
 use kludge. Use this option to ignore kludge.
 Known affected systems: old Solaris, SkyOS.
 
-- 
2.26.0


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCHv2] multiboot2: enable quirk-modules-after-kernel

[Paul Menzel]

70cd1db513e6..8adce7b3489b 100644
--- a/grub-core/loader/multiboot_elfxx.c
+++ b/grub-core/loader/multiboot_elfxx.c
@@ -89,17 +89,18 @@ CONCAT(grub_multiboot_load_elf, XX) (mbi_load_data_t *mld)
  if (phdr(i)->p_type == PT_LOAD)
{
mld->link_base_addr = grub_min (mld->link_base_addr, phdr(i)->p_paddr);
-   highest_load = grub_max (highest_load, phdr(i)->p_paddr + 
phdr(i)->p_memsz);
+   GRUB_MULTIBOOT (highest_load) = grub_max (GRUB_MULTIBOOT (highest_load),
+   phdr(i)->p_paddr + phdr(i)->p_memsz);
}
  
  #ifdef MULTIBOOT_LOAD_ELF64

-  if (highest_load >= 0x1)
+  if (GRUB_MULTIBOOT(highest_load) >= 0x1)
  return grub_error (GRUB_ERR_BAD_OS, "segment crosses 4 GiB border");
  #endif
  
if (mld->relocatable)

  {
-  load_size = highest_load - mld->link_base_addr;
+  load_size = GRUB_MULTIBOOT(highest_load) - mld->link_base_addr;
  
grub_dprintf ("multiboot_loader", "align=0x%lx, preference=0x%x, "

"load_size=0x%x, avoid_efi_boot_services=%d\n",
diff --git a/grub-core/loader/multiboot_mbi2.c 
b/grub-core/loader/multiboot_mbi2.c
index 18e766c7b31c..3883732df531 100644
--- a/grub-core/loader/multiboot_mbi2.c
+++ b/grub-core/loader/multiboot_mbi2.c
@@ -315,8 +315,10 @@ grub_multiboot2_load (grub_file_t file, const char 
*filename)
  grub_free (mld.buffer);
  return err;
}
+
mld.link_base_addr = load_addr;
mld.load_base_addr = get_physical_target_address (ch);
+  grub_multiboot2_highest_load = mld.load_base_addr + code_size;
source = get_virtual_current_address (ch);
  
grub_dprintf ("multiboot_loader", "link_base_addr=0x%x, load_base_addr=0x%x, "

diff --git a/include/grub/multiboot.h b/include/grub/multiboot.h
index bd0a9873e6c1..3d7c5ad29318 100644
--- a/include/grub/multiboot.h
+++ b/include/grub/multiboot.h
@@ -107,6 +107,7 @@ grub_multiboot_load_elf (mbi_load_data_t *mld);
  extern grub_size_t grub_multiboot_pure_size;
  extern grub_size_t grub_multiboot_alloc_mbi;
  extern grub_uint32_t grub_multiboot_payload_eip;
+extern grub_uint64_t grub_multiboot_highest_load;
  
  
  #endif /* ! GRUB_MULTIBOOT_HEADER */

diff --git a/include/grub/multiboot2.h b/include/grub/multiboot2.h
index 502d34ef1804..fa74508afcda 100644
--- a/include/grub/multiboot2.h
+++ b/include/grub/multiboot2.h
@@ -27,6 +27,13 @@
  #include 
  #include 
  
+typedef enum

+  {
+GRUB_MULTIBOOT2_QUIRKS_NONE = 0,
+GRUB_MULTIBOOT2_QUIRK_MODULES_AFTER_KERNEL = 1
+  } grub_multiboot2_quirks_t;
+extern grub_multiboot2_quirks_t grub_multiboot2_quirks;
+
  extern struct grub_relocator *grub_multiboot2_relocator;
  
  void grub_multiboot2 (int argc, char *argv[]);

@@ -99,6 +106,7 @@ grub_multiboot2_load_elf (mbi_load_data_t *mld);
  extern grub_size_t grub_multiboot2_pure_size;
  extern grub_size_t grub_multiboot2_alloc_mbi;
  extern grub_uint32_t grub_multiboot2_payload_eip;
+extern grub_uint64_t grub_multiboot2_highest_load;
  
  
  #endif /* ! GRUB_MULTIBOOT_HEADER */


Does this need to be documented somewhere? (Multiboot 2 does not seem to 
be separately documented in `docs/grub.texi`, so maybe not.


It’d be great if you added a separate second patch on top, adding a 
Multiboot 2 example with this quirk to the documentation.


Please post a v3 patch with the improved commit message, and add the 
line below to it.


Reviewed-by: Paul Menzel 


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Patch to add newer i386 modinfo types

[Paul Menzel]

Dear Eric,


Am 05.04.20 um 03:54 schrieb Eric McCorkle:

Here's a first attempt at a patch that adds the code necessary to pass
the EFI framebuffer info into the FreeBSD kernel.  I have tested this
successfully on real hardware.


Nice. Great work. What hardware (also firmware version) did you test with?

Could you please send the changes as git formatted patches. That way 
they can be easily applied, and there is a commit message. `git 
format-patch` and `git send-email` should do that for you.



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] multiboot2: enable quirk-modules-after-kernel

[Paul Menzel]

Dear Zide,


Thank you very much for your patch.

Am 26.03.20 um 23:46 schrieb Zide Chen:

In multiboot2, currently there is no way to control where to load the
modules. In case of user wants to reserve low address for specific
usage, this quirk is useful.


It’d be great if you elaborated, where the quirk comes from, and how the 
the change can be tested to reproduce your issue.


Lastly, it’d be great to also describe your implementation in the commit 
message, so reviewers can verify that too.


[…]


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Native NVMe driver

[Paul Menzel]

Dear Christian,


Am 31.03.20 um 00:40 schrieb Christian E. Jørgensen:

Am I correct in assuming that GRUB relies on something like a BIOS for
support of NVMe devices? I'm running coreboot with GRUB as the payload
(on amd64 hardware) and GRUB does not seem to detect my NVMe device.

If I use SeaBIOS instead of GRUB as the coreboot payload, then SeaBIOS
detects the NVMe device without issue.


Yes, you are correct. Besides example implementations in SeaBIOS and 
Linux, there is also one for libpayload [1]. It’d be awesome if you gave 
it a shot to implement one.



Kind regards,

Paul


[1]: https://review.coreboot.org/c/coreboot/+/33582

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] version: add a module to get GRUB version

[Paul Menzel]

Dear Flavio,


Thanks a lot for the patch.

Am 30.03.20 um 17:02 schrieb Flavio Suligoi:

Sometimes, writing a custom grub.cfg configuration file,
especially with embedded systems, it is indispensable
to know the version of the running GRUB.
This is essential for every automatic sw update procedure.

Additionaly to the standard GRUB version, I added a


Additionally


supplementary "OEM" version, to keep track of the OEM
custom GRUB version.
For further script test and processing, the version
can be also saved in an environment variable.


I suggest to add one blank line between paragraphs to help legibility.



Command syntax:

grub> help version
Usage: version [OPTIONS]

Print GRUB or GRUB+OEM version.
If --set is specified, the version is set to a variable

-s, --set=VARNAME   Set a variable to return value.
-o, --oem   Add OEM version
-h, --help  Display this help and exit.
-u, --usage Display the usage of this command and exit.
grub>

Signed-off-by: Flavio Suligoi 
---
  Makefile.am  |  2 +-
  docs/grub.texi   |  9 +
  grub-core/Makefile.core.def  |  5 +++
  grub-core/commands/version.c | 93 
  include/oem.h| 25 
  5 files changed, 133 insertions(+), 1 deletion(-)
  create mode 100644 grub-core/commands/version.c
  create mode 100644 include/oem.h

diff --git a/Makefile.am b/Makefile.am
index bf9c1ba..151a437 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -425,7 +425,7 @@ if COND_i386_coreboot
  FS_PAYLOAD_MODULES ?= $(shell cat grub-core/fs.lst)
  default_payload.elf: grub-mkstandalone grub-mkimage FORCE
test -f $@ && rm $@ || true
-   pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci usb_keyboard usbms 
part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs' 
--install-modules='ls linux search configfile normal cbtime cbls memrw iorw 
minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain 
test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu 
$(FS_PAYLOAD_MODULES) password_pbkdf2 $(EXTRA_PAYLOAD_MODULES)' --fonts= 
--themes= --locales= -d grub-core/ /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg
+   pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci usb_keyboard usbms 
part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs' 
--install-modules='ls linux search configfile normal cbtime cbls memrw iorw 
minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain 
test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu 
$(FS_PAYLOAD_MODULES) password_pbkdf2 version $(EXTRA_PAYLOAD_MODULES)' 
--fonts= --themes= --locales= -d grub-core/ 
/boot/grub/grub.cfg=$(srcdir)/coreboot.cfg


Out of curiosity, are you using coreboot based firmware?


  endif
  
  endif

diff --git a/docs/grub.texi b/docs/grub.texi
index 83979af..b9302da 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -4013,6 +4013,7 @@ you forget a command, you can run the command 
@command{help}
  * uppermem::Set the upper memory size
  @comment * vbeinfo:: List available video modes
  * verify_detached:: Verify detached digital signature
+* version:: Show GRUB (or GRUB+OEM) version


I’d add spaces around the + sign.


  * videoinfo::   List available video modes
  @comment * xen_*::  Xen boot commands for AArch64
  * wrmsr::   Write values to model-specific registers
@@ -5374,6 +5375,14 @@ successfully.  If validation fails, it is set to a 
non-zero value.
  @xref{Using digital signatures}, for more information.
  @end deffn
  
+@node version

+@subsection version
+@deffn Command version [@option{--set} var] [@option{--oem}]
+Display GRUB version. If option @option{--oem} is given, display also
+the OEM version.
+If option @option{--set} is give, store the version instead of printing it.


give*n*


+@end deffn
+
  @node videoinfo
  @subsection videoinfo
  
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def

index 48b82e7..357d750 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -2534,3 +2534,8 @@ module = {
common = commands/i386/wrmsr.c;
enable = x86;
  };
+
+module = {
+  name = version;
+  common = commands/version.c;
+};
diff --git a/grub-core/commands/version.c b/grub-core/commands/version.c
new file mode 100644
index 000..07458be
--- /dev/null
+++ b/grub-core/commands/version.c
@@ -0,0 +1,93 @@
+/* version.c - command to print GRUB version and GRUB+OEM version  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2020  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public 

Re: fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

[Paul Menzel]

Dear PGNet Dev,


Thank you for your report.


Am 26.03.20 um 04:50 schrieb PGNet Dev:

building

cd grub
git log | head -n5
commit 552c9fd08122a3036c724ce96dfe68aa2f75705f
Author: Patrick Steinhardt 
Date:   Sat Mar 7 17:29:09 2020 +0100

gnulib: Fix build of base64 when compiling with memory 
debugging

with

gcc --version
gcc (SUSE Linux) 10.0.1 20200324 (experimental) [revision 
75c24a08d697d6442fe6c26142f0559f803af977]

patched

patch -p1 < 
/tmp/grub_patches/grub_patches/0001-mdraid1x_linux-Fix-gcc10-error-Werror-array-bounds.patch
patching file grub-core/disk/mdraid1x_linux.c
patch -p1 < 
/tmp/grub_patches/grub_patches/0002-zfs-Fix-gcc10-error-Werror-zero-length-bounds.patch
patching file grub-core/fs/zfs/zfs.c
patching file include/grub/zfs/zap_leaf.h

from

https://lists.gnu.org/archive/html/grub-devel/2020-03/msg00222.html

config's ok

unset CC CPP
./bootstrap
./autogen.sh
./configure

build FAILs

make V=1

gcc -DHAVE_CONFIG_H -I.  -Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64 
-I./include -DGRUB_FILE=\"grub-core/fs/ntfscomp.c\" -I. -I. -I. -I. -I./include 
-I./include -I./grub-core/lib/libgcrypt-grub/src/  -I./grub-core/lib/minilzo 
-I./grub-core/lib/xzembed -I./grub-core/lib/zstd -DMINILZO_HAVE_CONFIG_H -O3 -Wall 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 
-grecord-gcc-switches -march=native -mtune=native -D_FORTIFY_SOURCE=2 
-D_FILE_OFFSET_BITS=64 -Wall -W -Wshadow -Wpointer-arith -Wundef -Wchar-subscripts 
-Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wfloat-equal 
-Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit 
-Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces 
-Wmissing-format-attribute -Wmultichar -Wparentheses -Wreturn-type -Wsequence-point 
-Wshadow -Wsign-compare -Wswitch -Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function 
-Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable -Wwrite-strings 
-Wnested-externs -Wstrict-prototypes -Wcast-align  -Wextra -Wattributes -Wendif-labels 
-Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmissing-field-initializers -Wnonnull 
-Woverflow -Wvla -Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros 
-Wvolatile-register-var -Wpointer-sign -Wmissing-include-dirs -Wmissing-prototypes 
-Wmissing-declarations -Wformat=2 -Werror  -fno-builtin -Wno-undef -O3 -Wall 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 
-grecord-gcc-switches -march=native -mtune=native -MT 
grub-core/fs/libgrubmods_a-ntfscomp.o -MD -MP -MF 
grub-core/fs/.deps-util/libgrubmods_a-ntfscomp.Tpo -c -o 
grub-core/fs/libgrubmods_a-ntfscomp.o `test -f 'grub-core/fs/ntfscomp.c' || echo 
'./'`grub-core/fs/ntfscomp.c
grub-core/fs/ntfscomp.c: In function ‘read_block’:
grub-core/fs/ntfscomp.c:82:11: error: ‘flg’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
   82 |   if (flg & 0x8000)
  |   ^~~
grub-core/fs/ntfscomp.c:74:17: note: ‘flg’ was declared here
   74 |   grub_uint16_t flg, cnt;
  | ^~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:7647: 
grub-core/fs/libgrubmods_a-ntfscomp.o] Error 1
make[2]: Leaving directory '/usr/local/src/grub'
make[1]: *** [Makefile:11920: all-recursive] Error 1
make[1]: Leaving directory '/usr/local/src/grub'
make: *** [Makefile:3772: all] Error 2


I am unable to reproduce this with

$ gcc --version
gcc (Debian 10-20200324-1) 10.0.1 20200324 (experimental) [master 
revision 596c90d3559:023579257f5:906b3eb9df6c577d3f6e9c3ea5c9d7e4d1e90536]


Here is the code in question:

``
static grub_err_t
decomp_get16 (struct grub_ntfs_comp *cc, grub_uint16_t * res)
{
  grub_uint8_t c1 = 0, c2 = 0;

  if ((decomp_getch (cc, &c1)) || (decomp_getch (cc, &c2)))
return grub_errno;
  *res = ((grub_uint16_t) c2) * 256 + ((grub_uint16_t) c1);
  return 0;
}

[…]
  grub_uint16_t flg, cnt;

  if (decomp_get16 (cc, &flg))
return grub_errno;
  cnt = (flg & 0xFFF) + 1;

  if (dest)
{
  if (flg & 0x8000)
[…]
```

In the code, the `if (decomp_get16 (cc, &flg))` ensures, that `flg` is 
initialized, doesn’t it?


Why is it complaining complaining in line 82 and not 78, where `flg` is 
already accessed?



Kind regards,

Paul
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: disk/mdraid1x_linux.c:181:15: warning: array subscript ...

[Paul Menzel]

Dear PGNet Dev,


Am 25.03.20 um 16:54 schrieb PGNet Dev:

On 3/25/20 8:52 AM, Paul Menzel wrote:

Thanks, but please follow the mailing list netiquette


I was responding to a question asked by a developer in THIS thread


Yes, the question was, if the reported(?) build issues were fixed, and 
you replied to them.


But, you new build error, which I quoted, should be discussed and fixed 
in a separate thread with the correct descriptive subject line.



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: disk/mdraid1x_linux.c:181:15: warning: array subscript ...

[Paul Menzel]

Dear PGNet Dev,


Am 25.03.20 um 16:35 schrieb PGNet Dev:

[…]


with your patches, no immediate mdraid1x or zfs build errors
one does surface, now, for ntfscomp ...


[…]

Thanks, but please follow the mailing list netiquette, and start a new 
discussion thread with a descriptive subject line.



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: grub/head build with pre-release GCC10 ; fail @ "grub-core/disk/mdraid1x_linux.c:181:15: error: ..."

[Paul Menzel]

Dear PGNet Dev,


Already reported and analyzed [1]. It’d be nice, if you could verify 
Thomas’ analysis.



Kind regards,

Paul


[1]: https://lists.gnu.org/archive/html/grub-devel/2020-03/msg00206.html

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] grub.d: Use linuxefi and initrdefi commands if platform is efi

[Paul Menzel]

Dear Tianjia,


Am 23.03.20 um 12:53 schrieb Tianjia Zhang:

When the platform is EFI platform, use 'linuxefi' and 'initrdefi'
commands instead of 'linux' and 'initrd'.

Signed-off-by: Jia Zhang 
Signed-off-by: Tianjia Zhang 
---
  util/grub.d/10_linux.in | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index e8b01c0d0..8c5c3dab7 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -138,10 +138,17 @@ linux_entry ()
  fi
  printf '%s\n' "${prepare_boot_cache}" | sed "s/^/$submenu_indentation/"
fi
+  if [ "@GRUB_PLATFORM@" != "efi" ] ; then
+linux_cmd="linux"
+initrd_cmd="initrd"
+  else
+linux_cmd="linuxefi"
+initrd_cmd="initrdefi"
+  fi
message="$(gettext_printf "Loading Linux %s ..." ${version})"
sed "s/^/$submenu_indentation/" << EOF
echo'$(echo "$message" | grub_quote)'
-   linux   ${rel_dirname}/${basename} 
root=${linux_root_device_thisversion} ro ${args}
+   ${linux_cmd}${rel_dirname}/${basename} 
root=${linux_root_device_thisversion} ro ${args}
  EOF
if test -n "${initrd}" ; then
  # TRANSLATORS: ramdisk isn't identifier. Should be translated.
@@ -152,7 +159,7 @@ EOF
  done
  sed "s/^/$submenu_indentation/" << EOF
echo'$(echo "$message" | grub_quote)'
-   initrd  $(echo $initrd_path)
+   ${initrd_cmd}   $(echo $initrd_path)
  EOF
fi
sed "s/^/$submenu_indentation/" << EOF


What problem does your change address?


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

disk/mdraid1x_linux.c:181:15: warning: array subscript is outside array bounds of ‘grub_uint16_t[0]’ {aka ‘short unsigned int[0]’} [-Warray-bounds]

[Paul Menzel]

Dear GRUB folks,


Using Debian Sid/unstable with

gcc (Debian 10-20200312-2) 10.0.1 20200312 (experimental) [master 
revision c56871dd15a:7ba6e7f0f21:daf2852b883762d921361462dad1f99320faca2a]


building GRUB fails with the error below due to treating warnings as errors.


gcc -DHAVE_CONFIG_H -I. -I..  -Wall -W  -DGRUB_MACHINE_EFI=1 -DGRUB_MACHINE=X86_64_EFI 
-m64 -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/10/include -I../include 
-I../include -DGRUB_FILE=\"disk/mdraid1x_linux.c\" -I. -I. -I.. -I.. 
-I../include -I../include -I../grub-core/lib/libgcrypt-grub/src/
-D_FILE_OFFSET_BITS=64 -Os -m64 -Wall -W -Wshadow -Wpointer-arith -Wundef 
-Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization 
-Wdiv-by-zero -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit 
-Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces 
-Wmissing-format-attribute -Wmultichar -Wparentheses -Wreturn-type -Wsequence-point 
-Wshadow -Wsign-compare -Wswitch -Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function 
-Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable -Wwrite-strings 
-Wnested-externs -Wstrict-prototypes -g -Wredundant-decls -Wmissing-prototypes 
-Wmissing-declarations  -Wextra -Wattributes -Wendif-labels -Winit-self 
-Wint-to-pointer-cast -Winvalid-pch -Wmissing-field-initializers -Wnonnull -Woverflow 
-Wvla -Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros -Wvolatile-register-var 
-Wpointer-sign -Wmissing-include-dirs -Wmissing-prototypes -Wmissing-declarations 
-Wformat=2 -freg-struct-return -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-3dnow 
-msoft-float -fno-dwarf2-cfi-asm -mno-stack-arg-probe -fno-asynchronous-unwind-tables 
-fno-unwind-tables -fno-ident -mcmodel=large -mno-red-zone -fno-PIE -fno-pie 
-fno-stack-protector -Wtrampolines   -ffreestanding   -MT 
disk/mdraid1x_module-mdraid1x_linux.o -MD -MP -MF 
disk/.deps-core/mdraid1x_module-mdraid1x_linux.Tpo -c -o 
disk/mdraid1x_module-mdraid1x_linux.o `test -f 'disk/mdraid1x_linux.c' || echo 
'./'`disk/mdraid1x_linux.c
disk/mdraid1x_linux.c: In function ‘grub_mdraid_detect’:
disk/mdraid1x_linux.c:181:15: warning: array subscript  is outside 
array bounds of ‘grub_uint16_t[0]’ {aka ‘short unsigned int[0]’} [-Warray-bounds]
  181 |  (char *) &sb.dev_roles[grub_le_to_cpu32 (sb.dev_number)]
  |   ^~~
disk/mdraid1x_linux.c:98:17: note: while referencing ‘dev_roles’
   98 |   grub_uint16_t dev_roles[]; /* Role in array, or 0x for a spare, 
or 0xfffe for faulty.  */
  | ^
disk/mdraid1x_linux.c:127:33: note: defined here ‘sb’
  127 |   struct grub_raid_super_1x sb;
  |


Code in question seems to be:

  if (grub_disk_read (disk, sector,
  (char *) &sb.dev_roles[grub_le_to_cpu32 
(sb.dev_number)]

  - (char *) &sb,
  sizeof (role), &role))
return NULL;

Normally, it should be fixed by using `grub_uint16_t[]` instead of 
`grub_uint16_t[0]`, but I haven’t found out where yet.



Kind regards,

Paul
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/2] build: Fix option to explicitly disable memory debugging

[Paul Menzel]

Dear Patrick,


On 2020-03-07 17:29, Patrick Steinhardt wrote:
> The memory management system supports a debug mode that can be enabled
> at build time by passing "--enable-mm-debug" to the configure script.
> Passing the option will cause us define MM_DEBUG as expected, but in
> fact the reverse option "--disable-mm-deubg" will do the exact same

s/deubg/debug/

> thing and also set up the define. This currently causes the build of
> "lib/gnulib/base64.c" to fail as it tries to use `grub_debug_malloc()`
> and `grub_debug_free()` even though both symbols aren't defined.
> 
> Seemingly, `AC_ARG_ENABLE()` will always execute the third argument if
> either the positive or negative option was passed. Let's thus fix the
> issue by moving the call to`AC_DEFINE()` into an explicit `if test
> $xenable_mm_debug` block, similar to how other defines work.
> 
> Signed-off-by: Patrick Steinhardt 
> ---
>  configure.ac | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index f19489418..9eeec2d76 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1448,9 +1448,11 @@ LIBS="$tmp_LIBS"
>  # Memory manager debugging.
>  AC_ARG_ENABLE([mm-debug],
> AS_HELP_STRING([--enable-mm-debug],
> - [include memory manager debugging]),
> -  [AC_DEFINE([MM_DEBUG], [1],
> - [Define to 1 if you enable memory manager 
> debugging.])])
> + [include memory manager debugging]))
> +if test x$enable_mm_debug = xyes; then
> +AC_DEFINE([MM_DEBUG], [1],
> +[Define to 1 if you enable memory manager debugging.])
> +fi
>  
>  AC_ARG_ENABLE([cache-stats],
> AS_HELP_STRING([--enable-cache-stats],

Reviewed-by: Paul Menzel 


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: master fails to create moddep.lst, related to luks2 changes

[Paul Menzel]

Dear Olaf,


On 2020-03-03 09:48, Olaf Hering wrote:
> After upgrade from 
> 4e75b2ae313b13b5bfb54cc5e5c53368d6eb2a08..d5a32255de0e073881980fca0262000c865b30dd
>  I get this compile error:
> 
> env CFLAGS=-Wall CXXFLAGS=-Wall FFLAGS=-Wall ../grub2-src/configure 
> --target=i386-suse-linux --with-platform=pc 
> --prefix=/usr/lib64/grub2-chainloader --disable-boot-time 
> --disable-cache-stats --disable-device-mapper --disable-efiemu 
> --disable-grub-emu-pci --disable-grub-emu-sdl --disable-grub-mkfont 
> --disable-grub-mount --disable-grub-themes --disable-liblzma --disable-libzfs 
> --disable-mm-debug --disable-nls --disable-werror --enable-rpath 
> --with-bootdir=/chainloader/grub2-chainloader --enable-grub-mkfont 
> --enable-grub-themes --with-grubdir=grub2

Please share the commands, how you configured your system?

$ ./bootstrap
$ ./configure

That builds fine in my environment.

> ...
> [  187s] cat kernel_syms.lst > syminfo.lst.new
> [  187s] for m in disk.module trig.module cs5536.moduleusb.module 
> usbserial_common.module usbserial_pl2303.module 
> usbserial_ftdi.module usbserial_usbdebug.module uhci.module   
>  ohci.moduleehci.module pci.modulenativedisk.module   
>   cmostest.module cmosdump.module iorw.module   
> cbtable.module  cbtime.module   cbls.module   cbmemc.module   
> regexp.module acpi.module  lsacpi.module  
>blocklist.module  boot.module cat.module 
> cmp.module configfile.module cpuid.module  date.module 
> drivemap.module echo.module eval.module extcmd.module  
> gptsync.module  halt.module   reboot.module   
>hashsum.module pgp.module verifiers.module  hdparm.module 
> help.module hexdump.module keystatus.module   loadenv.module ls.module 
> lsmmap.module lspci.modulememrw.module minicmd.module parttool.module 
> password.module password_pbkdf2.module play.module   spkmodem.module  
>  morse.module   probe.module read.module search.module 
> search_fs_file.module search_fs_uuid.module search_label.module setpci.module 
>pcidump.modulesleep.module smbios.module
> terminal.module test.module true.module usbtest.module 
> videoinfo.module videotest.module xnu_uuid.module dm_nv.module 
> loopback.module cryptodisk.module json.module afsplitter.module luks.module 
> luks2.module geli.module lvm.module ldm.module mdraid09.module 
> mdraid09_be.module mdraid1x.module diskfilter.module raid5rec.module 
> raid6rec.module scsi.module memdisk.module ata.module ahci.module 
>pata.module biosdisk.module usbms.module  efiemu.module
>   font.module   procfs.module affs.module afs.module 
> bfs.module zstd.module btrfs.module archelp.module cbfs.module cpio.module 
> cpio_be.module newc.module odc.module ext2.module fat.module exfat.module 
> f2fs.module fshelp.module hfs.module hfsplus.module hfspluscomp.module 
> iso9660.module jfs.module minix.module minix2.module minix3.module 
> minix_be.module minix2_be.module minix3_be.module nilfs2.module ntfs.module 
> ntfscomp.module reiserfs.module romfs.module sfs.module squash4.module 
> tar.module udf.module ufs1.module ufs1_be.module ufs2.module xfs.module 
> zfs.module zfscrypt.module zfsinfo.module macbless.module pxe.module 
> gettext.module gfxmenu.module hello.module gzio.module offsetio.module  
> bufio.module   elf.module crypto.module pbkdf2.module 
> relocator.module  datetime.module  
> setjmp.module aout.module   bsd.module   plan9.module linux16.module  
>  ntldr.module truecrypt.module freedos.module pxechain.module 
> multiboot2.module   multiboot.module linux.module 
>   xnu.module random.module macho.module   chain.module
>  mmap.modulenormal.module part_acorn.module 
> part_amiga.module part_apple.module part_gpt.module part_msdos.module 
> part_sun.module part_plan.module part_dvh.module part_bsd.module 
> part_sunpc.module part_dfly.module msdospart.module at_keyboard.module
> gfxterm.module   gfxterm_background.module serial.module  
>   sendkey.module terminfo.moduleusb_keyboard.module   
>   vga.module vga_text.module mda_text.modulevideo_cirrus.module   
> video_bochs.module   functional_test.module exfctest.module 
> strtoull_test.module setjmp_test.module signature_test.module 
> sleep_test.module xnu_uuid_test.module pbkdf2_test.module  
> legacy_password_test.module   div.module div_test.module 
> mul_test.module shift_test.module cmp_test.module ctz_test.module 
> bswap_test.module videotest_checksum.module gfxterm_menu.module 
> cmdline_cat_te

Re: [PATCH 2/2] build: Disable PIE in TARGET_CCASFLAGS if needed

[Paul Menzel]

Dear Matt,


Thank you for upstreaming the patches.

On 2020-02-20 07:51, Matt Turner wrote:
> From: Mike Gilbert 
> 
> PIE should be disabled in assembly sources as well, or else grub will
> fail to boot.

Could you please extend this with the list, on what architectures it
fails to boot? It seems to work on x86, doesn’t it?

> Bug: https://bugs.gentoo.org/667852
> ---
>  configure.ac | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configure.ac b/configure.ac
> index b5e31c787..e2c783652 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1263,6 +1263,7 @@ grub_CHECK_LINK_PIE
>  # `-fPIE' or '-fpie' and '-pie' in the default specs.
>  if [ x"$pie_possible" = xyes ]; then
>TARGET_CFLAGS="$TARGET_CFLAGS -fno-PIE -fno-pie"
> +  TARGET_CCASFLAGS="$TARGET_CCASFLAGS -fno-PIE -fno-pie"
>  fi
>  
>  if [ x"$link_nopie_needed" = xyes ] || [ x"$pie_possible" = xyes ]; then


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Anyone tried hooking up Link Time Optimization (LTO)

[Paul Menzel]

Dear GRUB folks,


Am 24.02.20 um 12:57 schrieb Paul Menzel:

Dear GRUB folks,


Jacob integrated support for LTO (Link Time Optimization) to coreboot [1],
libpayload [2], and the payload *coreinfo* [3] resulting in a noticeable
reduction in the size.

So maybe GRUB would benefit too. Has anyone looked into this already?


Just adding `-flto` to the C flags fails.


$ make CFLAGS="-flto"



cp lib/libgcrypt-grub/cipher/crypto.lst crypto.lst
cat kernel_syms.lst > syminfo.lst.new
for m in disk.module trig.modulecs5536.moduleusb.module 
usbserial_common.module usbserial_pl2303.module 
usbserial_ftdi.module usbserial_usbdebug.module uhci.module 
   ohci.moduleehci.module   pci.module  nativedisk.module   
 cmostest.module cmosdump.module  iorw.module 
cbtime.module   cbls.module   cbmemc.moduleregexp.module   
acpi.module  lsacpi.module   
blocklist.module boot.module  cat.module cmp.module 
configfile.modulecpuid.module   date.module  echo.module eval.module
extcmd.module   gptsync.module halt.module   
reboot.module   hashsum.module pgp.module verifiers.module 
hdparm.module  help.module hexdump.module keystatus.module   loadenv.module 
ls.module lsmmap.modulelspci.module memrw.module minicmd.module 
parttool.module password.module password_pbkdf2.moduleplay.module   
spkmodem.module   morse.moduleprobe.module read.module search.module 
search_fs_file.module search_fs_uuid.module search_label.module
setpci.modulepcidump.module sleep.module   smbios.module  
terminal.module test.module true.moduleusbtest.module  videoinfo.module 
videotest.module xnu_uuid.module dm_nv.module loopback.module cryptodisk.module 
json.module afsplitter.module luks.module luks2.module geli.module lvm.module 
ldm.module mdraid09.module mdraid09_be.module mdraid1x.module diskfilter.module 
raid5rec.module raid6rec.module scsi.module memdisk.moduleata.module
 ahci.modulepata.module usbms.module efiemu.module  
 procfs.module affs.module afs.module bfs.module zstd.module 
btrfs.module archelp.module cbfs.module cpio.module cpio_be.module newc.module 
odc.module ext2.module fat.module exfat.module f2fs.module fshelp.module 
hfs.module hfsplus.module hfspluscomp.module iso9660.module jfs.module 
minix.module minix2.module minix3.module minix_be.module minix2_be.module 
minix3_be.module nilfs2.module ntfs.module ntfscomp.module reiserfs.module 
romfs.module sfs.module squash4.module tar.module udf.module ufs1.module 
ufs1_be.module ufs2.module xfs.module zfs.module zfscrypt.module zfsinfo.module 
macbless.module  gettext.module gfxmenu.module hello.module gzio.module 
offsetio.module elf.module crypto.module pbkdf2.module
relocator.module  datetime.module   setjmp.module   
 aout.module   bsd.module   linux16.module   multiboot2.module  
 multiboot.module linux.module  xnu.module  
   random.module   macho.module chain.module  mmap.module   
  normal.module part_acorn.module part_amiga.module part_apple.module 
part_gpt.module part_msdos.module part_sun.module part_plan.module 
part_dvh.module part_bsd.module part_sunpc.module part_dfly.module 
msdospart.moduleat_keyboard.module
gfxterm_background.moduleserial.moduleterminfo.module   
 usb_keyboard.modulemda_text.module video_cirrus.module   
video_bochs.modulefunctional_test.module exfctest.module 
strtoull_test.module setjmp_test.module signature_test.module sleep_test.module 
xnu_uuid_test.module pbkdf2_test.modulediv.module  
div_test.module mul_test.module shift_test.module cmp_test.module 
ctz_test.module bswap_test.module videotest_checksum.module gfxterm_menu.module 
cmdline_cat_test.module bitmap.module bitmap_scale.module  jpeg.module 
png.module tga.module  
video_colors.module   datehook.module net.module tftp.module http.module
   syslinuxcfg.module test_blockarg.module xzio.module lzopio.module 
testload.modulebacktrace.module  keylayouts.module
priority_queue.module time.module   adler32.module crc64.module mpi.module 
all_video.modulegdb.module   testspeed.module  tr.module progress.module 
file.modulerdmsr.module   wrmsr.modulegcry_arcfour.module 
gcry_blowfish.module gcry_camellia.module gcry_cast5.module gcry_crc.module 
gcry_des.module gcry_dsa.module gcry_idea.module gcry_md4.module 
gcry_md5.module gcry_rfc2268.module gcry_rijndael.module gcry_rmd160.module 
gcry_rsa.module gcr

Anyone tried hooking up Link Time Optimization (LTO)

[Paul Menzel]

Dear GRUB folks,


Jacob integrated support for LTO (Link Time Optimization) to coreboot [1],
libpayload [2], and the payload *coreinfo* [3] resulting in a noticeable
reduction in the size.

So maybe GRUB would benefit too. Has anyone looked into this already?


Kind regards,

Paul


[1]: https://review.coreboot.org/c/coreboot/+/38989
[2]: https://review.coreboot.org/c/coreboot/+/38291
[3]: https://review.coreboot.org/c/coreboot/+/38293



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] docs: Export `superusers` to apply to submenus

[Paul Menzel]

Date: Tue, 10 Dec 2019 12:52:22 +0100
Subject: [PATCH] docs: Export `superusers` to apply to submenus

Signed-off-by: Paul Menzel 
---
 docs/grub.texi | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index c25ab7a5f..615c32d99 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -5715,9 +5715,10 @@ variable must be set to a list of usernames, separated 
by any of spaces,
 commas, semicolons, pipes, or ampersands.  Superusers are permitted to use
 the GRUB command line, edit menu entries, and execute any menu entry.  If
 @samp{superusers} is set, then use of the command line and editing of menu
-entries are automatically restricted to superusers. Setting @samp{superusers}
-to empty string effectively disables both access to CLI and editing of menu
-entries.
+entries are automatically restricted to superusers. Note, the environment
+variable needs to be exported to also affect the section defined by the
+@samp{submenu} command (@pxref{submenu}). Setting @samp{superusers} to empty
+string effectively disables both access to CLI and editing of menu entries.
 
 Other users may be allowed to execute specific menu entries by giving a list of
 usernames (as above) using the @option{--users} option to the
-- 
2.24.0



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Disable CLI in submenu but allow users to access it

[Paul Menzel]

Dear Vladimir,


On 2019-11-29 16:34, Vladimir 'phcoder' Serbinenko wrote:
> On Fri, 29 Nov 2019, 15:17 Paul Menzel,  wrote:

>> Is it possible to allow unprivileged users to access a submenu but
>> not enter the command-line interface?
>>
>> Reading the documentation [1] it’s not clear to me how to do that,
>> and my tests to do that also failed.
>>
>> The warning in [2] also hints that it’s not possible.

[…]

> You need to export variables related to security

Thank you. The line

export superusers

helped indeed.


Kind regards,

Paul


>> [1]: https://www.gnu.org/software/grub/manual/grub/grub.html#Security
>> [2]: 
>> https://philosophos.github.io/articles/20170304~Password-Protection-of-GRUB-Menu/



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Disable CLI in submenu but allow users to access it

[Paul Menzel]

Dear GRUB folks,


Is it possible to allow unprivileged users to access a submenu but
not enter the command-line interface?

Reading the documentation [1] it’s not clear to me how to do that,
and my tests to do that also failed.

The warning in [2] also hints that it’s not possible.

> Warning — Adding --unrestricted to a menu entry with submenuentry
> will allow ANYONE gain superuser authority in the submenuentry ! So
> make sure the --unrestricted option is not used for a menu entry with
> submenuentry, Or add GRUB_DISABLE_SUBMENU=y to /etc/default/grub /
> /etc/sysconfig/grub to disable submenu.


Kind regards,

Paul


[1]: https://www.gnu.org/software/grub/manual/grub/grub.html#Security
[2]: 
https://philosophos.github.io/articles/20170304~Password-Protection-of-GRUB-Menu/



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

error: the initrd is too big

[Paul Menzel]

Dear GRUB folks,


I built Linux 5.4-rc7 with an initrd and additional options
like KASAN selected. When starting the 9.8 MB LZ4 compressed
initrd on a Dell Latitude E7250 with 16 GB RAM GRUB shows:

error: the initrd is too big

UEFI is used and GRUB 2.04 from Debian Sid/unstable.

Any idea, how to debug this?


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] btrfs: disable zstd support for i386-pc

[Paul Menzel]

Dear Michael,


Thank you for your patch.

On 2019-11-05 10:19, Michael Chang wrote:
> The zstd support in btrfs has dependenciy to zstd module and core.img

dependency

> grows its size significantly to 75KB on my system. The resulted image
> cannot be installed into btrfs bootloader area in the size of 64KB and
> eventually fails with following message.
> 
> /usr/sbin/grub-install: warning: your core.img is unusually large.  It won't 
> fit in the embedding area.
> /usr/sbin/grub-install: error: filesystem `btrfs' doesn't support blocklists.
> 
> The patch disabled the zstd support of btrfs in pc-bios platform to

disables (present tense)

Maybe:

So, disable the zstd support of btrfs for the PC BIOS platform to …

> avoid the regression. The resulting size is 56KB, albeit a bit too close
> to the 64KB but works. This is simple workaround until a proper fix

is *a* simple

> landed upstream.

lands

Is there a feature request/bug report for this? Maybe reference it heare?

> Signed-off-by: Michael Chang 
> ---
>  grub-core/fs/btrfs.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
> index 48bd3d04a..8f98892d3 100644
> --- a/grub-core/fs/btrfs.c
> +++ b/grub-core/fs/btrfs.c
> @@ -17,6 +17,7 @@
>   *  along with GRUB.  If not, see .
>   */
>  
> +#ifndef GRUB_MACHINE_PCBIOS
>  /*
>   * Tell zstd to expose functions that aren't part of the stable API, which
>   * aren't safe to use when linking against a dynamic library. We vendor in a
> @@ -24,6 +25,7 @@
>   * functions to provide our own allocator, which uses grub_malloc(), to zstd.
>   */
>  #define ZSTD_STATIC_LINKING_ONLY
> +#endif
>  
>  #include 
>  #include 
> @@ -35,7 +37,9 @@
>  #include 
>  #include 
>  #include 
> +#ifndef GRUB_MACHINE_PCBIOS
>  #include 
> +#endif
>  #include 
>  #include 
>  #include 
> @@ -56,8 +60,10 @@ GRUB_MOD_LICENSE ("GPLv3+");
>  #define GRUB_BTRFS_LZO_BLOCK_MAX_CSIZE (GRUB_BTRFS_LZO_BLOCK_SIZE + \
>(GRUB_BTRFS_LZO_BLOCK_SIZE / 16) + 64 + 3)
>  
> +#ifndef GRUB_MACHINE_PCBIOS
>  #define ZSTD_BTRFS_MAX_WINDOWLOG 17
>  #define ZSTD_BTRFS_MAX_INPUT (1 << ZSTD_BTRFS_MAX_WINDOWLOG)
> +#endif
>  
>  typedef grub_uint8_t grub_btrfs_checksum_t[0x20];
>  typedef grub_uint16_t grub_btrfs_uuid_t[8];
> @@ -229,7 +235,9 @@ struct grub_btrfs_extent_data
>  #define GRUB_BTRFS_COMPRESSION_NONE 0
>  #define GRUB_BTRFS_COMPRESSION_ZLIB 1
>  #define GRUB_BTRFS_COMPRESSION_LZO  2
> +#ifndef GRUB_MACHINE_PCBIOS
>  #define GRUB_BTRFS_COMPRESSION_ZSTD 3
> +#endif
>  
>  #define GRUB_BTRFS_OBJECT_ID_CHUNK 0x100
>  
> @@ -1229,6 +1237,7 @@ grub_btrfs_read_inode (struct grub_btrfs_data *data,
>return grub_btrfs_read_logical (data, elemaddr, inode, sizeof (*inode), 0);
>  }
>  
> +#ifndef GRUB_MACHINE_PCBIOS
>  static void *grub_zstd_malloc (void *state __attribute__((unused)), size_t 
> size)
>  {
>return grub_malloc (size);
> @@ -1318,6 +1327,7 @@ err:
>  
>return ret;
>  }
> +#endif
>  
>  static grub_ssize_t
>  grub_btrfs_lzo_decompress(char *ibuf, grub_size_t isize, grub_off_t off,
> @@ -1494,8 +1504,12 @@ grub_btrfs_extent_read (struct grub_btrfs_data *data,
>  
>if (data->extent->compression != GRUB_BTRFS_COMPRESSION_NONE
> && data->extent->compression != GRUB_BTRFS_COMPRESSION_ZLIB
> +#ifndef GRUB_MACHINE_PCBIOS
> && data->extent->compression != GRUB_BTRFS_COMPRESSION_LZO
> && data->extent->compression != GRUB_BTRFS_COMPRESSION_ZSTD)
> +#else
> +   && data->extent->compression != GRUB_BTRFS_COMPRESSION_LZO)
> +#endif

Why not just guard the ZSTD line by switching the order of LZO and ZSTD for
the closing bracket?

>   {
> grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
> "compression type 0x%x not supported",
> @@ -1535,6 +1549,7 @@ grub_btrfs_extent_read (struct grub_btrfs_data *data,
> != (grub_ssize_t) csize)
>   return -1;
>   }
> +#ifndef GRUB_MACHINE_PCBIOS
> else if (data->extent->compression == GRUB_BTRFS_COMPRESSION_ZSTD)
>   {
> if (grub_btrfs_zstd_decompress (data->extent->inl, data->extsize -
> @@ -1544,6 +1559,7 @@ grub_btrfs_extent_read (struct grub_btrfs_data *data,
> != (grub_ssize_t) csize)
>   return -1;
>   }
> +#endif
> else
>   grub_memcpy (buf, data->extent->inl + extoff, csize);
> break;
> @@ -1581,10 +1597,12 @@ grub_btrfs_extent_read (struct grub_btrfs_data *data,
>   ret = grub_btrfs_lzo_decompress (tmp, zsize, extoff
>   + grub_le_to_cpu64 (data->extent->offset),
>   buf, csize);
> +#ifndef GRUB_MACHINE_PCBIOS
> else if (data->extent->compression == GRUB_BTRFS_COMPRESSION_ZSTD)
>   ret = grub_btrfs_zstd_decompress (tmp, zsize, extoff
>   + grub_le

Re: Patch that fixes an 'at_keyboard' module issue (unreliable key presses)

[Paul Menzel]

Dear Michael,


I am sorry for the late reply.


On 2019-08-29 00:24, Michael Bideau wrote:

> Le mardi 27 août 2019 à 11:57 +0200, Paul Menzel a écrit :

>> On 8/24/19 9:09 PM, Michael Bideau wrote:
>>
>>> This patch fixes an issue that prevented the 'at_keyboard' module
>>> to work (for me).
>>>
>>> The cause is a bad/wrong return value in the function
>>> 'grub_at_keyboard_getkey()' in file 
>>> 'grub-core/term/at_keyboard.c' at line 234.
>>>
>>> / patch /
>>> diff --git a/grub-core/term/at_keyboard.c b/grub-
>>> core/term/at_keyboard.c
>>> index f0a986eb1..597111077 100644
>>> --- a/grub-core/term/at_keyboard.c
>>> +++ b/grub-core/term/at_keyboard.c
>>> @@ -234,7 +234,7 @@ grub_at_keyboard_getkey (struct grub_term_input
>>> *term __attribute__ ((unused)))
>>>  return GRUB_TERM_NO_KEY;
>>>  
>>>if (! KEYBOARD_ISREADY (grub_inb (KEYBOARD_REG_STATUS)))
>>> -return -1;
>>> +return GRUB_TERM_NO_KEY;
>>>at_key = grub_inb (KEYBOARD_REG_DATA);
>>>old_led = ps2_state.led_status;
>>> / end of patch /
>>>
>>>
>>> My symptoms were to have an unresponsive keyboard: keys needed
>>> to be pressed 10x and more to effectively be printed, sometimes
>>> generating multiple key presses (after 1 or 2 sec of no
>>> printing). Very problematic for typing passphrase in early stage
>>> (with GRUB_ENABLE_CRYPTODISK). When switching to 'console'
>>> terminal input, keyboard works perfectly. It also worked great
>>> with grub 2.02 packaged by Debian (2.02+dfsg1- 20). It was not an
>>> output issue, but an input one.
>>
>> […]

>> I think I had a similar issue and tried to fix it in commit d3a3543a
>> (normal/menu: Do not treat error values as key presses) [1], present
>> in GRUB 2.04. Do you have that commit in your tree?
> 
> Yes I have this/your commit in my tree.
> 
> / your patch d3a3543a /
> diff --git a/grub-core/normal/menu.c b/grub-core/normal/menu.c
> index e7a83c2d6..d5e0c79a7 100644
> --- a/grub-core/normal/menu.c
> +++ b/grub-core/normal/menu.c
> @@ -698,7 +698,8 @@ run_menu (grub_menu_t menu, int nested, int *auto_boot)
>  
>c = grub_getkey_noblock ();
>  
> -  if (c != GRUB_TERM_NO_KEY)
> +  /* Negative values are returned on error. */
> +  if ((c != GRUB_TERM_NO_KEY) && (c > 0))
> {
>   if (timeout >= 0)
> {
> / end of your patch d3a3543a /
> 
> For what I understand, your patch seems to "only" address normal/menu
> timeout issue (but I might be wrong, I'm still very new to grub2 code),
> but mine fixes the keyboard (if input is 'at_keyboard') wherever it is
> used in the normal/menu or in the grub terminal/shell or even with the
> cryptomount utility (typing passphrase was my issue at the beginning).
> 
> To be clear, with the last checkout (commit 4e75b2ae3), that includes
> your commit d3a3543a, I have my keyboard not working reliably (as
> described previously), and with my patch it works perfectly (meaning
> in the grub terminal/shell I can type commands seamlessly and even
> use different keyboard layouts).
You are correct. Thank you for the analysis. Could you please create a
“proper” commit with a commit message (most can be taken from your
mail), and send that to this list?

By the way, do you only have this problem on one machine or all? Can it
be reproduced in QEMU?

> PS: there is a typo in my introduction of my patch: it is at the line
> 237 and not 234 as mentioned. Do you think I should answer to my first
> email to say it (so people not reading this sub-thread will know)?

You can fix that in the commit message.

Please ask if you need further help.


Kind regards,

Paul


>> [1]: 
>> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=d3a3543a5666c1dd180ae6027948ca753dcffc18



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Error in docs

[Paul Menzel]

Dear Clayton,


On 2019-08-30 23:03, Clayton Voges wrote:

> I found a type error in grub's manual/document on section 16.3.19. What
> action should I take to fix this?

Please check out the source code, make the change, create the commit, and
send that to this mailing list.


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Patch that fixes an 'at_keyboard' module issue (unreliable key presses)

[Paul Menzel]

Dear Michael,


On 8/24/19 9:09 PM, Michael Bideau wrote:

> This patch fixes an issue that prevented the 'at_keyboard' module to
> work (for me).
> 
> The cause is a bad/wrong return value in the function
> 'grub_at_keyboard_getkey()' in file 
> 'grub-core/term/at_keyboard.c' at line 234.
> 
> 
> / patch /
> diff --git a/grub-core/term/at_keyboard.c b/grub-core/term/at_keyboard.c
> index f0a986eb1..597111077 100644
> --- a/grub-core/term/at_keyboard.c
> +++ b/grub-core/term/at_keyboard.c
> @@ -234,7 +234,7 @@ grub_at_keyboard_getkey (struct grub_term_input *term 
> __attribute__ ((unused)))
>  return GRUB_TERM_NO_KEY;
>  
>if (! KEYBOARD_ISREADY (grub_inb (KEYBOARD_REG_STATUS)))
> -return -1;
> +return GRUB_TERM_NO_KEY;
>at_key = grub_inb (KEYBOARD_REG_DATA);
>old_led = ps2_state.led_status;
> / end of patch /
> 
> 
> My symptoms were to have an unresponsive keyboard: keys needed to be
> pressed 10x and more to
> effectively be printed, sometimes generating multiple key presses
> (after 1 or 2 sec of no printing).
> Very problematic for typing passphrase in early stage (with
> GRUB_ENABLE_CRYPTODISK).
> When switching to 'console' terminal input, keyboard works perfectly.
> It also worked great with grub 2.02 packaged by Debian (2.02+dfsg1-20).
> It was not an output issue, but an input one.

[…]

Welcome, and thank you very much for your contribution.

I think I had a similar issue and tried to fix it in commit d3a3543a
(normal/menu: Do not treat error values as key presses) [1], present in
GRUB 2.04. Do you have that commit in your tree?


Kind regards,

Paul


[1]: 
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=d3a3543a5666c1dd180ae6027948ca753dcffc18



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v7] probe: Support probing for partition UUID with --part-uuid

[Paul Menzel]

Dear Daniel,


On 20.05.19 13:39, Daniel Kiper wrote:

CC-ing Paul.

On Wed, May 15, 2019 at 09:04:43PM +0200, Jacob Kroon wrote:

Linux supports root=PARTUUID= boot argument, so add
support for probing it. Compared to the fs UUID, the partition
UUID does not change when reformatting a partition.

For now, only disks using a GPT partition table are supported.

Signed-off-by: Jacob Kroon 


Reviewed-by: Daniel Kiper 

Paul, is your RB valid for v7?


Yes, it is.


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v6] probe: Support probing for partition UUID with --part-uuid

[Paul Menzel]

Dear Jacob,


On 05/15/2019 07:20 AM, Jacob Kroon wrote:
> Linux supports root=PARTUUID= boot argument, so add
> support for probing it. Compared to the fs UUID, the partition
> UUID does not change when reformatting a partition.
> 
> For now, only disks using a GPT partition table are supported.

Should that be also mentioned in the documentation?

> Signed-off-by: Jacob Kroon 
> ---
>  docs/grub.texi |  2 +-
>  grub-core/commands/probe.c | 34 ++
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> Changes since v5:
>  * Remove short option
>  * partition UUID is not necessarily restricted to GPT, so clarify that
>in the help text and commit message

Thank you very much for going through the reviews so quickly.

This looks good to me, and the support can be extended later on.

Reviewed-by: Paul Menzel 


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v3] probe: Support probing for GPT partition UUID with -q

[Paul Menzel]

Dear Jacob,


On 10.05.19 14:05, Jacob Kroon wrote:

Linux supports root=PARTUUID= boot argument, so add
support for probing it. Compared to the fs UUID, the partition
UUID does not change when reformatting a partition.


How did you choose the switch name `-q`? Are other tools using this 
already, or was it just available?



Signed-off-by: Jacob Kroon 
---
  grub-core/commands/probe.c | 35 +++
  1 file changed, 35 insertions(+)


It’d be awesome if you also updated the documentation/manual 
`docs/grub.texi`.



Changes since v2:

  * Add a proper commit message
  * Handle endianess in the same way as is currently done in
util/grub-probe.c:print_gpt_guid ()

diff --git a/grub-core/commands/probe.c b/grub-core/commands/probe.c
index 95d272287..24742c181 100644
--- a/grub-core/commands/probe.c
+++ b/grub-core/commands/probe.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -45,6 +46,7 @@ static const struct grub_arg_option options[] =
  {"fs",  'f', 0, N_("Determine filesystem type."), 0, 0},
  {"fs-uuid", 'u', 0, N_("Determine filesystem UUID."), 0, 0},
  {"label",   'l', 0, N_("Determine filesystem label."), 0, 0},
+{"partuuid", 'q', 0, N_("Determine GPT partition uuid."), 0, 0},


UUID is capitalized in the string above. Do it her too for consistency?

[…]


Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Detect combined bzImage and UEFI binary

[Paul Menzel]

Dear jame88fane,


On 03/30/19 17:45, jame88f...@gmx.de wrote:

[…]

> I have here a combined bzImage and UEFI binary and wanted to start it with
> the linux/linuxefi command, but unfortunately GRUB2 does not recognize the
> integrated UEFI binary and tries to start the bzImage.
> 
> Could someone build a check for that?
> 
> PS: With the chainloader this is not possible because I want to load extra
> files into RAM with initrd/initrdefi

I probably won’t be able to help you, but can you please send instructions
how to create the problematic binary and how to reproduce your issue with
QEMU.


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH v2] Makefile: Allow to set file systems modules for default_payload.elf

[Paul Menzel]

Dear Daniel,


On 07.03.19 20:37, Daniel Kiper wrote:

On Thu, Mar 07, 2019 at 12:16:06PM +0100, Paul Menzel wrote:

Date: Wed Mar 6 08:14:28 2019 +0100

By default all file system modules are added to the GRUB coreboot
payload `default_payload.elf`. This makes the image quite big,
especially as often not all modules are needed.

Introduce the variable `FS_PAYLOAD_MODULES`, which can be used to
explicitly set file systems modules to be added.

 $ make default_payload.elf
 test -f default_payload.elf && rm default_payload.elf || true
 pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o default_payload.elf --modules='ahci pata ehci uhci ohci 
usb_keyboard usbms part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug 
cbfs' --install-modules='ls linux search configfile normal cbtime cbls memrw 
iorw minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi 
chain test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu affs 
afs bfs btrfs cbfs cpio cpio_be exfat ext2 f2fs fat hfs hfsplus iso9660 jfs 
minix minix2 minix2_be minix3 minix3_be minix_be newc nilfs2 ntfs odc procfs 
reiserfs romfs sfs squash4 tar udf ufs1 ufs1_be ufs2 xfs zfs password_pbkdf2 ' 
--fonts= --themes= --locales= -d grub-core/ /boot/grub/grub.cfg=./coreboot.cfg
 $ ls -l default_payload.elf
 -rw-rw 1 joey joey 1199568 Mar  6 13:58 default_payload.elf

 $ make default_payload.elf FS_PAYLOAD_MODULES="" # ext2 already in 
`--modules`
 test -f default_payload.elf && rm default_payload.elf || true
 pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o default_payload.elf --modules='ahci pata ehci uhci ohci 
usb_keyboard usbms part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug 
cbfs' --install-modules='ls linux search configfile normal cbtime cbls memrw 
iorw minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi 
chain test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu  
password_pbkdf2 ' --fonts= --themes= --locales= -d grub-core/ 
/boot/grub/grub.cfg=./coreboot.cfg
 $ ls -l default_payload.elf
 -rw-rw 1 joey joey 832976 Mar  7 12:13 default_payload.elf

So, the resulting payload size is around 370 kB smaller. (Adding it to
the CBFS, it will be compressed, so the effective size difference will
be smaller.)

Signed-off-by: Paul Menzel 
---
  Makefile.am | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 94296a37e..1f4bb9b8c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -422,9 +422,10 @@ BOOTCHECK_TIMEOUT=180
  bootcheck: $(BOOTCHECKS)

  if COND_i386_coreboot
+FS_PAYLOAD_MODULES ?= $(shell cat grub-core/fs.lst)
  default_payload.elf: grub-mkstandalone grub-mkimage FORCE
test -f $@ && rm $@ || true
-   pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci usb_keyboard usbms 
part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs' 
--install-modules='ls linux search configfile normal cbtime cbls memrw iorw 
minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain 
test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu $(shell cat 
grub-core/fs.lst) password_pbkdf2 $(EXTRA_PAYLOAD_MODULES)' --fonts= --themes= 
--locales= -d grub-core/ /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg


If you do that why not go further and drop...


+   pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage
-O i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci
usb_keyboard usbms part_msdos ext2 fat at_keyboard part_gpt


... ext2, fat...


They are added to the “core image”, so that one has a chance to load 
modules or other files like payloads from these common file systems. I 
suppose, it’s safer to have these included by default.



usbserial_usbdebug cbfs' --install-modules='ls linux search configfile


... and cbfs from here? Does anything depend on these filesystems?


Yes, at least the configuration file `etc/grub.cfg` is stored in CBFS. 
The file is read by the GRUB payload by default. So the module *cbfs* is 
essential for the GRUB payload.



normal cbtime cbls memrw iorw minicmd lsmmap lspci halt reboot hexdump
pcidump regexp setpci lsacpi chain test serial multiboot cbmemc
linux16 gzio echo help syslinuxcfg xnu $(FS_PAYLOAD_MODULES)
password_pbkdf2 $(EXTRA_PAYLOAD_MODULES)' --fonts= --themes=
--locales= -d grub-core/ /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH v2] Makefile: Allow to set file systems modules for default_payload.elf

[Paul Menzel]

Date: Wed Mar 6 08:14:28 2019 +0100

By default all file system modules are added to the GRUB coreboot
payload `default_payload.elf`. This makes the image quite big,
especially as often not all modules are needed.

Introduce the variable `FS_PAYLOAD_MODULES`, which can be used to
explicitly set file systems modules to be added.

$ make default_payload.elf
test -f default_payload.elf && rm default_payload.elf || true
pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o default_payload.elf --modules='ahci pata ehci uhci ohci 
usb_keyboard usbms part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug 
cbfs' --install-modules='ls linux search configfile normal cbtime cbls memrw 
iorw minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi 
chain test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu affs 
afs bfs btrfs cbfs cpio cpio_be exfat ext2 f2fs fat hfs hfsplus iso9660 jfs 
minix minix2 minix2_be minix3 minix3_be minix_be newc nilfs2 ntfs odc procfs 
reiserfs romfs sfs squash4 tar udf ufs1 ufs1_be ufs2 xfs zfs password_pbkdf2 ' 
--fonts= --themes= --locales= -d grub-core/ /boot/grub/grub.cfg=./coreboot.cfg
$ ls -l default_payload.elf
-rw-rw 1 joey joey 1199568 Mar  6 13:58 default_payload.elf

$ make default_payload.elf FS_PAYLOAD_MODULES="" # ext2 already in 
`--modules`
test -f default_payload.elf && rm default_payload.elf || true
pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o default_payload.elf --modules='ahci pata ehci uhci ohci 
usb_keyboard usbms part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug 
cbfs' --install-modules='ls linux search configfile normal cbtime cbls memrw 
iorw minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi 
chain test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu  
password_pbkdf2 ' --fonts= --themes= --locales= -d grub-core/ 
/boot/grub/grub.cfg=./coreboot.cfg
$ ls -l default_payload.elf 
-rw-rw 1 joey joey 832976 Mar  7 12:13 default_payload.elf

So, the resulting payload size is around 370 kB smaller. (Adding it to
the CBFS, it will be compressed, so the effective size difference will
be smaller.)

Signed-off-by: Paul Menzel 
---
 Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 94296a37e..1f4bb9b8c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -422,9 +422,10 @@ BOOTCHECK_TIMEOUT=180
 bootcheck: $(BOOTCHECKS)
 
 if COND_i386_coreboot
+FS_PAYLOAD_MODULES ?= $(shell cat grub-core/fs.lst)
 default_payload.elf: grub-mkstandalone grub-mkimage FORCE
test -f $@ && rm $@ || true
-   pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci usb_keyboard usbms 
part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs' 
--install-modules='ls linux search configfile normal cbtime cbls memrw iorw 
minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain 
test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu $(shell cat 
grub-core/fs.lst) password_pbkdf2 $(EXTRA_PAYLOAD_MODULES)' --fonts= --themes= 
--locales= -d grub-core/ /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg
+   pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci usb_keyboard usbms 
part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs' 
--install-modules='ls linux search configfile normal cbtime cbls memrw iorw 
minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain 
test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu 
$(FS_PAYLOAD_MODULES) password_pbkdf2 $(EXTRA_PAYLOAD_MODULES)' --fonts= 
--themes= --locales= -d grub-core/ /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg
 endif
 
 endif
-- 
2.21.0

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] Makefile: Allow to set file systems modules for default_payload.elf

[Paul Menzel]

Date: Wed, 6 Mar 2019 13:46:05 +0100

By default all file system modules are added to the GRUB coreboot
payload `default_payload.elf`. This makes the image quite big,
especially as often not all modules are needed.

Introduce the variable `FS_PAYLOAD_MODULES`, which can be used to
explicitly set file systems modules to be added.

$ make default_payload.elf
test -f default_payload.elf && rm default_payload.elf || true
pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o default_payload.elf --modules='ahci pata ehci uhci ohci 
usb_keyboard usbms part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug 
cbfs' --install-modules='ls linux search configfile normal cbtime cbls memrw 
iorw minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi 
chain test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu affs 
afs bfs btrfs cbfs cpio cpio_be exfat ext2 f2fs fat hfs hfsplus iso9660 jfs 
minix minix2 minix2_be minix3 minix3_be minix_be newc nilfs2 ntfs odc procfs 
reiserfs romfs sfs squash4 tar udf ufs1 ufs1_be ufs2 xfs zfs password_pbkdf2 ' 
--fonts= --themes= --locales= -d grub-core/ /boot/grub/grub.cfg=./coreboot.cfg
$ ls -l default_payload.elf
-rw-rw 1 joey joey 1199568 Mar  6 13:58 default_payload.elf

$ make default_payload.elf FS_PAYLOAD_MODULES=ext2
test -f default_payload.elf && rm default_payload.elf || true
pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o default_payload.elf --modules='ahci pata ehci uhci ohci 
usb_keyboard usbms part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug 
cbfs' --install-modules='ls linux search configfile normal cbtime cbls memrw 
iorw minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi 
chain test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu ext2 
password_pbkdf2 ' --fonts= --themes= --locales= -d grub-core/ 
/boot/grub/grub.cfg=./coreboot.cfg
$ ls -l default_payload.elf
-rw-rw 1 joey joey 843728 Mar  6 15:20 default_payload.elf

So, the resulting payload size is around 360 kB smaller. (Adding it to
the CBFS, it will be compressed, so the effective size difference will
be smaller.)

Signed-off-by: Paul Menzel 
---
 Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 94296a37e..1f4bb9b8c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -422,9 +422,10 @@ BOOTCHECK_TIMEOUT=180
 bootcheck: $(BOOTCHECKS)
 
 if COND_i386_coreboot
+FS_PAYLOAD_MODULES ?= $(shell cat grub-core/fs.lst)
 default_payload.elf: grub-mkstandalone grub-mkimage FORCE
test -f $@ && rm $@ || true
-   pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci usb_keyboard usbms 
part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs' 
--install-modules='ls linux search configfile normal cbtime cbls memrw iorw 
minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain 
test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu $(shell cat 
grub-core/fs.lst) password_pbkdf2 $(EXTRA_PAYLOAD_MODULES)' --fonts= --themes= 
--locales= -d grub-core/ /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg
+   pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O 
i386-coreboot -o $@ --modules='ahci pata ehci uhci ohci usb_keyboard usbms 
part_msdos ext2 fat at_keyboard part_gpt usbserial_usbdebug cbfs' 
--install-modules='ls linux search configfile normal cbtime cbls memrw iorw 
minicmd lsmmap lspci halt reboot hexdump pcidump regexp setpci lsacpi chain 
test serial multiboot cbmemc linux16 gzio echo help syslinuxcfg xnu 
$(FS_PAYLOAD_MODULES) password_pbkdf2 $(EXTRA_PAYLOAD_MODULES)' --fonts= 
--themes= --locales= -d grub-core/ /boot/grub/grub.cfg=$(srcdir)/coreboot.cfg
 endif
 
 endif
-- 
2.21.0



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add knobs to allow non-initrd boot config

[Paul Menzel]

Dear Daniel,


On 18.02.19 13:58, Daniel Kiper wrote:

On Fri, Feb 15, 2019 at 07:44:55AM -0800, Nick Vinson wrote:



Let me start of by saying that I am a contributor and do not have any
authority to approve or deny patches to GRUB.  That said I do have a few
comments below that I would like for you to consider.


Paul, may I ask you to follow Nick's comments?


Sure, but I’ll two more weeks to give the original authors time to reply 
and distrubtion maintainers to comment.



Kind regards,

Paul

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH 1/1] Add new module msr

[Paul Menzel]

Dear Jesus,


Thank you very much for your contribution.


On 02/16/19 18:29, JesusDF wrote:

> Add a new grub module called msr that registers two commands (rdmsr and wrmsr)
> to be able to read and write to the model-specific registers. It is i386
> specific, as the cpuid module. The name of the module and commands match the
> linux kernel module and intel commands to interact with it.

I moved the description away from the subject line to the body. Please read,
for example, *How to Write a Git Commit Message* [1] and reformat it with
`git commit --amend`.

I believe a Signed-off-by line is also needed. (Use the switch `-s`:
`git commit --amend -s` in this case.)

> ---
>  grub-core/Makefile.core.def   |  10 
>  grub-core/commands/i386/msr.c | 106 ++
>  include/grub/i386/msr.h   |  67 +
>  3 files changed, 183 insertions(+)
>  create mode 100644 grub-core/commands/i386/msr.c
>  create mode 100644 include/grub/i386/msr.h

[…]

Could you please add the appropriate documentation too, and then resend as
v2?


Kind regards,

Paul


[1]: https://chris.beams.io/posts/git-commit/



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] Add knobs to allow non-initrd boot config

[Paul Menzel]

Date: Thu, 10 Nov 2016 13:44:25 -0500

Add GRUB_FORCE_PARTUUID and GRUB_DISABLE_INITRD configuration knobs to allow
users to generate GRUB menu entries booting directly to the kernel, without
using an initramfs.

Signed-off-by: Mathieu Trudel-Lapierre 
[1. Upstream patch from Ubuntu repository
https://code.launchpad.net/ubuntu/+source/grub2
 2. Fix typo s/Then/When/]
Signed-off-by: Paul Menzel 
---
 docs/grub.texi  | 13 +
 util/grub-mkconfig.in   |  4 +++-
 util/grub.d/10_linux.in | 11 +--
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index ecaba9d5c..6520d9f87 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -1522,6 +1522,19 @@ This option may be set to a list of GRUB module names 
separated by spaces.
 Each module will be loaded as early as possible, at the start of
 @file{grub.cfg}.
 
+@item GRUB_FORCE_PARTUUID
+This option forces the root disk entry to be the specified PARTUUID instead
+of whatever would be used instead. This is useful when you control the
+partitioning of the disk but cannot guarantee what the actual hardware will
+be, for example in virtual machine images.
+Setting this option to @samp{12345678-01} will produce:
+root=PARTUUID=12345678-01
+
+@item GRUB_DISABLE_INITRD
+When set to @samp{true}, this option prevents an initrd to be used at boot
+time, regardless of whether one is detected or not. @command{grub-mkconfig}
+will therefore not generate any initrd lines.
+
 @end table
 
 The following options are still accepted for compatibility with existing
diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index 2360e..265cf959b 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -238,7 +238,9 @@ export GRUB_DEFAULT \
   GRUB_ENABLE_CRYPTODISK \
   GRUB_BADRAM \
   GRUB_OS_PROBER_SKIP_LIST \
-  GRUB_DISABLE_SUBMENU
+  GRUB_DISABLE_SUBMENU \
+  GRUB_FORCE_PARTUUID \
+  GRUB_DISABLE_INITRD
 
 if test "x${grub_cfg}" != "x"; then
   rm -f "${grub_cfg}.new"
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index 4532266be..d4498f106 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -139,11 +139,18 @@ linux_entry ()
 printf '%s\n' "${prepare_boot_cache}" | sed "s/^/$submenu_indentation/"
   fi
   message="$(gettext_printf "Loading Linux %s ..." ${version})"
-  sed "s/^/$submenu_indentation/" << EOF
+  if [ x"$GRUB_FORCE_PARTUUID" = x ]; then
+sed "s/^/$submenu_indentation/" << EOF
echo'$(echo "$message" | grub_quote)'
linux   ${rel_dirname}/${basename} 
root=${linux_root_device_thisversion} ro ${args}
 EOF
-  if test -n "${initrd}" ; then
+  else
+sed "s/^/$submenu_indentation/" << EOF
+   echo'$(echo "$message" | grub_quote)'
+   linux   ${rel_dirname}/${basename} 
root=$PARTUUID=${GRUB_FORCE_PARTUUID} ro ${args}
+EOF
+  fi
+  if test -n "${initrd}" && [ x"$GRUB_DISABLE_INITRD" != xtrue ]; then
 # TRANSLATORS: ramdisk isn't identifier. Should be translated.
 message="$(gettext_printf "Loading initial ramdisk ...")"
 initrd_path=
-- 
2.20.0



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Add travis-ci config file

[Paul Menzel]

Dear Alexander,


On 02/12/19 18:00, Alexander Graf wrote:
> There is a really convenient service for open source project from Travis
> CI: They allow for free CI testing using their infrastructure.
> 
> Grub has had issues with broken builds for various targets for a long time
> already. The main reason is a lack of CI to just do smoke tests on whether
> all targets still at least compile.
> 
> This patch adds a travis config file which builds (almost) all currently
> available targets.
> 
> On top of that, this travis config also runs a small execution test on the
> x86_64-efi target.
> 
> All of this config file can easily be extended further on. It probably makes
> sense to do something similar to the u-boot test infrastructure that
> communicates with the payload properly. Going forward, we also will want to
> do more qemu runtime checks for other targets.
> 
> Currently, with this config alone, I already see about half of the available
> targets as broken. So it's definitely desperately needed :).

Thank you very much for this patch. Could you please post the URL where the
test results are available for the run you did?

There is one small typo further down.

> Signed-off-by: Alexander Graf 
> ---
>  .travis.yml | 118 
> 
>  1 file changed, 118 insertions(+)
>  create mode 100644 .travis.yml
> 
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index 0..05608fc21
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,118 @@

[…]

> +before_script:
> +  # install toolchains based on TOOLCHAIN} variable

Remove the bracket }?

> +  - mkdir /tmp/cross
> +  # results in binaries like 
> /tmp/cross/gcc-8.1.0-nolibc/ia64-linux/bin/ia64-linux-gcc
> +  - for i in $CROSS_TARGETS; do
> +( cd /tmp/cross; wget -O - 
> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-$i.tar.xz
>  | xzcat | tar x );
> +done

[…]


Thanks,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

clang 7.0.1 build fails with `error: argument unused during compilation: '-Qn'`

[Paul Menzel]

Dear GRUB folks,


Building GRUB from the master branch fails with clang 7.0.1 fails
with the error below. The error is not shown with clang 6.0.1.

```
$ ./autogen.sh
$ ./configure CC=clang
$ make -j`nproc`
[…]
clang -DHAVE_CONFIG_H -I. -I..  -Wall -W  -DGRUB_MACHINE_PCBIOS=1 
-DGRUB_MACHINE=I386_PC -m32 -msoft-float -Xclang -msoft-float -Xclang 
-no-implicit-float -nostdinc -isystem /usr/lib/clang/7.0.1/include -I../include 
-I../include -DGRUB_FILE=\"bus/cs5536.c\" -I. -I. -I.. -I.. -I../include 
-I../include -I../grub-core/lib/libgcrypt-grub/src/-D_FILE_OFFSET_BITS=64 
-Os -Wall -W -Wshadow -Wpointer-arith -Wundef -Wchar-subscripts -Wcomment 
-Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wfloat-equal 
-Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit 
-Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces 
-Wmissing-format-attribute -Wmultichar -Wparentheses -Wreturn-type 
-Wsequence-point -Wshadow -Wsign-compare -Wswitch -Wtrigraphs -Wunknown-pragmas 
-Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value  
-Wunused-variable -Wwrite-strings -Wnested-externs -Wstrict-prototypes -g 
-Wredundant-decls -Wmissing-prototypes -Wmissing-declarations  -Wextra 
-Wattributes -Wendif-labels -Winit-self -Wint-to-pointer-cast -Winvalid-pch 
-Wmissing-field-initializers -Wnonnull -Woverflow -Wvla -Wpointer-to-int-cast 
-Wstrict-aliasing -Wvariadic-macros -Wvolatile-register-var -Wpointer-sign 
-Wmissing-include-dirs -Wmissing-prototypes -Wmissing-declarations -Wformat=2 
-march=i386 -m32 -malign-jumps=1 -malign-loops=1 -malign-functions=1 
-freg-struct-return -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-3dnow 
-fno-dwarf2-cfi-asm -mno-stack-arg-probe -fno-asynchronous-unwind-tables 
-fno-unwind-tables -Qn -fno-stack-protector -Werror   -ffreestanding   -MT 
bus/cs5536_module-cs5536.o -MD -MP -MF bus/.deps-core/cs5536_module-cs5536.Tpo 
-c -o bus/cs5536_module-cs5536.o `test -f 'bus/cs5536.c' || echo 
'./'`bus/cs5536.c
clang-7grep 'MARKER' gcry_twofish.marker.new > gcry_twofish.marker; rm -f 
gcry_twofish.marker.new
: error: argument unused during compilation: '-Qn' 
[-Werror,-Wunused-command-line-argument]
make[3]: *** [Makefile:28232: trig.module] Error 1
```


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel