On 6/17/19 11:50 AM, Nadav Amit wrote:
>> The idea is that you have a per-cpu address space. Certain kernel
>> virtual addresses would map to different physical address based on where
>> you are running. Each of the physical addresses would be "owned" by a
>> single CPU and would, by convention,
On Mon, Jun 17, 2019 at 11:44 AM Konrad Rzeszutek Wilk
wrote:
>
> On Mon, Jun 17, 2019 at 11:07:45AM -0700, Dave Hansen wrote:
> > On 6/17/19 9:53 AM, Nadav Amit wrote:
> > >>> For anyone following along at home, I'm going to go off into crazy
> > >>> per-cpu-pgds speculation mode now... Feel
> On Jun 17, 2019, at 11:07 AM, Dave Hansen wrote:
>
> On 6/17/19 9:53 AM, Nadav Amit wrote:
For anyone following along at home, I'm going to go off into crazy
per-cpu-pgds speculation mode now... Feel free to stop reading now. :)
But, I was thinking we could get away with
On 6/17/19 11:45 AM, Konrad Rzeszutek Wilk wrote:
>> The idea is that you have a per-cpu address space. Certain kernel
>> virtual addresses would map to different physical address based on where
>> you are running. Each of the physical addresses would be "owned" by a
>> single CPU and would, by
On Mon, Jun 17, 2019 at 11:07:45AM -0700, Dave Hansen wrote:
> On 6/17/19 9:53 AM, Nadav Amit wrote:
> >>> For anyone following along at home, I'm going to go off into crazy
> >>> per-cpu-pgds speculation mode now... Feel free to stop reading now. :)
> >>>
> >>> But, I was thinking we could get
On 6/17/19 9:53 AM, Nadav Amit wrote:
>>> For anyone following along at home, I'm going to go off into crazy
>>> per-cpu-pgds speculation mode now... Feel free to stop reading now. :)
>>>
>>> But, I was thinking we could get away with not doing this on _every_
>>> context switch at least. For
> On Jun 17, 2019, at 9:14 AM, Andy Lutomirski wrote:
>
> On Mon, Jun 17, 2019 at 9:09 AM Dave Hansen wrote:
>> On 6/17/19 8:54 AM, Andy Lutomirski wrote:
> Would that mean that with Meltdown affected CPUs we open speculation
> attacks against the mmlocal memory from KVM user space?
On Mon, Jun 17, 2019 at 9:09 AM Dave Hansen wrote:
>
> On 6/17/19 8:54 AM, Andy Lutomirski wrote:
> >>> Would that mean that with Meltdown affected CPUs we open speculation
> >>> attacks against the mmlocal memory from KVM user space?
> >> Not necessarily. There would likely be a _set_ of local
On 6/17/19 8:54 AM, Andy Lutomirski wrote:
>>> Would that mean that with Meltdown affected CPUs we open speculation
>>> attacks against the mmlocal memory from KVM user space?
>> Not necessarily. There would likely be a _set_ of local PGDs. We could
>> still have pair of PTI PGDs just like we do
On 6/17/19 12:38 AM, Alexander Graf wrote:
>> Yes I know, but as a benefit we could get rid of all the GSBASE
>> horrors in
>> the entry code as we could just put the percpu space into the local PGD.
>
> Would that mean that with Meltdown affected CPUs we open speculation
> attacks against the
On Mon, Jun 17, 2019 at 8:50 AM Dave Hansen wrote:
>
> On 6/17/19 12:38 AM, Alexander Graf wrote:
> >> Yes I know, but as a benefit we could get rid of all the GSBASE
> >> horrors in
> >> the entry code as we could just put the percpu space into the local PGD.
> >
> > Would that mean that with
On 14.06.19 16:21, Thomas Gleixner wrote:
On Wed, 12 Jun 2019, Andy Lutomirski wrote:
On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote:
On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
This patch series proposes to introduce a region for what we call
process-local memory into the kernel's
On Sun, 16 Jun 2019, Andy Lutomirski wrote:
> On Fri, Jun 14, 2019 at 7:21 AM Thomas Gleixner wrote:
> > On Wed, 12 Jun 2019, Andy Lutomirski wrote:
> > >
> > > Fair warning: Linus is on record as absolutely hating this idea. He might
> > > change his mind, but it’s an uphill battle.
> >
> > Yes
On Fri, Jun 14, 2019 at 7:21 AM Thomas Gleixner wrote:
>
> On Wed, 12 Jun 2019, Andy Lutomirski wrote:
> > > On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote:
> > >
> > >> On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
> > >> This patch series proposes to introduce a region for what we call
> >
On Wed, 12 Jun 2019, Andy Lutomirski wrote:
> > On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote:
> >
> >> On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
> >> This patch series proposes to introduce a region for what we call
> >> process-local memory into the kernel's virtual address space.
> >
On Thu, Jun 13, 2019 at 10:49:42AM -0700, Dave Hansen wrote:
> On 6/13/19 10:29 AM, Nadav Amit wrote:
> > Having said that, I am not too excited to deal with this issue. Do
> > people still care about x86/32-bit?
> No, not really.
Especially not for KVM, given the number of times 32-bit KVM has
On 6/13/19 10:29 AM, Nadav Amit wrote:
> Having said that, I am not too excited to deal with this issue. Do
> people still care about x86/32-bit?
No, not really. It's just fun to try to give history lessons about the
good old days. ;)
> On Jun 13, 2019, at 9:20 AM, Dave Hansen wrote:
>
> On 6/13/19 9:13 AM, Andy Lutomirski wrote:
>>> It might make sense to use it for kmap_atomic() for debug purposes, as
>>> it ensures that other users can no longer access the same mapping
>>> through the linear map. However, it does come at
On Wed, Jun 12, 2019 at 1:27 PM Andy Lutomirski wrote:
>
>
>
> > On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote:
> >
> >> On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
> >> This patch series proposes to introduce a region for what we call
> >> process-local memory into the kernel's virtual
> On Jun 12, 2019, at 6:30 PM, Andy Lutomirski wrote:
>
> On Wed, Jun 12, 2019 at 1:27 PM Andy Lutomirski wrote:
>>> On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote:
>>>
On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
This patch series proposes to introduce a region for what we call
On 12.06.19 20:25, Sean Christopherson wrote:
On Wed, Jun 12, 2019 at 07:08:24PM +0200, Marius Hillenbrand wrote:
The Linux kernel has a global address space that is the same for any
kernel code. This address space becomes a liability in a world with
processor information leak
On 12.06.19 21:55, Dave Hansen wrote:
On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
This patch series proposes to introduce a region for what we call
process-local memory into the kernel's virtual address space.
It might be fun to cc some x86 folks on this series. They might have
some
On 13.06.19 03:30, Andy Lutomirski wrote:
On Wed, Jun 12, 2019 at 1:27 PM Andy Lutomirski wrote:
On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote:
On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
This patch series proposes to introduce a region for what we call
process-local memory into
On 6/13/19 9:13 AM, Andy Lutomirski wrote:
>> It might make sense to use it for kmap_atomic() for debug purposes, as
>> it ensures that other users can no longer access the same mapping
>> through the linear map. However, it does come at quite a big cost, as we
>> need to shoot down the TLB of all
On Wed, Jun 12, 2019 at 6:50 PM Nadav Amit wrote:
>
> > On Jun 12, 2019, at 6:30 PM, Andy Lutomirski wrote:
> >
> > On Wed, Jun 12, 2019 at 1:27 PM Andy Lutomirski wrote:
> >>> On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote:
> >>>
> On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
>
On Thu, Jun 13, 2019 at 12:53 AM Alexander Graf wrote:
>
>
> On 13.06.19 03:30, Andy Lutomirski wrote:
> > On Wed, Jun 12, 2019 at 1:27 PM Andy Lutomirski wrote:
> >>
> >>
> >>> On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote:
> >>>
> On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
>
> On 12 Jun 2019, at 21:25, Sean Christopherson
> wrote:
>
> On Wed, Jun 12, 2019 at 07:08:24PM +0200, Marius Hillenbrand wrote:
>> The Linux kernel has a global address space that is the same for any
>> kernel code. This address space becomes a liability in a world with
>> processor
On 6/13/19 12:27 AM, Alexander Graf wrote:
>> Where's the context-switching code? Did I just miss it?
>
> I'm not sure I understand the question. With this mechanism, the global
> linear map pages are just not present anymore, so there is no context
> switching needed. For the process local
> On Jun 12, 2019, at 1:41 PM, Dave Hansen wrote:
>
> On 6/12/19 1:27 PM, Andy Lutomirski wrote:
>>> We've discussed having per-cpu page tables where a given PGD is
>>> only in use from one CPU at a time. I *think* this scheme still
>>> works in such a case, it just adds one more PGD entry
On 6/12/19 1:27 PM, Andy Lutomirski wrote:
>> We've discussed having per-cpu page tables where a given PGD is
>> only in use from one CPU at a time. I *think* this scheme still
>> works in such a case, it just adds one more PGD entry that would
>> have to context-switched.
> Fair warning: Linus
> On Jun 12, 2019, at 12:55 PM, Dave Hansen wrote:
>
>> On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
>> This patch series proposes to introduce a region for what we call
>> process-local memory into the kernel's virtual address space.
>
> It might be fun to cc some x86 folks on this
On 6/12/19 10:08 AM, Marius Hillenbrand wrote:
> This patch series proposes to introduce a region for what we call
> process-local memory into the kernel's virtual address space.
It might be fun to cc some x86 folks on this series. They might have
some relevant opinions. ;)
A few high-level
On Wed, Jun 12, 2019 at 07:08:24PM +0200, Marius Hillenbrand wrote:
> The Linux kernel has a global address space that is the same for any
> kernel code. This address space becomes a liability in a world with
> processor information leak vulnerabilities, such as L1TF. With the right
> cache load
The Linux kernel has a global address space that is the same for any
kernel code. This address space becomes a liability in a world with
processor information leak vulnerabilities, such as L1TF. With the right
cache load gadget, an attacker-controlled hyperthread pair can leak
arbitrary data via
34 matches
Mail list logo
