On Fri, Jan 05, 2018 at 11:51:38PM -0800, Dave Hansen wrote:
> On 01/05/2018 10:28 PM, Hanjun Guo wrote:
> >> +
> >>p4d = p4d_alloc(&tboot_mm, pgd, vaddr);
> > Seems pgd will be re-set after p4d_alloc(), so should
> > we put the code behind (or after pud_alloc())?
Thanks Dave and Jiri for thes
On 2018/1/6 15:55, Dave Hansen wrote:
> On 01/05/2018 10:53 PM, Hanjun Guo wrote:
>>> + /*
>>> + * PTI poisons low addresses in the kernel page tables in the
>>> + * name of making them unusable for userspace. To execute
>>> + * code at such a low address, the poison must be cleared.
>>
On 01/05/2018 10:53 PM, Hanjun Guo wrote:
>> + /*
>> +* PTI poisons low addresses in the kernel page tables in the
>> +* name of making them unusable for userspace. To execute
>> +* code at such a low address, the poison must be cleared.
>> +*/
>> + pgd->pgd &= ~_PAGE_NX;
On 01/05/2018 10:28 PM, Hanjun Guo wrote:
>> +
>> p4d = p4d_alloc(&tboot_mm, pgd, vaddr);
> Seems pgd will be re-set after p4d_alloc(), so should
> we put the code behind (or after pud_alloc())?
Yes, it has to go below where the PGD actually gets set which is
after pud_alloc(). You can put
On 2018/1/6 14:28, Hanjun Guo wrote:
> Hi Dave,
>
> Thank you very much for the quick response! Minor comments inline.
>
> On 2018/1/6 14:06, Dave Hansen wrote:
>> On 01/05/2018 08:54 PM, Hanjun Guo wrote:
>>> Do you mean NX bit will be brought back later? I'm asking this because
>>> I tested thi
Hi Dave,
Thank you very much for the quick response! Minor comments inline.
On 2018/1/6 14:06, Dave Hansen wrote:
> On 01/05/2018 08:54 PM, Hanjun Guo wrote:
>> Do you mean NX bit will be brought back later? I'm asking this because
>> I tested this patch which it fixed the boot panic issue but th
On 01/05/2018 08:54 PM, Hanjun Guo wrote:
> Do you mean NX bit will be brought back later? I'm asking this because
> I tested this patch which it fixed the boot panic issue but the system
> will hang when rebooting the system, because rebooting will also call efi
> then panic as NS bit is set.
Wow
Hi Jiri,
Thanks for the fix, comments inline.
On 2018/1/6 2:19, Jiri Kosina wrote:
>
> [ adding Hugh ]
>
> On Thu, 4 Jan 2018, Dave Hansen wrote:
>
>>> BTW, we have just reported a bug caused by kaiser[1], which looks like
>>> caused by SMEP. Could you please help to have a look?
>>>
>>> [1] h
On Fri, Jan 5, 2018 at 1:14 PM, Jiri Kosina wrote:
> On Fri, 5 Jan 2018, Dave Hansen wrote:
>
>> >>> --- a/arch/x86/platform/efi/efi_64.c
>> >>> +++ b/arch/x86/platform/efi/efi_64.c
>> >>> @@ -95,6 +95,12 @@ pgd_t * __init efi_call_phys_prolog(void
>> >>> save_pgd[pgd] = *pgd_offset_k(pg
> On Jan 5, 2018, at 1:14 PM, Jiri Kosina wrote:
>
> On Fri, 5 Jan 2018, Dave Hansen wrote:
>
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -95,6 +95,12 @@ pgd_t * __init efi_call_phys_prolog(void
>save_pgd[pgd] = *pgd_offset_k(pgd *
On Fri, 5 Jan 2018, Dave Hansen wrote:
> >>> --- a/arch/x86/platform/efi/efi_64.c
> >>> +++ b/arch/x86/platform/efi/efi_64.c
> >>> @@ -95,6 +95,12 @@ pgd_t * __init efi_call_phys_prolog(void
> >>> save_pgd[pgd] = *pgd_offset_k(pgd * PGDIR_SIZE);
> >>> vaddress = (unsigned long)
On 01/05/2018 11:17 AM, Jiri Kosina wrote:
> On Fri, 5 Jan 2018, Dave Hansen wrote:
>
>>> --- a/arch/x86/platform/efi/efi_64.c
>>> +++ b/arch/x86/platform/efi/efi_64.c
>>> @@ -95,6 +95,12 @@ pgd_t * __init efi_call_phys_prolog(void
>>> save_pgd[pgd] = *pgd_offset_k(pgd * PGDIR_SIZE);
>
On Fri, Jan 05, 2018 at 08:17:17PM +0100, Jiri Kosina wrote:
> On Fri, 5 Jan 2018, Dave Hansen wrote:
>
> > > --- a/arch/x86/platform/efi/efi_64.c
> > > +++ b/arch/x86/platform/efi/efi_64.c
> > > @@ -95,6 +95,12 @@ pgd_t * __init efi_call_phys_prolog(void
> > > save_pgd[pgd] = *pgd_offse
On Fri, 5 Jan 2018, Jiri Kosina wrote:
> That's because pgd_populate() uses _PAGE_TABLE and not _KERNPG_TABLE for
> reasons that are behind me.
[ oh and BTW I find the fact that we have populate_pgd() and
pgd_populate(), which do something *completely* different quite
entertaining ]
--
Jiri
On Fri, 5 Jan 2018, Dave Hansen wrote:
> > --- a/arch/x86/platform/efi/efi_64.c
> > +++ b/arch/x86/platform/efi/efi_64.c
> > @@ -95,6 +95,12 @@ pgd_t * __init efi_call_phys_prolog(void
> > save_pgd[pgd] = *pgd_offset_k(pgd * PGDIR_SIZE);
> > vaddress = (unsigned long)__va(p
On 01/05/2018 10:19 AM, Jiri Kosina wrote:
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -95,6 +95,12 @@ pgd_t * __init efi_call_phys_prolog(void
> save_pgd[pgd] = *pgd_offset_k(pgd * PGDIR_SIZE);
> vaddress = (unsigned long)__va(pgd
The previous patch was for slightly older kernel, and the logic in
_prologue() is a bit different in 4.15, but the (cofirmed) fix for
mainline is basically the same:
From: Jiri Kosina
Subject: [PATCH] PTI: unbreak EFI old_memmap
old_memmap's efi_call_phys_prolog() calls set_pgd() with swappe
[ adding Hugh ]
On Thu, 4 Jan 2018, Dave Hansen wrote:
> > BTW, we have just reported a bug caused by kaiser[1], which looks like
> > caused by SMEP. Could you please help to have a look?
> >
> > [1] https://lkml.org/lkml/2018/1/5/3
>
> Please report that to your kernel vendor. Your EFI page
Hi Yisheng and Dave,
On Thu, Jan 04, 2018 at 10:29:53PM -0800, Dave Hansen wrote:
> On 01/04/2018 10:16 PM, Yisheng Xie wrote:
> > BTW, we have just reported a bug caused by kaiser[1], which looks like
> > caused by SMEP. Could you please help to have a look?
> >
> > [1] https://lkml.org/lkml/201
On 01/04/2018 10:16 PM, Yisheng Xie wrote:
> BTW, we have just reported a bug caused by kaiser[1], which looks like
> caused by SMEP. Could you please help to have a look?
>
> [1] https://lkml.org/lkml/2018/1/5/3
Please report that to your kernel vendor. Your EFI page tables have the
NX bit set
Hi Dave,
On 2018/1/5 13:18, Dave Hansen wrote:
> On 01/04/2018 08:16 PM, Yisheng Xie wrote:
>>> === Page Table Poisoning ===
>>>
>>> KAISER has two copies of the page tables: one for the kernel and
>>> one for when running in userspace.
>>
>> So, we have 2 page table, thinking about this case:
>
On 01/04/2018 08:16 PM, Yisheng Xie wrote:
>> === Page Table Poisoning ===
>>
>> KAISER has two copies of the page tables: one for the kernel and
>> one for when running in userspace.
>
> So, we have 2 page table, thinking about this case:
> If _ONE_ process includes _TWO_ threads, one run in us
Hi Dava,
On 2017/11/23 8:34, Dave Hansen wrote:
>
> From: Dave Hansen
>
> These patches are based on work from a team at Graz University of
> Technology: https://github.com/IAIK/KAISER . This work would not have
> been possible without their work as a starting point.
>
> KAISER is a counterme
On Sun, Nov 26, 2017 at 8:24 AM, Dave Hansen
wrote:
> On 11/26/2017 08:10 AM, Andy Lutomirski wrote:
>>> As a side benefit, this shouldn't have magical interactions with the
>>> vsyscall page any more.
>>>
>>> Are there cases that this would get wrong?
>>>
>> Quick ping: did this get lost?
>
> It
On 11/26/2017 08:10 AM, Andy Lutomirski wrote:
>> As a side benefit, this shouldn't have magical interactions with the
>> vsyscall page any more.
>>
>> Are there cases that this would get wrong?
>>
> Quick ping: did this get lost?
It does drop a warning that the other version of the code has, but
On Wed, Nov 22, 2017 at 8:07 PM, Andy Lutomirski wrote:
> On Wed, Nov 22, 2017 at 4:34 PM, Dave Hansen
> wrote:
>>
>> These actions when dealing with a user address *and* the
>> PGD has _PAGE_USER set. That way, in-kernel users of low addresses
>> typically used by userspace are not accidentally
On Wed, Nov 22, 2017 at 4:34 PM, Dave Hansen
wrote:
>
> These actions when dealing with a user address *and* the
> PGD has _PAGE_USER set. That way, in-kernel users of low addresses
> typically used by userspace are not accidentally poisoned.
This seems sane.
> +/*
> + * Take a PGD location (pg
From: Dave Hansen
These patches are based on work from a team at Graz University of
Technology: https://github.com/IAIK/KAISER . This work would not have
been possible without their work as a starting point.
KAISER is a countermeasure against side channel attacks against kernel
virtual memory.
28 matches
Mail list logo