From: Alexander Graf <agraf@suse.de>
To: Scott Wood <scottwood@freescale.com>
Cc: Mihai Caraman <mihai.caraman@freescale.com>,
"<kvm-ppc@vger.kernel.org>" <kvm-ppc@vger.kernel.org>,
"<kvm@vger.kernel.org>" <kvm@vger.kernel.org>,
"<linuxppc-dev@lists.ozlabs.org>" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 4/4] KVM: PPC: Bookehv: Get vcpu's last instruction for emulation
Date: Tue, 01 Apr 2014 17:11:53 +0000 [thread overview]
Message-ID: <533AF359.1030504@suse.de> (raw)
In-Reply-To: <1396371496.20849.51.camel@snotra.buserror.net>
On 04/01/2014 06:58 PM, Scott Wood wrote:
> On Tue, 2014-04-01 at 07:47 +0200, Alexander Graf wrote:
>>> Am 01.04.2014 um 01:03 schrieb Scott Wood <scottwood@freescale.com>:
>>>
>>>> On Mon, 2014-03-31 at 15:41 +0200, Alexander Graf wrote:
>>>>> On 03/26/2014 10:17 PM, Scott Wood wrote:
>>>>>> On Thu, 2014-02-20 at 18:30 +0200, Mihai Caraman wrote:
>>>>>> + /*
>>>>>> + * Another thread may rewrite the TLB entry in parallel, don't
>>>>>> + * execute from the address if the execute permission is not set
>>>>>> + */
>>>> What happens when another thread rewrites the TLB entry in parallel?
>>>> Does tlbsx succeed? Does it fail? Do we see failure indicated somehow?
>>>> Are the contents of the MAS registers consistent at this point or
>>>> inconsistent?
>>> If another thread rewrites the TLB entry, then we use the new TLB entry,
>>> just as if it had raced in hardware. This check ensures that we don't
>>> execute from the new TLB entry if it doesn't have execute permissions
>>> (just as hardware would).
>>>
>>> What happens if the new TLB entry is valid and executable, and the
>>> instruction pointed to is valid, but doesn't trap (and thus we don't
>>> have emulation for it)?
>>>
>>>> There has to be a good way to detect such a race and deal with it, no?
>>> How would you detect it? We don't get any information from the trap
>>> about what physical address the instruction was fetched from, or what
>>> the instruction was.
>> Ah, this is a guest race where the guest modifies exactly the TLB in question. I see.
>>
>> Why would this ever happen in practice (in a case where we're not executing malicious code)?
> I don't know. It probably wouldn't. But it seems wrong to not check
> the exec bit.
Right, I'm just saying that a program interrupt is not too bad of an
answer in case the guest does something as stupid as this in kernel
space :). It's definitely good practice to check for the exec bit.
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Scott Wood <scottwood@freescale.com>
Cc: Mihai Caraman <mihai.caraman@freescale.com>,
"<linuxppc-dev@lists.ozlabs.org>" <linuxppc-dev@lists.ozlabs.org>,
"<kvm@vger.kernel.org>" <kvm@vger.kernel.org>,
"<kvm-ppc@vger.kernel.org>" <kvm-ppc@vger.kernel.org>
Subject: Re: [PATCH 4/4] KVM: PPC: Bookehv: Get vcpu's last instruction for emulation
Date: Tue, 01 Apr 2014 19:11:53 +0200 [thread overview]
Message-ID: <533AF359.1030504@suse.de> (raw)
In-Reply-To: <1396371496.20849.51.camel@snotra.buserror.net>
On 04/01/2014 06:58 PM, Scott Wood wrote:
> On Tue, 2014-04-01 at 07:47 +0200, Alexander Graf wrote:
>>> Am 01.04.2014 um 01:03 schrieb Scott Wood <scottwood@freescale.com>:
>>>
>>>> On Mon, 2014-03-31 at 15:41 +0200, Alexander Graf wrote:
>>>>> On 03/26/2014 10:17 PM, Scott Wood wrote:
>>>>>> On Thu, 2014-02-20 at 18:30 +0200, Mihai Caraman wrote:
>>>>>> + /*
>>>>>> + * Another thread may rewrite the TLB entry in parallel, don't
>>>>>> + * execute from the address if the execute permission is not set
>>>>>> + */
>>>> What happens when another thread rewrites the TLB entry in parallel?
>>>> Does tlbsx succeed? Does it fail? Do we see failure indicated somehow?
>>>> Are the contents of the MAS registers consistent at this point or
>>>> inconsistent?
>>> If another thread rewrites the TLB entry, then we use the new TLB entry,
>>> just as if it had raced in hardware. This check ensures that we don't
>>> execute from the new TLB entry if it doesn't have execute permissions
>>> (just as hardware would).
>>>
>>> What happens if the new TLB entry is valid and executable, and the
>>> instruction pointed to is valid, but doesn't trap (and thus we don't
>>> have emulation for it)?
>>>
>>>> There has to be a good way to detect such a race and deal with it, no?
>>> How would you detect it? We don't get any information from the trap
>>> about what physical address the instruction was fetched from, or what
>>> the instruction was.
>> Ah, this is a guest race where the guest modifies exactly the TLB in question. I see.
>>
>> Why would this ever happen in practice (in a case where we're not executing malicious code)?
> I don't know. It probably wouldn't. But it seems wrong to not check
> the exec bit.
Right, I'm just saying that a program interrupt is not too bad of an
answer in case the guest does something as stupid as this in kernel
space :). It's definitely good practice to check for the exec bit.
Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Scott Wood <scottwood@freescale.com>
Cc: Mihai Caraman <mihai.caraman@freescale.com>,
"<kvm-ppc@vger.kernel.org>" <kvm-ppc@vger.kernel.org>,
"<kvm@vger.kernel.org>" <kvm@vger.kernel.org>,
"<linuxppc-dev@lists.ozlabs.org>" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 4/4] KVM: PPC: Bookehv: Get vcpu's last instruction for emulation
Date: Tue, 01 Apr 2014 19:11:53 +0200 [thread overview]
Message-ID: <533AF359.1030504@suse.de> (raw)
In-Reply-To: <1396371496.20849.51.camel@snotra.buserror.net>
On 04/01/2014 06:58 PM, Scott Wood wrote:
> On Tue, 2014-04-01 at 07:47 +0200, Alexander Graf wrote:
>>> Am 01.04.2014 um 01:03 schrieb Scott Wood <scottwood@freescale.com>:
>>>
>>>> On Mon, 2014-03-31 at 15:41 +0200, Alexander Graf wrote:
>>>>> On 03/26/2014 10:17 PM, Scott Wood wrote:
>>>>>> On Thu, 2014-02-20 at 18:30 +0200, Mihai Caraman wrote:
>>>>>> + /*
>>>>>> + * Another thread may rewrite the TLB entry in parallel, don't
>>>>>> + * execute from the address if the execute permission is not set
>>>>>> + */
>>>> What happens when another thread rewrites the TLB entry in parallel?
>>>> Does tlbsx succeed? Does it fail? Do we see failure indicated somehow?
>>>> Are the contents of the MAS registers consistent at this point or
>>>> inconsistent?
>>> If another thread rewrites the TLB entry, then we use the new TLB entry,
>>> just as if it had raced in hardware. This check ensures that we don't
>>> execute from the new TLB entry if it doesn't have execute permissions
>>> (just as hardware would).
>>>
>>> What happens if the new TLB entry is valid and executable, and the
>>> instruction pointed to is valid, but doesn't trap (and thus we don't
>>> have emulation for it)?
>>>
>>>> There has to be a good way to detect such a race and deal with it, no?
>>> How would you detect it? We don't get any information from the trap
>>> about what physical address the instruction was fetched from, or what
>>> the instruction was.
>> Ah, this is a guest race where the guest modifies exactly the TLB in question. I see.
>>
>> Why would this ever happen in practice (in a case where we're not executing malicious code)?
> I don't know. It probably wouldn't. But it seems wrong to not check
> the exec bit.
Right, I'm just saying that a program interrupt is not too bad of an
answer in case the guest does something as stupid as this in kernel
space :). It's definitely good practice to check for the exec bit.
Alex
next prev parent reply other threads:[~2014-04-01 17:11 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-20 16:30 [PATCH 1/4] KVM: PPC: e500mc: Revert "add load inst fixup" Mihai Caraman
2014-02-20 16:30 ` Mihai Caraman
2014-02-20 16:30 ` Mihai Caraman
2014-02-20 16:30 ` [PATCH 2/4] KVM: PPC: Book3e: Add TLBSEL/TSIZE defines for MAS0/1 Mihai Caraman
2014-02-20 16:30 ` Mihai Caraman
2014-02-20 16:30 ` Mihai Caraman
2014-02-20 16:30 ` [PATCH 3/4] KVM: PPC: Alow kvmppc_get_last_inst() to fail Mihai Caraman
2014-02-20 16:30 ` Mihai Caraman
2014-02-20 16:30 ` Mihai Caraman
2014-03-26 20:52 ` Scott Wood
2014-03-26 20:52 ` Scott Wood
2014-03-26 20:52 ` Scott Wood
2014-03-31 13:32 ` Alexander Graf
2014-03-31 13:32 ` Alexander Graf
2014-03-31 13:32 ` Alexander Graf
2014-02-20 16:30 ` [PATCH 4/4] KVM: PPC: Bookehv: Get vcpu's last instruction for emulation Mihai Caraman
2014-02-20 16:30 ` Mihai Caraman
2014-02-20 16:30 ` Mihai Caraman
2014-03-26 21:17 ` Scott Wood
2014-03-26 21:17 ` Scott Wood
2014-03-26 21:17 ` Scott Wood
2014-03-31 13:41 ` Alexander Graf
2014-03-31 13:41 ` Alexander Graf
2014-03-31 13:41 ` Alexander Graf
2014-03-31 23:03 ` Scott Wood
2014-03-31 23:03 ` Scott Wood
2014-03-31 23:03 ` Scott Wood
2014-04-01 5:47 ` Alexander Graf
2014-04-01 5:47 ` Alexander Graf
2014-04-01 5:47 ` Alexander Graf
2014-04-01 16:58 ` Scott Wood
2014-04-01 16:58 ` Scott Wood
2014-04-01 16:58 ` Scott Wood
2014-04-01 17:11 ` Alexander Graf [this message]
2014-04-01 17:11 ` Alexander Graf
2014-04-01 17:11 ` Alexander Graf
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=533AF359.1030504@suse.de \
--to=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mihai.caraman@freescale.com \
--cc=scottwood@freescale.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.