[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/3] x86/mem_sharing: option to enforce fork starting with empty p2m
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
- Date: Wed, 30 Mar 2022 08:23:14 -0400
- Cc: Tamas K Lengyel <tamas.lengyel@xxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Juergen Gross <JGross@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 30 Mar 2022 12:23:33 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 29.03.2022 18:10, Tamas K Lengyel wrote:
> On Tue, Mar 29, 2022 at 11:42 AM Jan Beulich <jbeulich@xxxxxxxx> 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
|