If grub_calloc() fails hist_lines becomes NULL. It means we loose the
reference to the previously allocated hist_lines and leak memory. With
this change on failure hist_lines still points to the old memory. So,
no leak, no state corruption.
Signed-off-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When the normal module is loaded, the normal and normal_exit commands
are registered but aren't unregistered when the module is unloaded. We
need to add calls to grub_unregister_command() when unloading the module
for these commands.
Fixes: CVE-2025-61663
Fixes: CVE-2025-61664
Reported-by: Alec Brown <alec.r.brown@oracle.com>
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds a NULL check after grub_malloc() call. Missing a failure
check after calling grub_malloc() can lead to undefined behavior. If the
allocation fails and returns NULL subsequent dereferencing or writing to
the pointer will likely result in a runtime error such as a segmentation
fault.
Signed-off-by: Avnish Chouhan <avnish@linux.ibm.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The --hw-accel option has been added to cryptomount to speed up
decryption by temporarily enabling hardware-specific instruction
sets (e.g., AVX, SSE) in libgcrypt.
A new feature, "feature_gcry_hw_accel", is also introduced to mark the
availability of the new option.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To prevent a sealed key from being unsealed again, a common and
straightforward method is to "cap" the key by extending the associated
PCRs. When the PCRs associated with the sealed key are extended, TPM will
be unable to unseal the key, as the PCR values required for unsealing no
longer match, effectively rendering the key unusable until the next
system boot or a state where the PCRs are reset to their expected values.
To cap a specific set of PCRs, simply append the argument '-c pcr_list'
to the tpm2_key_protector command. Upon successfully unsealing the key,
the TPM2 key protector will then invoke tpm2_protector_cap_pcrs(). This
function extends the selected PCRs with an EV_SEPARATOR event,
effectively "capping" them. Consequently, the associated key cannot be
unsealed in any subsequent attempts until these PCRs are reset to their
original, pre-capped state, typically occurring upon the next system
boot.
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The BootLoaderSpec (BLS) defines a scheme where different bootloaders can
share a format for boot items and a configuration directory that accepts
these common configurations as drop-in files.
The BLS Specification: https://uapi-group.org/specifications/specs/boot_loader_specification/
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Will Thompson <wjt@endlessm.com>
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In bidi_line_wrap(), "kk - 1" in the for loop init, "i = kk - 1",
underflows when "kk" (unsigned int) is 0. Assigning the result of
"kk - 1" to signed int "i" may cause overflow. To address both
issues, cast "kk" to a signed type before subtraction to ensure
safe arithmetic and assignment.
Fixed: CID 473874
Signed-off-by: Lidong Chen <lidong.chen@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
This allows users to restrict the "search" command's scope to
encrypted disks only.
Typically, this command is used to "rebase" $root and $prefix
before loading additional configuration files via "source" or
"configfile". Unfortunately, this leads to security problems,
like CVE-2023-4001, when an unexpected, attacker-controlled
device is chosen by the "search" command.
The --cryptodisk-only argument allows users to ensure that the
file system picked is encrypted.
This feature supports the CLI authentication, blocking bypass
attempts.
Signed-off-by: Maxim Suhanov <dfirblog@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The Coverity indicates that the variable current_entry might overflow.
To prevent this use safe math when adding GRUB_MENU_PAGE_SIZE to current_entry.
On the occasion fix limiting condition which was broken.
Fixes: CID 473853
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The normal module does not entirely cleanup after itself in
its GRUB_MOD_FINI() leaving a few variables hooks in place.
It is not possible to unload normal module now but fix the
issues for completeness.
On the occasion replace 0s with NULLs for "pager" variable
hooks unregister.
Fixes: CVE-2025-0622
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The function included a call to grub_strcpy() which copied data from an
environment variable to a buffer allocated in grub_cmd_normal(). The
grub_cmd_normal() didn't consider the length of the environment variable.
So, the copy operation could exceed the allocation and lead to an OOB
write. Fix the issue by replacing grub_strcpy() with grub_strlcpy() and
pass the underlying buffers size to the grub_net_search_config_file().
Fixes: CVE-2025-0624
Reported-by: B Horn <b@horn.uk>
Signed-off-by: B Horn <b@horn.uk>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The GRUB may use TPM to verify the integrity of boot components and the
result can determine whether a previously sealed key can be released. If
everything checks out, showing nothing has been tampered with, the key
is released and GRUB unlocks the encrypted root partition for the next
stage of booting.
However, the liberal Command Line Interface (CLI) can be misused by
anyone in this case to access files in the encrypted partition one way
or another. Despite efforts to keep the CLI secure by preventing utility
command output from leaking file content, many techniques in the wild
could still be used to exploit the CLI, enabling attacks or learning
methods to attack. It's nearly impossible to account for all scenarios
where a hack could be applied.
Therefore, to mitigate potential misuse of the CLI after the root device
has been successfully unlocked via TPM, the user should be required to
authenticate using the LUKS password. This added layer of security
ensures that only authorized users can access the CLI reducing the risk
of exploitation or unauthorized access to the encrypted partition.
Fixes: CVE-2024-49504
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A regression in GRUB 2.12 causes the GRUB screen to become cluttered
with artifacts from the previous screen whether it's the UEFI post UI,
UEFI shell or any graphical UI running before GRUB. This issue occurs
in situations like booting GRUB from the UEFI shell and going straight
to the rescue or command shell causing visual discomfort.
The regression was introduced by commit 2d7c3abd8 (efi/console: Do not
set text-mode until it is actually needed). To address the screen
flickering issue this commit suppresses the text-mode setting until the
first output is requested. Before text-mode is set any attempt to clear
the screen has no effect. This inactive period renders the clear screen
ineffective in early boot stages, potentially leaving leftover artifacts
that will clutter the GRUB console display, as there is no guarantee
there will always be a clear screen after the first output.
The issue is fixed by ensuring grub_console_cls() to work through lazy
mode-setting, while also avoiding screen clearing for the hidden menu
which the flicker-free patch aims to improve.
Fixes: 2d7c3abd8 (efi/console: Do not set text-mode until we actually need it)
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add functionality to disable command line interface access and editing of GRUB
menu entries if GRUB image is built with --disable-cli.
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
An unchecked decrement operation in cl_print() would cause a few
integers to underflow. Where an output terminal's state is stored in
cl_term, the values cl_term->ystart and cl_term->pos.y both underflow.
This can be replicated with the following steps:
1. Get to the GRUB command line
2. Hold down the "d" key (or any key that enters a visible character)
until it fills the entire row
3. Press "HOME" and then press "CTRL-k". This will clear every
character entered in step 2
4. Continuously press "CTRL-y" until the terminal scrolls the original
prompt ("grub> ") passed the terminal's top row. Now, no prompt
should be visible. This step causes cl_term->ystart to underflow
5. Press "HOME" and then "d" (or any visible character). This can have
different visual effects for different systems, but it will always
cause cl_term->pos.y to underflow
On BIOS systems, these underflows cause the output terminal to
completely stop displaying anything. Characters can still be
entered and commands can be run, but nothing will display on the
terminal. From here, you can only get the display working by running
a command to switch the current output terminal to a different type:
terminal_output <OTHER_TERMINAL>
On UEFI systems, these replication steps do not break the output
terminal. Until you press "ENTER", the cursor stops responding to input,
but you can press "ENTER" after step 5 and the command line will
work properly again. This patch is mostly important for BIOS systems
where the output terminal is rendered unusable after the underflows
occur.
This patch adds two checks, one for each variable. It ensures that
cl_term->ystart does not decrement passed 0. It also ensures that
cl_term->pos.y does not get set passed the terminal's bottom row.
When the previously listed replication steps are followed with this
patch, the terminal's cursor will be set to the top row and the command
line is still usable, even on BIOS systems.
Signed-off-by: Ryan Cohen <rcohenprogramming@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The out->ncomb is a bit-field of 8 bits. So, the max possible value is 255.
However, code in grub_unicode_aglomerate_comb() doesn't check for an
overflow when incrementing out->ncomb. If out->ncomb is already 255,
after incrementing it will get 0 instead of 256, and cause illegal
memory access in subsequent processing.
This patch introduces GRUB_UNICODE_NCOMB_MAX to represent the max
acceptable value of ncomb. The code now checks for this limit and
ignores additional combining characters when limit is reached.
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Zhang Boyang <zhangboyang.id@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is not an ideal solution, as interactive users must always run
a command in order to get the behavior they want, but it avoids
problematic interactions between prompting and sourcing files.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is useful on cloud instances with remote serial ports as it can be
difficult to connect "fast enough" to get the initial menu display
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In some cases attempting to display arbitrary binary strings leads
to ASAN splats reading the widthspec array out of bounds.
Check the index. If it would be out of bounds, return a width of 1.
I don't know if that's strictly correct, but we're not really expecting
great display of arbitrary binary data, and it's certainly not worse than
an OOB read.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When the user has asked the menu code to be hidden/quiet and the current
entry is being autobooted because the timeout has expired don't show
the "Booting `%s'" msg.
This is necessary to let flicker-free boots really be flicker free,
otherwise the "Booting `%s'" msg will kick the EFI fb into text mode
and show the msg, breaking the flicker-free experience.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Some filesystems nowadays use 64-bit types for timestamps. So, update
grub_dirhook_info struct to use an grub_int64_t type to store mtime.
This also updates the grub_unixtime2datetime() function to receive
a 64-bit timestamp argument and do 64-bit-safe divisions.
All the remaining conversion from 32-bit to 64-bit should be safe, as
32-bit to 64-bit attributions will be implicitly casted. The most
critical part in the 32-bit to 64-bit conversion is in the function
grub_unixtime2datetime() where it needs to deal with the 64-bit type.
So, for that, the grub_divmod64() helper has been used.
These changes enables the GRUB to support dates beyond y2038.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
It is possible for the code to reach the end of the function without
freeing the memory allocated to argv and argc still to be 0.
We should always call grub_free(argv). The grub_free() will handle
a NULL argument correctly if it reaches that code without the memory
being allocated.
Fixes: CID 96672
Signed-off-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The function grub_disk_get_size() is confusingly named because it actually
returns a sector count where the sectors are sized in the GRUB native sector
size. Rename to something more appropriate.
Suggested-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This attempts to fix the places where we do the following where
arithmetic_expr may include unvalidated data:
X = grub_malloc(arithmetic_expr);
It accomplishes this by doing the arithmetic ahead of time using grub_add(),
grub_sub(), grub_mul() and testing for overflow before proceeding.
Among other issues, this fixes:
- allocation of integer overflow in grub_video_bitmap_create()
reported by Chris Coulson,
- allocation of integer overflow in grub_png_decode_image_header()
reported by Chris Coulson,
- allocation of integer overflow in grub_squash_read_symlink()
reported by Chris Coulson,
- allocation of integer overflow in grub_ext2_read_symlink()
reported by Chris Coulson,
- allocation of integer overflow in read_section_as_string()
reported by Chris Coulson.
Fixes: CVE-2020-14309, CVE-2020-14310, CVE-2020-14311
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This modifies most of the places we do some form of:
X = malloc(Y * Z);
to use calloc(Y, Z) instead.
Among other issues, this fixes:
- allocation of integer overflow in grub_png_decode_image_header()
reported by Chris Coulson,
- allocation of integer overflow in luks_recover_key()
reported by Chris Coulson,
- allocation of integer overflow in grub_lvm_detect()
reported by Chris Coulson.
Fixes: CVE-2020-14308
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On some devices the ESC key is the hotkey to enter the BIOS/EFI setup
screen, making it really hard to time pressing it right. Besides that
ESC is also pretty hard to discover for a user who does not know it
will unhide the menu.
This commit makes F4, which was chosen because is not used as a hotkey
to enter the BIOS setup by any vendor, also interrupt sleeps / stop the
menu countdown.
This solves the ESC gets into the BIOS setup and also somewhat solves
the discoverability issue, but leaves the timing issue unresolved.
This commit fixes the timing issue by also adding support for keeping
SHIFT pressed during boot to stop the menu countdown. This matches
what Ubuntu is doing, which should also help with discoverability.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Coverity Scan reports that the grub_strrchr() function can return NULL if
the character is not found. Check if that's the case for dirfile pointer.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently the string functions grub_strtol(), grub_strtoul(), and
grub_strtoull() don't declare the "end" pointer in such a way as to
require the pointer itself or the character array to be immutable to the
implementation, nor does the C standard do so in its similar functions,
though it does require us not to change any of it.
The typical declarations of these functions follow this pattern:
long
strtol(const char * restrict nptr, char ** restrict endptr, int base);
Much of the reason for this is historic, and a discussion of that
follows below, after the explanation of this change. (GRUB currently
does not include the "restrict" qualifiers, and we name the arguments a
bit differently.)
The implementation is semantically required to treat the character array
as immutable, but such accidental modifications aren't stopped by the
compiler, and the semantics for both the callers and the implementation
of these functions are sometimes also helped by adding that requirement.
This patch changes these declarations to follow this pattern instead:
long
strtol(const char * restrict nptr,
const char ** const restrict endptr,
int base);
This means that if any modification to these functions accidentally
introduces either an errant modification to the underlying character
array, or an accidental assignment to endptr rather than *endptr, the
compiler should generate an error. (The two uses of "restrict" in this
case basically mean strtol() isn't allowed to modify the character array
by going through *endptr, and endptr isn't allowed to point inside the
array.)
It also means the typical use case changes to:
char *s = ...;
const char *end;
long l;
l = strtol(s, &end, 10);
Or even:
const char *p = str;
while (p && *p) {
long l = strtol(p, &p, 10);
...
}
This fixes 26 places where we discard our attempts at treating the data
safely by doing:
const char *p = str;
long l;
l = strtol(p, (char **)&ptr, 10);
It also adds 5 places where we do:
char *p = str;
while (p && *p) {
long l = strtol(p, (const char ** const)&p, 10);
...
/* more calls that need p not to be pointer-to-const */
}
While moderately distasteful, this is a better problem to have.
With one minor exception, I have tested that all of this compiles
without relevant warnings or errors, and that /much/ of it behaves
correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception
is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea
how to build.
Because the C standard defined type-qualifiers in a way that can be
confusing, in the past there's been a slow but fairly regular stream of
churn within our patches, which add and remove the const qualifier in many
of the users of these functions. This change should help avoid that in
the future, and in order to help ensure this, I've added an explanation
in misc.h so that when someone does get a compiler warning about a type
error, they have the fix at hand.
The reason we don't have "const" in these calls in the standard is
purely anachronistic: C78 (de facto) did not have type qualifiers in the
syntax, and the "const" type qualifier was added for C89 (I think; it
may have been later). strtol() appears to date from 4.3BSD in 1986,
which means it could not be added to those functions in the standard
without breaking compatibility, which is usually avoided.
The syntax chosen for type qualifiers is what has led to the churn
regarding usage of const, and is especially confusing on string
functions due to the lack of a string type. Quoting from C99, the
syntax is:
declarator:
pointer[opt] direct-declarator
direct-declarator:
identifier
( declarator )
direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ]
...
direct-declarator [ type-qualifier-list[opt] * ]
...
pointer:
* type-qualifier-list[opt]
* type-qualifier-list[opt] pointer
type-qualifier-list:
type-qualifier
type-qualifier-list type-qualifier
...
type-qualifier:
const
restrict
volatile
So the examples go like:
const char foo; // immutable object
const char *foo; // mutable pointer to object
char * const foo; // immutable pointer to mutable object
const char * const foo; // immutable pointer to immutable object
const char const * const foo; // XXX extra const keyword in the middle
const char * const * const foo; // immutable pointer to immutable
// pointer to immutable object
const char ** const foo; // immutable pointer to mutable pointer
// to immutable object
Making const left-associative for * and right-associative for everything
else may not have been the best choice ever, but here we are, and the
inevitable result is people using trying to use const (as they should!),
putting it at the wrong place, fighting with the compiler for a bit, and
then either removing it or typecasting something in a bad way. I won't
go into describing restrict, but its syntax has exactly the same issue
as with const.
Anyway, the last example above actually represents the *behavior* that's
required of strtol()-like functions, so that's our choice for the "end"
pointer.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch implements a search for a specific configuration when the config
file is on a remoteserver. It uses the following order:
1) DHCP client UUID option.
2) MAC address (in lower case hexadecimal with dash separators);
3) IP (in upper case hexadecimal) or IPv6;
4) The original grub.cfg file.
This procedure is similar to what is used by pxelinux and yaboot:
http://www.syslinux.org/wiki/index.php/PXELINUX#config
It is enabled by default but can be disabled by setting the environment
variable "feature_net_search_cfg" to "n" in an embedded configuration.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=873406
Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@br.ibm.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The common datetime helper functions are currently included in the normal
module, but this makes any other module that calls these functions to have
a dependency with the normal module only for this reason.
Since the normal module does a lot of stuff, it calls functions from other
modules. But since other modules may depend on it for calling the datetime
helpers, this could lead to circular dependencies between modules.
As an example, when platform == xen the grub_get_datetime() function from
the datetime module calls to the grub_unixtime2datetime() helper function
from the normal module. Which leads to the following module dependency:
datetime -> normal
and send_dhcp_packet() from the net module calls the grub_get_datetime()
function, which leads to the following module dependency:
net -> datetime -> normal
but that means that the normal module is not allowed to depend on net or
any other module that depends on it due the transitive dependency caused
by datetime. A recent patch attempted to add support to fetch the config
file over the network, which leads to the following circular dependency:
normal -> net -> datetime -> normal
So having the datetime helpers in the normal module makes it quite fragile
and easy to add circular dependencies like these, that break the build due
the genmoddep.awk script catching the issues.
Fix this by taking the datetime helper functions out of the normal module
and instead add them to the datetime module itself. Besides fixing these
issues, it makes more sense to have these helper functions there anyways.
Reported-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Some terminals, like `grub-core/term/at_keyboard.c`, return `-1` in case
they are not ready yet.
if (! KEYBOARD_ISREADY (grub_inb (KEYBOARD_REG_STATUS)))
return -1;
Currently, that is treated as a key press, and the menu time-out is
cancelled/cleared. This is unwanted, as the boot is stopped and the user
manually has to select a menu entry. Therefore, adapt the condition to
require the key value also to be greater than 0.
`GRUB_TERM_NO_KEY` is defined as 0, so the condition could be collapsed
to greater or equal than (≥) 0, but the compiler will probably do that
for us anyway, so keep the cases separate for clarity.
This is tested with coreboot, the GRUB default payload, and the
configuration file `grub.cfg` below.
For GRUB:
$ ./autogen.sh
$ ./configure --with-platform=coreboot
$ make -j`nproc`
$ make default_payload.elf
For coreboot:
$ more grub.cfg
serial --unit 0 --speed 115200
set timeout=5
menuentry 'halt' {
halt
}
$ build/cbfstool build/coreboot.rom add-payload \
-f /dev/shm/grub/default_payload.elf -n fallback/payload -c lzma
$ build/cbfstool build/coreboot.rom add -f grub.cfg -n etc/grub.cfg -t raw
$ qemu-system-x86_64 --version
QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-2+b1)
Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
$ qemu-system-x86_64 -M pc -bios build/coreboot.rom -serial stdio -nic none
Currently, the time-out is cancelled/cleared. With the commit, it is not.
With a small GRUB payload, this the problem is also reproducible on the
ASRock E350M1.
Link: http://lists.gnu.org/archive/html/grub-devel/2019-01/msg00037.html
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Let's provide file type info to the I/O layer. This way verifiers
framework and its users will be able to differentiate files and verify
only required ones.
This is preparatory patch.
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ross Philipson <ross.philipson@oracle.com>
When running grub in a VGA console of a KVM pseries guest on PowerPC,
you can see the cursor sweeping over the whole line when entering a
character in editor mode. This is visible because grub always refreshes
the whole line when entering a character in editor mode, and drawing
characters is quite a slow operation with the firmware used for the
powerpc pseries guests (SLOF).
To avoid this ugliness, the cursor should be disabled when refreshing
the screen contents during update_screen().
Signed-off-by: Thomas Huth <thuth@redhat.com>
