All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jeddeloh <andrew.jeddeloh@redhat.com>
To: Daniel Kiper <dkiper@net-space.pl>
Cc: grub-devel@gnu.org
Subject: Re: [PATCH] loader/i386/linux: calculate the size of the setup header
Date: Fri, 25 May 2018 12:02:03 -0700	[thread overview]
Message-ID: <CAK=Wzwdo1mMvT7OMKrqxEPF7_bR_5QC07+S_ma26cq9ZP0F0pw@mail.gmail.com> (raw)
In-Reply-To: <20180518115301.GA13069@router-fw-old.local.net-space.pl>

Oops, my bad, didn't mean to drop the ML.

So you're saying the setup header could expand to include some of pad7
in the future, but we error if it goes beyond that (into the e820
map)? Looking at bootparam.h it looks like the _most_ correct thing
would be to stop at edd_mbr_sig_buffer, but grub doesn't have a
corresponding field so e820_map seems good enough. Thanks for working
through this.

Here's the revised patch


From d46c75b4a9151c10e7f7809637f9f42a2c393c25 Mon Sep 17 00:00:00 2001
From: Andrew Jeddeloh <andrew.jeddeloh@coreos.com>
Date: Tue, 8 May 2018 14:39:01 -0700
Subject: [PATCH] loader/i386/linux: calculate setup header length

Previously the length was just assumed to be the size of the
linux_params struct. The linux x86 32 bit boot protocol says the size of
the setup header is 0x202 + the byte at 0x201 in the boot params.
Calculate the size of the header, rather than assume it is the size of
the linux_params struct.

Signed-off-by: Andrew Jeddeloh <andrew.jeddeloh@coreos.com>
---
 grub-core/loader/i386/linux.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/linux.c
index 44301e126..b5b65ea36 100644
--- a/grub-core/loader/i386/linux.c
+++ b/grub-core/loader/i386/linux.c
@@ -805,7 +805,19 @@ grub_cmd_linux (grub_command_t cmd __attribute__
((unused)),
   linux_params.kernel_alignment = (1 << align);
   linux_params.ps_mouse = linux_params.padding10 =  0;

-  len = sizeof (linux_params) - sizeof (lh);
+  /* The Linux 32 bit boot protocol defines the setup header size to
be 0x202 + the byte value
+   * at 0x201. */
+  len = *((char *)&linux_params.jump + 1) + 0x202;
+
+  /* Verify the struct is big enough so we do not write past the end */
+  if (len > (char *)&linux_params.e820_map - (char *)&linux_params) {
+    grub_error (GRUB_ERR_BAD_OS, "boot params setup header too big");
+    goto fail;
+  }
+
+  /* We've already read lh so there is no need to read it second time. */
+  len -= sizeof(lh);
+
   if (grub_file_read (file, (char *) &linux_params + sizeof (lh), len) != len)
     {
       if (!grub_errno)
-- 
2.14.1


On Fri, May 18, 2018 at 4:53 AM, Daniel Kiper <dkiper@net-space.pl> wrote:
> Re-added grub-devel. Next time please do not drop GRUB ML from the addresses.
>
> On Thu, May 17, 2018 at 03:40:32PM -0700, Andrew Jeddeloh wrote:
>> Sorry about the long delay, I agree with all the sugguestions, except shouldn't
>
> No problem.
>
>> if (len > &linux_params.e820_map - &linux_params)
>>
>> be
>>
>> if (len > sizeof(linux_params))
>>
>> since at that point len is the total size of the header which
>> linux_params represents?
>
> Please take a look at arch/x86/include/uapi/asm/bootparam.h in latest
> Linux kernel source. My proposal is better but it seems to me right now
> that it is still too much. I have a feeling that we should not go beyond
> the end of boot_params._pad7. Am I right?
>
> Daniel


  reply	other threads:[~2018-05-25 19:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 17:46 [PATCH] loader/i386/linux: calculate the size of the setup header Andrew Jeddeloh
2018-05-10 17:11 ` Daniel Kiper
     [not found]   ` <CAK=WzwcAa5kjyT+Tupr5jedX+XiW1i4hDjknLZHEst1EGLOmtg@mail.gmail.com>
2018-05-18 11:53     ` Daniel Kiper
2018-05-25 19:02       ` Andrew Jeddeloh [this message]
2018-05-30 14:40         ` Daniel Kiper

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='CAK=Wzwdo1mMvT7OMKrqxEPF7_bR_5QC07+S_ma26cq9ZP0F0pw@mail.gmail.com' \
    --to=andrew.jeddeloh@redhat.com \
    --cc=dkiper@net-space.pl \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.