From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Chen Yu <yu.chen.surf@gmail.com>
Subject: Re: [GIT PULL] bootconfig: Extend the magic check range to the preceding 3 bytes
Date: Fri, 13 Nov 2020 12:54:19 -0500 [thread overview]
Message-ID: <20201113125419.3656d001@oasis.local.home> (raw)
In-Reply-To: <CAHk-=whO3bt9wCFX-v54RYewdAuovVEDx9DHJ0SbhrzCwY3aEA@mail.gmail.com>
On Fri, 13 Nov 2020 09:43:31 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, Nov 13, 2020 at 5:29 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Fix alignment of bootconfig
> >
> > GRUB may align the init ramdisk size to 4 bytes, the magic number at the
> > end of the init ramdisk that denotes bootconfig is attached may not be at
> > the exact end of the ramdisk. The kernel needs to check back at least 4
> > bytes.
>
> I've pulled this, but this really smells to me.
>
> Isn't the thing that actually _writes_ that BOOTCONFIG_MAGIC able to
> fix this properly? I'm looking at the bootconfig tool, and wondering
> why that doesn't know about the alignment thing, for example.
>
> And the fact that this got screwed up means that the BOOTCONFIG
> documentation needs updating too, so that the rules are documented and
> proper.
>
The issue is with grub. It will pad the initrd that it is given to make
sure that it ends on a 4 byte memory boundary. That is the bootconfig
tool adds itself at the end of the ramdisk. But, after grub loads it
into memory, if the ramdisk loaded ends at an off by one from finishing
at a 4 byte boundary, grub will append 3 more bytes. It then passes that
ending to the kernel.
The issue is that grub padded the end of the ramdisk after loading it
into memory. I'm not sure how the bootconfig tool can fix this. Perhaps
make sure the ram disk size is 4 bytes aligned?
Masami, correct me if my above explanation is incorrect. Thanks!
-- Steve
next prev parent reply other threads:[~2020-11-13 17:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-13 13:29 Steven Rostedt
2020-11-13 17:43 ` Linus Torvalds
2020-11-13 17:54 ` Steven Rostedt [this message]
2020-11-13 17:57 ` Linus Torvalds
2020-11-13 18:03 ` Steven Rostedt
2020-11-16 7:07 ` Masami Hiramatsu
2020-11-13 17:49 ` pr-tracker-bot
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=20201113125419.3656d001@oasis.local.home \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=yu.chen.surf@gmail.com \
/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
all inboxes | Powered by JetHome®