* Song Liu <songliubrav...@fb.com> wrote:
>
>
> > On Sep 17, 2019, at 4:35 PM, Linus Torvalds <torva...@linux-foundation.org>
> > wrote:
> >
> > On Tue, Sep 17, 2019 at 4:29 PM Song Liu <songliubrav...@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
