From: Segher Boessenkool <segher@kernel.crashing.org>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: linuxppc-dev@lists.ozlabs.org,
Oliver O'Halloran <oohall@gmail.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] powerpc/boot: Fix the initrd being overwritten under qemu
Date: Thu, 24 Oct 2019 12:45:45 -0500 [thread overview]
Message-ID: <20191024174545.GT28442@gate.crashing.org> (raw)
In-Reply-To: <90a0f702-6891-cd14-f190-5682d7c3778e@ozlabs.ru>
On Thu, Oct 24, 2019 at 12:31:24PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 23/10/2019 22:21, Segher Boessenkool wrote:
> > On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
> >> When booting under OF the zImage expects the initrd address and size to be
> >> passed to it using registers r3 and r4. SLOF (guest firmware used by QEMU)
> >> currently doesn't do this so the zImage is not aware of the initrd
> >> location. This can result in initrd corruption either though the zImage
> >> extracting the vmlinux over the initrd, or by the vmlinux overwriting the
> >> initrd when relocating itself.
> >>
> >> QEMU does put the linux,initrd-start and linux,initrd-end properties into
> >> the devicetree to vmlinux to find the initrd. We can work around the SLOF
> >> bug by also looking those properties in the zImage.
> >
> > This is not a bug. What boot protocol requires passing the initrd start
> > and size in GPR3, GPR4?
>
> So far I was unable to identify it...
Maybe this comes from yaboot?
https://git.ozlabs.org/?p=yaboot.git;a=blob;f=second/yaboot.c;h=9b66ab44e1be0ee82b88e386a5d0358428766e73;hb=HEAD#l1186
> > The CHRP binding (what SLOF implements) requires passing two zeroes here.
> > And ePAPR requires passing the address of a device tree and a zero, plus
> > something in GPR6 to allow distinguishing what it does.
> >
> > As Alexey says, initramfs works just fine, so please use that? initrd was
> > deprecated when this code was written already.
>
> I did not say about anything working fine :)
Yeah, I read that from your words, wrong it seems. Sorry. I often used
INITRAMFS_SOURCE for kernels for use with SLOF, it's just so convenient.
> In my case I was using a new QEMU which does full FDT on client-arch-support and that thing would put the original
> linux,initrd-start/end to the FDT even though the initrd was unpacked and the properties were changes in SLOF. With that
> fixed, this is an alternative fix for SLOF but I am not pushing it out as I have no idea about the bindings and this
> also breaks "vmlinux".
>
>
> diff --git a/slof/fs/client.fs b/slof/fs/client.fs
> index 8a7f6ac4326d..138177e4c2a3 100644
> --- a/slof/fs/client.fs
> +++ b/slof/fs/client.fs
> @@ -45,6 +45,17 @@ VARIABLE client-callback \ Address of client's callback function
> >r ciregs >r7 ! ciregs >r6 ! client-entry-point @ ciregs >r5 !
> \ Initialise client-stack-pointer
> cistack ciregs >r1 !
> +
> + s" linux,initrd-end" get-chosen IF decode-int -rot 2drop ELSE 0 THEN
> + s" linux,initrd-start" get-chosen IF decode-int -rot 2drop ELSE 0 THEN
> + 2dup - dup IF
> + ciregs >r4 !
> + ciregs >r3 !
> + drop
> + ELSE
> + 3drop
> + THEN
Something like that should work fine. Do it in go-32 and go-64 though?
Or is that the wrong spot?
Segher
WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: "Oliver O'Halloran" <oohall@gmail.com>,
linuxppc-dev@lists.ozlabs.org, stable@vger.kernel.org
Subject: Re: [PATCH] powerpc/boot: Fix the initrd being overwritten under qemu
Date: Thu, 24 Oct 2019 12:45:45 -0500 [thread overview]
Message-ID: <20191024174545.GT28442@gate.crashing.org> (raw)
In-Reply-To: <90a0f702-6891-cd14-f190-5682d7c3778e@ozlabs.ru>
On Thu, Oct 24, 2019 at 12:31:24PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 23/10/2019 22:21, Segher Boessenkool wrote:
> > On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
> >> When booting under OF the zImage expects the initrd address and size to be
> >> passed to it using registers r3 and r4. SLOF (guest firmware used by QEMU)
> >> currently doesn't do this so the zImage is not aware of the initrd
> >> location. This can result in initrd corruption either though the zImage
> >> extracting the vmlinux over the initrd, or by the vmlinux overwriting the
> >> initrd when relocating itself.
> >>
> >> QEMU does put the linux,initrd-start and linux,initrd-end properties into
> >> the devicetree to vmlinux to find the initrd. We can work around the SLOF
> >> bug by also looking those properties in the zImage.
> >
> > This is not a bug. What boot protocol requires passing the initrd start
> > and size in GPR3, GPR4?
>
> So far I was unable to identify it...
Maybe this comes from yaboot?
https://git.ozlabs.org/?p=yaboot.git;a=blob;f=second/yaboot.c;h=9b66ab44e1be0ee82b88e386a5d0358428766e73;hb=HEAD#l1186
> > The CHRP binding (what SLOF implements) requires passing two zeroes here.
> > And ePAPR requires passing the address of a device tree and a zero, plus
> > something in GPR6 to allow distinguishing what it does.
> >
> > As Alexey says, initramfs works just fine, so please use that? initrd was
> > deprecated when this code was written already.
>
> I did not say about anything working fine :)
Yeah, I read that from your words, wrong it seems. Sorry. I often used
INITRAMFS_SOURCE for kernels for use with SLOF, it's just so convenient.
> In my case I was using a new QEMU which does full FDT on client-arch-support and that thing would put the original
> linux,initrd-start/end to the FDT even though the initrd was unpacked and the properties were changes in SLOF. With that
> fixed, this is an alternative fix for SLOF but I am not pushing it out as I have no idea about the bindings and this
> also breaks "vmlinux".
>
>
> diff --git a/slof/fs/client.fs b/slof/fs/client.fs
> index 8a7f6ac4326d..138177e4c2a3 100644
> --- a/slof/fs/client.fs
> +++ b/slof/fs/client.fs
> @@ -45,6 +45,17 @@ VARIABLE client-callback \ Address of client's callback function
> >r ciregs >r7 ! ciregs >r6 ! client-entry-point @ ciregs >r5 !
> \ Initialise client-stack-pointer
> cistack ciregs >r1 !
> +
> + s" linux,initrd-end" get-chosen IF decode-int -rot 2drop ELSE 0 THEN
> + s" linux,initrd-start" get-chosen IF decode-int -rot 2drop ELSE 0 THEN
> + 2dup - dup IF
> + ciregs >r4 !
> + ciregs >r3 !
> + drop
> + ELSE
> + 3drop
> + THEN
Something like that should work fine. Do it in go-32 and go-64 though?
Or is that the wrong spot?
Segher
next prev parent reply other threads:[~2019-10-24 19:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 1:36 [PATCH] powerpc/boot: Fix the initrd being overwritten under qemu Oliver O'Halloran
2019-10-23 1:36 ` Oliver O'Halloran
2019-10-23 7:00 ` Alexey Kardashevskiy
2019-10-23 11:21 ` Segher Boessenkool
2019-10-23 11:21 ` Segher Boessenkool
2019-10-23 12:44 ` Oliver O'Halloran
2019-10-23 12:44 ` Oliver O'Halloran
2019-10-24 1:31 ` Alexey Kardashevskiy
2019-10-24 1:47 ` Alexey Kardashevskiy
2019-10-24 17:45 ` Segher Boessenkool [this message]
2019-10-24 17:45 ` Segher Boessenkool
2019-10-25 0:03 ` Alexey Kardashevskiy
2019-10-25 0:03 ` Alexey Kardashevskiy
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=20191024174545.GT28442@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=aik@ozlabs.ru \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=oohall@gmail.com \
--cc=stable@vger.kernel.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.