From: Andrey Borzenkov <arvidjaar@gmail.com>
To: grub-devel@gnu.org
Subject: [PATCH] trivial fixes for windows-efi branch
Date: Sun, 15 Dec 2013 12:04:12 +0400 [thread overview]
Message-ID: <1387094652-14021-1-git-send-email-arvidjaar@gmail.com> (raw)
Background - I have pending rewrite for Linux to directly use sysfs
instead of relying on efibootmgr. This should fix long standing bug
where grub-install may delete wrong boot entry due to fuzzy matching.
So I just tried to rebase it on top of this branch. I think we could
reuse part of code that builds EFI device path; everything else is probably
too different.
Below fixes for problems I hit when testing it.
==
1. Check for errors when reading Boot* variables
2. Fix core dump when variable name was not found (it tried to compare
null pointer)
Both are likely related to signed vs. unsigned comaprison mismatch where
negative values are treated as large positive.
3. Prefer minimal free boot number found, not highest one.
4. Fix length of file path component in EFI device path
---
grub-core/osdep/windows/platform.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/grub-core/osdep/windows/platform.c b/grub-core/osdep/windows/platform.c
index e017796..4da0ed0 100644
--- a/grub-core/osdep/windows/platform.c
+++ b/grub-core/osdep/windows/platform.c
@@ -246,6 +246,8 @@ grub_install_register_efi (grub_device_t efidir_grub_dev,
void *current = NULL;
ssize_t current_len;
current = get_efi_variable_bootn (i, ¤t_len);
+ if (current_len < 0)
+ continue; /* Should we abort on error? */
if (current_len < (distrib16_len + 1) * sizeof (grub_uint16_t)
+ 6)
{
@@ -273,10 +275,16 @@ grub_install_register_efi (grub_device_t efidir_grub_dev,
void *current = NULL;
ssize_t current_len;
current = get_efi_variable_bootn (i, ¤t_len);
+ if (current_len < -1)
+ continue; /* Should we abort here? */
if (current_len == -1)
{
- order_num = i;
- have_order_num = 1;
+ if (!have_order_num)
+ {
+ order_num = i;
+ have_order_num = 1;
+ }
+ continue;
}
if (current_len < (distrib16_len + 1) * sizeof (grub_uint16_t)
+ 6)
@@ -369,9 +377,9 @@ grub_install_register_efi (grub_device_t efidir_grub_dev,
path8_len * GRUB_MAX_UTF16_PER_UTF8,
(const grub_uint8_t *) efifile_path,
path8_len, 0);
- filep->path_name[path16_len + 1] = 0;
+ filep->path_name[path16_len] = 0;
filep->header.length = sizeof (*filep) + (path16_len + 1) * sizeof (grub_uint16_t);
- pathptr = &filep->path_name[path16_len + 2];
+ pathptr = &filep->path_name[path16_len + 1];
endp = pathptr;
endp->type = GRUB_EFI_END_DEVICE_PATH_TYPE;
endp->subtype = GRUB_EFI_END_ENTIRE_DEVICE_PATH_SUBTYPE;
--
tg: (f3b8170..) u/windows-efi-fixes (depends on: origin/windows-efi)
next reply other threads:[~2013-12-15 8:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-15 8:04 Andrey Borzenkov [this message]
2013-12-15 11:43 ` [PATCH] trivial fixes for windows-efi branch Vladimir 'phcoder' Serbinenko
2013-12-15 12:41 ` Andrey Borzenkov
2013-12-15 12:51 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-15 16:43 ` Vladimir 'φ-coder/phcoder' Serbinenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1387094652-14021-1-git-send-email-arvidjaar@gmail.com \
--to=arvidjaar@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).