All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan.Robinson@fujitsu.com (Alan Robinson)
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	"Jan Beulich" <JBeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Daniel P . Smith" <dpsmith@apertussolutions.com>
Subject: Re: [PATCH] x86/boot: Fix PVH boot during boot_info transition period
Date: Wed, 23 Oct 2024 09:10:22 +0200	[thread overview]
Message-ID: <20241023071022.GA30985@ts.fujitsu.com> (raw)
In-Reply-To: <cd8f29e7662f44999552be6e75ac6d6c@BEZP281MB2581.DEUP281.PROD.OUTLOOK.COM>

Hi Andrew,

A small suggestion for the commit log..

On Tue, Oct 22, 2024 at 12:41:14PM +0000, Andrew Cooper wrote:
> 
> multiboot_fill_boot_info() taking the physical address of the multiboot_info
> structure leads to a subtle use-after-free on the PVH path, with rather less
> subtle fallout.
> 
> The pointers used by __start_xen(), mbi and mod, are either:
> 
>  - MB:  Directmap pointers into the trampoline, or
>  - PVH: Xen pointers into .initdata, or
>  - EFI: Directmap pointers into Xen.
> 
> Critically, these either remain valid across move_xen() (MB, PVH), or rely on
> move_xen() being inhibited (EFI).
> 
> The conversion to multiboot_fill_boot_info(), taking only mbi_p, makes the PVH
> path use directmap pointers into Xen, as well as move_xen() which invalidates
> said pointers.
> 
> Switch multiboot_fill_boot_info() to consume the same virtual addresses that
> __start_xen() currently uses.  This keeps all the pointers valid for the
> duration of __start_xen(), for all boot protocols.
> 
> It can be safely untangled once multiboot_fill_boot_info() takes a full copy
> the multiboot info data, and __start_xen() has been moved over to using the

 of the multiboot info data, and __start_xen() has been moved over to using the

> new boot_info consistently.
> 

Alan


       reply	other threads:[~2024-10-23  7:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cd8f29e7662f44999552be6e75ac6d6c@BEZP281MB2581.DEUP281.PROD.OUTLOOK.COM>
2024-10-23  7:10 ` Alan Robinson [this message]
2024-10-23  9:25   ` [PATCH] x86/boot: Fix PVH boot during boot_info transition period Andrew Cooper
2024-10-22 12:41 Andrew Cooper
2024-10-22 14:12 ` Roger Pau Monné
2024-10-22 14:20   ` Andrew Cooper

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=20241023071022.GA30985@ts.fujitsu.com \
    --to=alan.robinson@fujitsu.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.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.