qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stanislav Shmarov <snarpix@gmail.com>
To: Sergey Fedorov <sergey.fedorov@linaro.org>
Cc: Richard Henderson <rth@twiddle.net>,
	Peter Crosthwaite <crosthwaite.peter@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] translate-all: Bugfix for user-mode self-modifying code in 2 page long TB
Date: Wed, 6 Jul 2016 16:22:02 +0300	[thread overview]
Message-ID: <CACVv8pMfnXOUBtML75rhmYamp5aqzmz7g3a2Mg+waYkwnU4VJQ@mail.gmail.com> (raw)
In-Reply-To: <577CFF60.5030805@linaro.org>

Yes, exactly.

There is no point for returning to main loop immediately when current TB is
found on host page and is retranslated. We can continue invalidation of
TBs, and finally remove host page write protection. So there will be no
second SEGFAULT.

And when generating TB for next instructions, host page will be locked
again, if TB includes instructions from that page.

Stanislav.
6 Июл 2016 г. 15:53 пользователь "Sergey Fedorov" <sergey.fedorov@linaro.org>
написал:

> On 06/07/16 15:01, Стас Шмаров wrote:
>
> May be this can be done faster.
> After invalidation of current TB, we know next executed TB will be 1
> instruction long and will write to same address, and will cause segfault.
> In sigfault handler write protection to this page will be disabled.
> So, we can retranslate TB, and remove protection before execution of new
> TB. It will be one signal less.
>
>
> You mean not to return 2 immediately but rather to remember the desired
> return value and keep invalidating guest pages, then go ahead and call
> mprotect() to enable writes to the host page?
>
> Thanks,
> Sergey
>
>
> 2016-07-06 13:21 GMT+03:00 Sergey Fedorov <sergey.fedorov@linaro.org>:
>
>> On 06/07/16 10:54, Stanislav Shmarov wrote:
>> > In user-mode emulation Translation Block can consist of 2 guest pages.
>> > In that case QEMU also mprotects 2 host pages that are dedicated for
>> > guest memory, containing instructions. QEMU detects self-modifying code
>> > with SEGFAULT signal processing.
>> >
>> > In case if instruction in 1st page is modifying memory of 2nd
>> > page (or vice versa) QEMU will mark 2nd page with PAGE_WRITE,
>> > invalidate TB, generate new TB contatining 1 guest instruction and
>> > exit to CPU loop. QEMU won't call mprotect, and new TB will cause
>> > same SEGFAULT. Page will have both PAGE_WRITE_ORG and PAGE_WRITE
>> > flags, so QEMU will handle the signal as guest binary problem,
>> > and exit with guest SEGFAULT.
>> >
>> > Solution is retranslate TB before marking pages as PAGE_WRITE,
>> > and remove protection with mprotect on second SEGFAULT.
>> >
>> > Signed-off-by: Stanislav Shmarov <snarpix@gmail.com>
>>
>> Reviewed-by: Sergey Fedorov <sergey.fedorov@linaro.org>
>>
>> > ---
>> >   v2: Moved setting PAGE_WRITE flag to separte loop, to cover cases,
>> >       pointed by Sergey Fedorov.
>> >
>> >  translate-all.c | 17 +++++++++++------
>> >  1 file changed, 11 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/translate-all.c b/translate-all.c
>> > index eaa95e4..fb3743f 100644
>> > --- a/translate-all.c
>> > +++ b/translate-all.c
>> > @@ -2020,13 +2020,8 @@ int page_unprotect(target_ulong address,
>> uintptr_t pc)
>> >          host_start = address & qemu_host_page_mask;
>> >          host_end = host_start + qemu_host_page_size;
>> >
>> > -        prot = 0;
>> >          for (addr = host_start ; addr < host_end ; addr +=
>> TARGET_PAGE_SIZE) {
>> > -            p = page_find(addr >> TARGET_PAGE_BITS);
>> > -            p->flags |= PAGE_WRITE;
>> > -            prot |= p->flags;
>> > -
>> > -            /* and since the content will be modified, we must
>> invalidate
>> > +            /* Since the content will be modified, we must invalidate
>> >                 the corresponding translated code. */
>> >              if (tb_invalidate_phys_page(addr, pc)) {
>> >                  mmap_unlock();
>> > @@ -2036,6 +2031,16 @@ int page_unprotect(target_ulong address,
>> uintptr_t pc)
>> >              tb_invalidate_check(addr);
>> >  #endif
>> >          }
>> > +
>> > +        /* If we got here, current TB have been retranslated (in case
>> of
>> > +         * self-modifying code), now it's safe to remove page
>> protection.
>> > +         */
>> > +        prot = 0;
>> > +        for (addr = host_start ; addr < host_end ; addr +=
>> TARGET_PAGE_SIZE) {
>> > +            p = page_find(addr >> TARGET_PAGE_BITS);
>> > +            p->flags |= PAGE_WRITE;
>> > +            prot |= p->flags;
>> > +        }
>> >          mprotect((void *)g2h(host_start), qemu_host_page_size,
>> >                   prot & PAGE_BITS);
>> >
>>
>>
>
>

  reply	other threads:[~2016-07-06 13:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-06  7:54 [Qemu-devel] [PATCH v2] translate-all: Bugfix for user-mode self-modifying code in 2 page long TB Stanislav Shmarov
2016-07-06 10:21 ` Sergey Fedorov
2016-07-06 12:01   ` Стас Шмаров
2016-07-06 12:53     ` Sergey Fedorov
2016-07-06 13:22       ` Stanislav Shmarov [this message]
2016-07-06 13:22         ` Sergey Fedorov

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=CACVv8pMfnXOUBtML75rhmYamp5aqzmz7g3a2Mg+waYkwnU4VJQ@mail.gmail.com \
    --to=snarpix@gmail.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=sergey.fedorov@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).