Re: kfence_protect_page() writing L1TF vulnerable PTE

[Marco Elver <elver@xxxxxxxxxx>]

On Sun, 11 Dec 2022 at 22:34, Demi Marie Obenour
<demi@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, Dec 11, 2022 at 01:15:06PM +0100, Juergen Gross wrote:
> > During tests with QubesOS a problem was found which seemed to be related
> > to kfence_protect_page() writing a L1TF vulnerable page table entry [1].
> >
> > Looking into the function I'm seeing:
> >
> >       set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT));
> >
> > I don't think this can be correct, as keeping the PFN unmodified and
> > just removing the _PAGE_PRESENT bit is wrong regarding L1TF.
> >
> > There should be at least the highest PFN bit set in order to be L1TF
> > safe.

Could you elaborate what we want to be safe from?

KFENCE is only for kernel memory, i.e. slab allocations. The
page-protection mechanism is used to detect memory safety bugs in the
Linux kernel. The page protection does not prevent or mitigate any
such bugs because KFENCE only samples sl[au]b allocations. Normal slab
allocations never change the page protection bits; KFENCE merely uses
them to receive a page fault, upon which we determine either a
use-after-free or out-of-bounds access. After a bug is detected,
KFENCE unprotects the page so that the kernel can proceed "as normal"
given that's the state of things if it had been a normal sl[au]b
allocation.

https://docs.kernel.org/dev-tools/kfence.html

>From [1] I see: "If an instruction accesses a virtual address for
which the relevant page table entry (PTE) has the Present bit cleared
or other reserved bits set, then speculative execution ignores the
invalid PTE and loads the referenced data if it is present in the
Level 1 Data Cache, as if the page referenced by the address bits in
the PTE was still present and accessible."

[1] https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html

This is perfectly fine in the context of KFENCE, as stated above, the
page protection is merely used to detect out-of-bounds and
use-after-free bugs of sampled slab allocations. KFENCE does not
mitigate nor prevent such bugs, because it samples allocations, i.e.
most allocations are still serviced by sl[au]b.

How can we teach whatever is complaining about L1TF on that KFENCE PTE
modification that KFENCE does not use page protection to stop anyone
from accessing that memory?

> >
> > Juergen
> >
> > [1]: https://github.com/QubesOS/qubes-issues/issues/7935
>
> Does that mean that Linux with kfence enabled is vulnerable to L1TF?  Or
> are these pages ones that are not in any userspace page tables?  If the
> former, then this is a security vulnerability in Linux and must be
> fixed.  If the latter, then the two options I can think of are to revert
> whatever change caused kfence to produce L1TF-vulnerable PTEs, or to
> disable kfence when running paravirtualized under Xen.

See above - it's for kernel memory only, and the page protection is
only to detect bugs of _sampled_ slab allocations.

Thanks,
-- Marco