Re: [PATCH v2 1/3] x86/mem_sharing: option to enforce fork starting with empty p2m

From: Tamas K Lengyel <tamas@tklengyel.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Tamas K Lengyel" <tamas.lengyel@intel.com>,
	"Wei Liu" <wl@xen.org>,
	"Anthony PERARD" <anthony.perard@citrix.com>,
	"Juergen Gross" <JGross@suse.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Jun Nakajima" <jun.nakajima@intel.com>,
	"Kevin Tian" <kevin.tian@intel.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 1/3] x86/mem_sharing: option to enforce fork starting with empty p2m
Date: Wed, 30 Mar 2022 08:23:14 -0400	[thread overview]
Message-ID: <CABfawhnTxuMr7T02B=0thy8h_P4KnCC2zc+Q-Ej==WZdh-Te9A@mail.gmail.com> (raw)
In-Reply-To: <b20fd202-0fd2-ad8a-58dc-1ca83b8da444@suse.com>

[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]

On Wed, Mar 30, 2022, 2:47 AM Jan Beulich <jbeulich@suse.com> wrote:

> On 29.03.2022 18:10, Tamas K Lengyel wrote:
> > On Tue, Mar 29, 2022 at 11:42 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 29.03.2022 16:03, Tamas K Lengyel wrote:
> >>> Add option to the fork memop to enforce a start with an empty p2m.
> >>> Pre-populating special pages to the fork tend to be necessary only
> when setting
> >>> up forks to be fully functional with a toolstack or if the fork makes
> use of
> >>> them in some way. For short-lived forks these pages are optional and
> starting
> >>> with an empty p2m has advantages both in terms of reset performance as
> well as
> >>> easier reasoning about the state of the fork after creation.
> >>
> >> I'm afraid I don't consider this enough of an explanation: Why would
> these
> >> page be optional? Where does the apriori knowledge come from that the
> guest
> >> wouldn't manage to access the vCPU info pages or the APIC access one?
> >
> > By knowing what code you are fuzzing. The code you are fuzzing is
> > clearly marked by harnesses and that's the only code you execute while
> > fuzzing. If you know the code doesn't use them, no need to map them
> > in. They haven't been needed in any of the fuzzing setups we had so
> > far so I'm planning to be this the default when fuzzing.
>
> But isn't it the very nature of what you do fuzzing for that unexpected
> code paths may be taken? By not having in place what is expected to be
> there, yet more unexpected behavior might then result.
>

You don't get totally arbitrary execution, no. If you do then that means
having instability and non-reproducible runs which makes the fuzzing
inefficient. So if you know that the part of code has no reasonable path to
reach code using these pages then you can get rid of them. This is an
option for cases where you can make that call. That's all, just an option.

> Plus - how do you bound how far the guest executes in a single attempt?
>

We use a cpuid or breakpoint to signal where the code reached the end
point. The start point is where the parent got paused (also usually using a
magic cpuid).

Tamas

>

[-- Attachment #2: Type: text/html, Size: 3219 bytes --]