Thanks all for your replies and comments. I am trying to summarize main
feedback below, and define next steps.
But first, let me clarify what should happen when exiting the KVM isolated
address space (i.e. when we need to access to the full kernel). There was
some confusion because this was not
On 5/14/19 12:37 AM, Peter Zijlstra wrote:
On Mon, May 13, 2019 at 07:07:36PM -0700, Andy Lutomirski wrote:
On Mon, May 13, 2019 at 2:09 PM Liran Alon wrote:
The hope is that the very vast majority of #VMExit handlers will be
able to completely run without requiring to switch to full address
On 5/13/19 11:08 PM, Liran Alon wrote:
On 13 May 2019, at 21:17, Andy Lutomirski wrote:
I expect that the KVM address space can eventually be expanded to include
the ioctl syscall entries. By doing so, and also adding the KVM page table
to the process userland page table (which should be
> On 14 May 2019, at 5:07, Andy Lutomirski wrote:
>
> On Mon, May 13, 2019 at 2:09 PM Liran Alon wrote:
>>
>>
>>
>>> On 13 May 2019, at 21:17, Andy Lutomirski wrote:
>>>
I expect that the KVM address space can eventually be expanded to include
the ioctl syscall entries. By doin
> On 14 May 2019, at 10:29, Peter Zijlstra wrote:
>
>
> (please, wrap our emails at 78 chars)
>
> On Tue, May 14, 2019 at 12:08:23AM +0300, Liran Alon wrote:
>
>> 3) From (2), we should have theoretically deduced that for every
>> #VMExit, there is a need to kick the sibling hyperthread als
On Mon, May 13, 2019 at 07:07:36PM -0700, Andy Lutomirski wrote:
> On Mon, May 13, 2019 at 2:09 PM Liran Alon wrote:
> > The hope is that the very vast majority of #VMExit handlers will be
> > able to completely run without requiring to switch to full address
> > space. Therefore, avoiding the pe
(please, wrap our emails at 78 chars)
On Tue, May 14, 2019 at 12:08:23AM +0300, Liran Alon wrote:
> 3) From (2), we should have theoretically deduced that for every
> #VMExit, there is a need to kick the sibling hyperthread also outside
> of guest until the #VMExit is completed.
That's not in
On Mon, May 13, 2019 at 2:09 PM Liran Alon wrote:
>
>
>
> > On 13 May 2019, at 21:17, Andy Lutomirski wrote:
> >
> >> I expect that the KVM address space can eventually be expanded to include
> >> the ioctl syscall entries. By doing so, and also adding the KVM page table
> >> to the process userl
> On 14 May 2019, at 0:42, Nakajima, Jun wrote:
>
>
>
>> On May 13, 2019, at 2:16 PM, Liran Alon wrote:
>>
>>> On 13 May 2019, at 22:31, Nakajima, Jun wrote:
>>>
>>> On 5/13/19, 7:43 AM, "kvm-ow...@vger.kernel.org on behalf of Alexandre
>>> Chartre" wrote:
>>>
>>> Proposal
>>>
> On 13 May 2019, at 22:31, Nakajima, Jun wrote:
>
> On 5/13/19, 7:43 AM, "kvm-ow...@vger.kernel.org on behalf of Alexandre
> Chartre" wrote:
>
>Proposal
>
>
>To handle both these points, this series introduce the mechanism of KVM
>address space isolation. Note that
> On 13 May 2019, at 21:17, Andy Lutomirski wrote:
>
>> I expect that the KVM address space can eventually be expanded to include
>> the ioctl syscall entries. By doing so, and also adding the KVM page table
>> to the process userland page table (which should be safe to do because the
>> KVM a
On 5/13/19, 7:43 AM, "kvm-ow...@vger.kernel.org on behalf of Alexandre Chartre"
wrote:
Proposal
To handle both these points, this series introduce the mechanism of KVM
address space isolation. Note that this mechanism completes (a)+(b) and
don't contradict. In ca
> I expect that the KVM address space can eventually be expanded to include
> the ioctl syscall entries. By doing so, and also adding the KVM page table
> to the process userland page table (which should be safe to do because the
> KVM address space doesn't have any secret), we could potentially ha
> On 13 May 2019, at 17:38, Alexandre Chartre
> wrote:
>
> Hi,
>
> This series aims to introduce the concept of KVM address space isolation.
> This is done as part of the upstream community effort to have exploit
> mitigations for CPU info-leaks vulnerabilities such as L1TF.
>
> These patc
Hi,
This series aims to introduce the concept of KVM address space isolation.
This is done as part of the upstream community effort to have exploit
mitigations for CPU info-leaks vulnerabilities such as L1TF.
These patches are based on an original patches from Liran Alon, completed
with addition
15 matches
Mail list logo
