lkml.org 
[lkml]   [2019]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT pull] x86/pti for 5.4-rc1

* Song Liu <songliubraving@fb.com> wrote:

>
>
> > On Sep 17, 2019, at 4:35 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> > On Tue, Sep 17, 2019 at 4:29 PM Song Liu <songliubraving@fb.com> wrote:
> >>
> >> How about we just do:
> >>
> >> diff --git i/arch/x86/mm/pti.c w/arch/x86/mm/pti.c
> >> index b196524759ec..0437f65250db 100644
> >> --- i/arch/x86/mm/pti.c
> >> +++ w/arch/x86/mm/pti.c
> >> @@ -341,6 +341,7 @@ pti_clone_pgtable(unsigned long start, unsigned long end,
> >> }
> >>
> >> if (pmd_large(*pmd) || level == PTI_CLONE_PMD) {
> >> + WARN_ON_ONCE(addr & ~PMD_MASK);
> >> target_pmd = pti_user_pagetable_walk_pmd(addr);
> >> if (WARN_ON(!target_pmd))
> >> return;
> >>
> >> So it is a "warn and continue" check just for unaligned PMD address.
> >
> > The problem there is that the "continue" part can be wrong.
> >
> > Admittedly it requires a pretty crazy setup: you first hit a
> > pmd_large() entry, but the *next* pmd is regular, so you start doing
> > the per-page cloning.
> >
> > And that per-page cloning will be wrong, because it will start in the
> > middle of the next pmd, because addr wasn't aligned, and the previous
> > pmd-only clone did
> >
> > addr += PMD_SIZE;
> >
> > to go to the next case.
> >
> > See?
>
> I see. This is tricky.
>
> Maybe we should skip clone of the first unaligned large pmd?
>
> diff --git i/arch/x86/mm/pti.c w/arch/x86/mm/pti.c
> index 7f2140414440..1dfa69f8196b 100644
> --- i/arch/x86/mm/pti.c
> +++ w/arch/x86/mm/pti.c
> @@ -343,6 +343,11 @@ pti_clone_pgtable(unsigned long start, unsigned long end,
> }
>
> if (pmd_large(*pmd) || level == PTI_CLONE_PMD) {
> + if (WARN_ON_ONCE(addr & ~PMD_MASK)) {
> + addr = round_up(addr, PMD_SIZE);
> + continue;
> + }
> +
> target_pmd = pti_user_pagetable_walk_pmd(addr);
> if (WARN_ON(!target_pmd))
> return;

No, we should do a proper iteration of the page table structures.

> Or we can round_down the addr and copy the whole PMD properly:
>
> diff --git i/arch/x86/mm/pti.c w/arch/x86/mm/pti.c
> index 7f2140414440..bee9881f2e85 100644
> --- i/arch/x86/mm/pti.c
> +++ w/arch/x86/mm/pti.c
> @@ -343,6 +343,9 @@ pti_clone_pgtable(unsigned long start, unsigned long end,
> }
>
> if (pmd_large(*pmd) || level == PTI_CLONE_PMD) {
> + if (WARN_ON_ONCE(addr & ~PMD_MASK))
> + addr &= PMD_MASK;
> +
> target_pmd = pti_user_pagetable_walk_pmd(addr);
> if (WARN_ON(!target_pmd))
> return;
>
> I think the latter is better, but I am not sure.

While this works, it's the wrong iterator pattern I believe.

In this function we iterate by passing in a 'random' [start,end) virtual
memory address range with no particular alignment assumptions, then look
up all pagetable entries covered by that range.

The iteration's principle is straightforward: we look up the first
address (byte granular) then continue iterating according to the observed
structure of the kernel pagetables, by skipping the range we have just
looked up:

- If the current PUD is not mapped, then we set 'addr' to the first byte
after the virtual memory range represented by the current PUD entry:

addr = round_up(addr + 1, PUD_SIZE);

- If the current PMD is not mapped, then the next byte is:

addr = round_up(addr + 1, PMD_SIZE);

The part Linus correctly pointed it is still iterating incorrectly and
might potentially be unrobust is:

addr += PMD_SIZE;

This is buggy because it doesn't step to the next byte after the current
mapped PMD, but potentially somewhere into the middle of the next
PMD-sized range of virtual memory (which might or might not be covered by
a PMD entry). The iterations after that might be similarly offset and
buggy as well.

The right fix is to *fix the address iterator*, to use the basic
principle of the function, with the same general exact calculation
pattern we use in the other cases:

addr = round_down(addr, PMD_SIZE) + PMD_SIZE;

BTW., I'd also suggest using this new round_down() pattern in the other
two cases as well:

addr = round_down(addr, PUD_SIZE) + PUD_SIZE;
...
addr = round_down(addr, PMD_SIZE) + PMD_SIZE;

Why? Because this:

addr = round_up(addr + 1, PUD_SIZE);

Will iterate incorrectly if 'addr' (which is byte granular) is the last
*byte* of a PUD range, it will incorrectly skip the next PUD range...

Is a page-unaligned address likely to be passed in to this function? With
the current users I really hope it won't happen, but it costs nothing to
use clean iterators and think through all cases - it also makes the code
more readable.

Three random nits about the pti_clone_pgtable() function:

- Could we please also fix all WARN()'s in that function to be
WARN_ONCE()? Any warning from that function is probably fatal to the
bootup anyway, and it doesn't help if we potentially spam many
warnings.

- Please add an explanation comment to why the 'BUG();' case is
unrecoverable and needs us to crash the kernel.

- Please add a comment about what the 'level' parameter does. It's non-obvious.

Thanks,

Ingo

\
 
 \ /
  Last update: 2019-09-25 08:24    [W:0.076 / U:0.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site