From: Kees Cook <keescook@chromium.org>
To: "Christopher M. Riedl" <cmr@linux.ibm.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
linuxppc-dev@lists.ozlabs.org, peterz@infradead.org,
x86@kernel.org, npiggin@gmail.com,
linux-hardening@vger.kernel.org, tglx@linutronix.de,
dja@axtens.net
Subject: Re: [PATCH v5 2/8] lkdtm/powerpc: Add test to hijack a patch mapping
Date: Wed, 11 Aug 2021 11:07:34 -0700 [thread overview]
Message-ID: <202108111057.CC6F897@keescook> (raw)
In-Reply-To: <CDGVLP8OS8N9.13R0RIGJ1WJ8R@oc8246131445.ibm.com>
On Wed, Aug 11, 2021 at 12:57:00PM -0500, Christopher M. Riedl wrote:
> On Thu Aug 5, 2021 at 4:13 AM CDT, Christophe Leroy wrote:
> >
> >
> > Le 13/07/2021 à 07:31, Christopher M. Riedl a écrit :
> > > When live patching with STRICT_KERNEL_RWX the CPU doing the patching
> > > must temporarily remap the page(s) containing the patch site with +W
> > > permissions. While this temporary mapping is in use, another CPU could
> > > write to the same mapping and maliciously alter kernel text. Implement a
> > > LKDTM test to attempt to exploit such an opening during code patching.
> > > The test is implemented on powerpc and requires LKDTM built into the
> > > kernel (building LKDTM as a module is insufficient).
> > >
> > > The LKDTM "hijack" test works as follows:
> > >
> > > 1. A CPU executes an infinite loop to patch an instruction. This is
> > > the "patching" CPU.
> > > 2. Another CPU attempts to write to the address of the temporary
> > > mapping used by the "patching" CPU. This other CPU is the
> > > "hijacker" CPU. The hijack either fails with a fault/error or
> > > succeeds, in which case some kernel text is now overwritten.
> > > [...]
> > > +#if (IS_BUILTIN(CONFIG_LKDTM) && defined(CONFIG_STRICT_KERNEL_RWX) && \
> > > + defined(CONFIG_PPC))
> >
> > I think this test shouldn't be limited to CONFIG_PPC and shouldn't be
> > limited to CONFIG_STRICT_KERNEL_RWX. It should be there all the time.
Agreed: if the machinery exists to provide this defense on even one
arch/config/whatever combo, I'd like LKDTM to test for it. This lets use
compare defenses across different combinations more easily, and means
folks must answer questions like "why doesn't $combination provide
$defense?"
> > Also why limiting it to IS_BUILTIN(CONFIG_LKDTM) ?
>
> The test needs read_cpu_patching_addr() which definitely cannot be
> exposed outside of the kernel (ie. builtin).
FWIW, I'm okay with this. There isn't a solution that feels entirely
"right", so either a build-time requirement like this, or using an
exception for modules like this:
arch/x86/kernel/cpu/common.c:#if IS_MODULE(CONFIG_LKDTM)
arch/x86/kernel/cpu/common.c-EXPORT_SYMBOL_GPL(native_write_cr4);
arch/x86/kernel/cpu/common.c-#endif
I think neither is great. Another idea is maybe using a name-spaced
export, like:
EXPORT_SYMBOL_NS_GPL(native_write_cr4, LKDTM);
But that still means it gets exposed to malicious discovery, so probably
not.
I suspect the best is to just do the BUILTIN check, since building LKDTM
as a module on a _production_ kernel is rare if it exists at all. The
only downside is needing to completely reboot to perform updated tests,
but then, I frequently find myself breaking the kernel badly on bad
tests, so I have to reboot anyway. ;)
-Kees
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: "Christopher M. Riedl" <cmr@linux.ibm.com>
Cc: peterz@infradead.org, x86@kernel.org, npiggin@gmail.com,
tglx@linutronix.de, dja@axtens.net,
linuxppc-dev@lists.ozlabs.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v5 2/8] lkdtm/powerpc: Add test to hijack a patch mapping
Date: Wed, 11 Aug 2021 11:07:34 -0700 [thread overview]
Message-ID: <202108111057.CC6F897@keescook> (raw)
In-Reply-To: <CDGVLP8OS8N9.13R0RIGJ1WJ8R@oc8246131445.ibm.com>
On Wed, Aug 11, 2021 at 12:57:00PM -0500, Christopher M. Riedl wrote:
> On Thu Aug 5, 2021 at 4:13 AM CDT, Christophe Leroy wrote:
> >
> >
> > Le 13/07/2021 à 07:31, Christopher M. Riedl a écrit :
> > > When live patching with STRICT_KERNEL_RWX the CPU doing the patching
> > > must temporarily remap the page(s) containing the patch site with +W
> > > permissions. While this temporary mapping is in use, another CPU could
> > > write to the same mapping and maliciously alter kernel text. Implement a
> > > LKDTM test to attempt to exploit such an opening during code patching.
> > > The test is implemented on powerpc and requires LKDTM built into the
> > > kernel (building LKDTM as a module is insufficient).
> > >
> > > The LKDTM "hijack" test works as follows:
> > >
> > > 1. A CPU executes an infinite loop to patch an instruction. This is
> > > the "patching" CPU.
> > > 2. Another CPU attempts to write to the address of the temporary
> > > mapping used by the "patching" CPU. This other CPU is the
> > > "hijacker" CPU. The hijack either fails with a fault/error or
> > > succeeds, in which case some kernel text is now overwritten.
> > > [...]
> > > +#if (IS_BUILTIN(CONFIG_LKDTM) && defined(CONFIG_STRICT_KERNEL_RWX) && \
> > > + defined(CONFIG_PPC))
> >
> > I think this test shouldn't be limited to CONFIG_PPC and shouldn't be
> > limited to CONFIG_STRICT_KERNEL_RWX. It should be there all the time.
Agreed: if the machinery exists to provide this defense on even one
arch/config/whatever combo, I'd like LKDTM to test for it. This lets use
compare defenses across different combinations more easily, and means
folks must answer questions like "why doesn't $combination provide
$defense?"
> > Also why limiting it to IS_BUILTIN(CONFIG_LKDTM) ?
>
> The test needs read_cpu_patching_addr() which definitely cannot be
> exposed outside of the kernel (ie. builtin).
FWIW, I'm okay with this. There isn't a solution that feels entirely
"right", so either a build-time requirement like this, or using an
exception for modules like this:
arch/x86/kernel/cpu/common.c:#if IS_MODULE(CONFIG_LKDTM)
arch/x86/kernel/cpu/common.c-EXPORT_SYMBOL_GPL(native_write_cr4);
arch/x86/kernel/cpu/common.c-#endif
I think neither is great. Another idea is maybe using a name-spaced
export, like:
EXPORT_SYMBOL_NS_GPL(native_write_cr4, LKDTM);
But that still means it gets exposed to malicious discovery, so probably
not.
I suspect the best is to just do the BUILTIN check, since building LKDTM
as a module on a _production_ kernel is rare if it exists at all. The
only downside is needing to completely reboot to perform updated tests,
but then, I frequently find myself breaking the kernel badly on bad
tests, so I have to reboot anyway. ;)
-Kees
--
Kees Cook
next prev parent reply other threads:[~2021-08-11 18:07 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-13 5:31 [PATCH v5 0/8] Use per-CPU temporary mappings for patching on Radix MMU Christopher M. Riedl
2021-07-13 5:31 ` Christopher M. Riedl
2021-07-13 5:31 ` [PATCH v5 1/8] powerpc: Add LKDTM accessor for patching addr Christopher M. Riedl
2021-07-13 5:31 ` Christopher M. Riedl
2021-07-13 5:31 ` [PATCH v5 2/8] lkdtm/powerpc: Add test to hijack a patch mapping Christopher M. Riedl
2021-07-13 5:31 ` Christopher M. Riedl
2021-08-05 9:13 ` Christophe Leroy
2021-08-11 17:57 ` Christopher M. Riedl
2021-08-11 17:57 ` Christopher M. Riedl
2021-08-11 18:07 ` Kees Cook [this message]
2021-08-11 18:07 ` Kees Cook
2021-07-13 5:31 ` [PATCH v5 3/8] x86_64: Add LKDTM accessor for patching addr Christopher M. Riedl
2021-07-13 5:31 ` Christopher M. Riedl
2021-07-13 5:31 ` [PATCH v5 4/8] lkdtm/x86_64: Add test to hijack a patch mapping Christopher M. Riedl
2021-07-13 5:31 ` Christopher M. Riedl
2021-08-05 9:09 ` Christophe Leroy
2021-08-11 17:53 ` Christopher M. Riedl
2021-08-11 17:53 ` Christopher M. Riedl
2021-07-13 5:31 ` [PATCH v5 5/8] powerpc/64s: Introduce temporary mm for Radix MMU Christopher M. Riedl
2021-07-13 5:31 ` Christopher M. Riedl
2021-08-05 9:27 ` Christophe Leroy
2021-08-11 18:02 ` Christopher M. Riedl
2021-08-11 18:02 ` Christopher M. Riedl
2021-07-13 5:31 ` [PATCH v5 6/8] powerpc: Rework and improve STRICT_KERNEL_RWX patching Christopher M. Riedl
2021-07-13 5:31 ` Christopher M. Riedl
2021-08-05 9:34 ` Christophe Leroy
2021-08-11 18:10 ` Christopher M. Riedl
2021-08-11 18:10 ` Christopher M. Riedl
2021-07-13 5:31 ` [PATCH v5 7/8] powerpc/64s: Initialize and use a temporary mm for patching on Radix Christopher M. Riedl
2021-07-13 5:31 ` Christopher M. Riedl
2021-08-05 9:48 ` Christophe Leroy
2021-08-11 18:28 ` Christopher M. Riedl
2021-08-11 18:28 ` Christopher M. Riedl
2021-07-13 5:31 ` [PATCH v5 8/8] lkdtm/powerpc: Fix code patching hijack test Christopher M. Riedl
2021-07-13 5:31 ` Christopher M. Riedl
2021-08-05 9:18 ` Christophe Leroy
2021-08-11 17:57 ` Christopher M. Riedl
2021-08-11 17:57 ` Christopher M. Riedl
2021-08-05 9:03 ` [PATCH v5 0/8] Use per-CPU temporary mappings for patching on Radix MMU Christophe Leroy
2021-08-11 17:49 ` Christopher M. Riedl
2021-08-11 17:49 ` Christopher M. Riedl
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=202108111057.CC6F897@keescook \
--to=keescook@chromium.org \
--cc=christophe.leroy@csgroup.eu \
--cc=cmr@linux.ibm.com \
--cc=dja@axtens.net \
--cc=linux-hardening@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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.