From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Juergen Gross <jgross@suse.com>,
Alexander Potapenko <glider@google.com>,
Marco Elver <elver@google.com>
Cc: kasan-dev <kasan-dev@googlegroups.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Subject: Re: kfence_protect_page() writing L1TF vulnerable PTE
Date: Sun, 11 Dec 2022 16:34:20 -0500 [thread overview]
Message-ID: <Y5ZM3HCnTcLvP2vy@itl-email> (raw)
In-Reply-To: <c18bc798-f484-ad66-fbb0-15192a74f8e3@suse.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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.
>
>
> 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.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmOWTNwACgkQsoi1X/+c
IsHgTA/9HGyx+vlFqwhx7sRHVbF3ZpBdZUY7WEDI6cZzIRx8Kvh2QT3ZfYXW/32t
9EUELEKDKqXMsjWozdFcs6leohZBbYozV/luoQUrm1AsavffwrxH+d84FnZFg2qh
VVh+Sd8NL15EZV9nXIqqS94uopqWKL79qmxVcSBVkfujtiI57uGFdshePGMP3I1D
RGPRB5my7A/JQFhuITiZcqbhj0h4Cm5QSQaARAOEr4XQuso+4SFPZVGSw/+vD1nG
XQ4YAvnFKy3+6oabroJ37cway7cimp6/qlEqS3YE1SaMa6q37mgsyGFobpQWbNy5
p4OkEuqlZ85p/C7g4XR+EvIJhfFovh0Wfj4fM0h78VvB8h2aHL2ckhi5vx0Snb8L
p5NLh8MFI0PDoUaUWFb4Y3tN/Ksne9MbTQSy03mnXdnT+/6LQEHFVgUC90K0N52D
R46brLZEfPsTVB+Ro3uynpbXaE7mw/IdzdAXgxRPcMQIiuRmUthWO4O9HC9DCoPz
IHgqZg8+oBn2DCqUomg8Fz/9DQzWKb24dPKyzNuOmbtL63Tk63Qy1Smxu829LtCv
5mkfNPXwT2A3PbdngNrIT9QgI7ziXwUxYBDJ7onlb8Ad6dsimQ6QHOOWilg8mY7E
jvNVYkqFD98wLeR4FuWdrA+20/0o1i2ab6afOFvyzN4lItC6mKU=
=lz1X
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2022-12-11 21:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-11 12:15 kfence_protect_page() writing L1TF vulnerable PTE Juergen Gross
2022-12-11 21:34 ` Demi Marie Obenour [this message]
2022-12-11 22:50 ` Marco Elver
2022-12-12 4:55 ` Demi Marie Obenour
2022-12-12 5:19 ` Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y5ZM3HCnTcLvP2vy@itl-email \
--to=demi@invisiblethingslab.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=jgross@suse.com \
--cc=kasan-dev@googlegroups.com \
--cc=marmarek@invisiblethingslab.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.