From: "Michael S. Tsirkin" <mst@redhat.com>
To: Wei Wang <wei.w.wang@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON discussion
Date: Wed, 7 Nov 2018 21:50:42 -0500 [thread overview]
Message-ID: <20181107214929-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <5BE3A430.7030505@intel.com>
On Thu, Nov 08, 2018 at 10:49:20AM +0800, Wei Wang wrote:
> On 11/07/2018 11:27 PM, Michael S. Tsirkin wrote:
>
> + LKML
>
> > On Wed, Nov 07, 2018 at 02:29:02PM +0000, Wang, Wei W wrote:
> > > Hi Michael,
> > >
> > >
> > > Thanks again for reviewing so many versions of patches, and I learnt a lot from
> > > your comments.
> > >
> > >
> > > While I’m writing the virtio-balloon spec patches, I’m thinking probably we
> > > don’t need VIRTIO_BALLOON_F_PAGE_POISON to limit
> > > VIRTIO_BALLOON_F_FREE_PAGE_HINT, because now the guest frees the allocated
> > > pages after the migration is done (that is, the skipped free pages will be
> > > poisoned when the guest is already on the destination machine).
> > The concern was this:
> >
> > guest poisons the page by writing a non-0 pattern there
> > guest sends page to host
> > VM is migrated, page is unmapped
> > guest reads page, zero page is mapped
>
> Not sure about this one: I think guest wouldn't read the page,
> since they are held by balloon (balloon itself will also
> not read it, the page just stays on a list waiting to be freed).
> Please see the below example.
>
> > guest sees 0 in page and detects it as use after free
>
> - balloon collects (i.e. alloc) a free page X (now it
> has 0xaa poison value) and reports X to host to be skipped in
> migration;
> - Now VM is migrated to the destination, and on the destination
> side, X is not mapped initially.
> - Nobody will access X since it has been taken by balloon
> and stays on a list waiting to be freed. So the first chance
> that will get X mapped will be the moment that balloon
> returns X to mm via free(), as free() writes the
> poison value to X.
>
>
> Best,
> Wei
Oh I see, that was with the previous design where we bypassed alloc.
I think you are right, but better stress-test it.
--
MST
next prev parent reply other threads:[~2018-11-08 2:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <286AC319A985734F985F78AFA26841F73DE40B6C@shsmsx102.ccr.corp.intel.com>
[not found] ` <20181107102538-mutt-send-email-mst@kernel.org>
2018-11-08 2:49 ` virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON discussion Wei Wang
2018-11-08 2:50 ` Michael S. Tsirkin [this message]
2018-11-08 3:01 ` Wei Wang
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=20181107214929-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wei.w.wang@intel.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 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.