kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: Andrew Donnellan <ajd@linux.ibm.com>
To: "Christopher M. Riedl" <cmr@informatik.wtf>,
	linuxppc-dev@ozlabs.org, kernel-hardening@lists.openwall.com
Cc: mjg59@google.com, dja@axtens.net
Subject: Re: [RFC PATCH v2] powerpc/xmon: restrict when kernel is locked down
Date: Mon, 3 Jun 2019 15:36:05 +1000	[thread overview]
Message-ID: <81549d40-e477-6552-9a12-7200933279af@linux.ibm.com> (raw)
In-Reply-To: <20190524123816.1773-1-cmr@informatik.wtf>

On 24/5/19 10:38 pm, Christopher M. Riedl wrote:
> Xmon should be either fully or partially disabled depending on the
> kernel lockdown state.
> 
> Put xmon into read-only mode for lockdown=integrity and completely
> disable xmon when lockdown=confidentiality. Xmon checks the lockdown
> state and takes appropriate action:
> 
>   (1) during xmon_setup to prevent early xmon'ing
> 
>   (2) when triggered via sysrq
> 
>   (3) when toggled via debugfs
> 
>   (4) when triggered via a previously enabled breakpoint
> 
> The following lockdown state transitions are handled:
> 
>   (1) lockdown=none -> lockdown=integrity
>       clear all breakpoints, set xmon read-only mode
> 
>   (2) lockdown=none -> lockdown=confidentiality
>       clear all breakpoints, prevent re-entry into xmon
> 
>   (3) lockdown=integrity -> lockdown=confidentiality
>       prevent re-entry into xmon
> 
> Suggested-by: Andrew Donnellan <ajd@linux.ibm.com>
> Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf>
> ---
> 
> Applies on top of this series:
> 	https://patchwork.kernel.org/cover/10884631/
> 
> I've done some limited testing of the scenarios mentioned in the commit
> message on a single CPU QEMU config.
> 
> v1->v2:
> 	Fix subject line
> 	Submit to linuxppc-dev and kernel-hardening
> 
>   arch/powerpc/xmon/xmon.c | 56 +++++++++++++++++++++++++++++++++++++++-
>   1 file changed, 55 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 3e7be19aa208..8c4a5a0c28f0 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -191,6 +191,9 @@ static void dump_tlb_44x(void);
>   static void dump_tlb_book3e(void);
>   #endif
>   
> +static void clear_all_bpt(void);
> +static void xmon_init(int);
> +
>   #ifdef CONFIG_PPC64
>   #define REG		"%.16lx"
>   #else
> @@ -291,6 +294,39 @@ Commands:\n\
>     zh	halt\n"
>   ;
>   
> +#ifdef CONFIG_LOCK_DOWN_KERNEL
> +static bool xmon_check_lockdown(void)
> +{
> +	static bool lockdown = false;
> +
> +	if (!lockdown) {
> +		lockdown = kernel_is_locked_down("Using xmon",
> +						 LOCKDOWN_CONFIDENTIALITY);
> +		if (lockdown) {
> +			printf("xmon: Disabled by strict kernel lockdown\n");
> +			xmon_on = 0;
> +			xmon_init(0);
> +		}
> +	}
> +
> +	if (!xmon_is_ro) {
> +		xmon_is_ro = kernel_is_locked_down("Using xmon write-access",
> +						   LOCKDOWN_INTEGRITY);
> +		if (xmon_is_ro) {
> +			printf("xmon: Read-only due to kernel lockdown\n");
> +			clear_all_bpt();

Remind me again why we need to clear breakpoints in integrity mode?


Andrew


> +		}
> +	}
> +
> +	return lockdown;
> +}
> +#else
> +inline static bool xmon_check_lockdown(void)
> +{
> +	return false;
> +}
> +#endif /* CONFIG_LOCK_DOWN_KERNEL */
> +
>   static struct pt_regs *xmon_regs;
>   
>   static inline void sync(void)
> @@ -708,6 +744,9 @@ static int xmon_bpt(struct pt_regs *regs)
>   	struct bpt *bp;
>   	unsigned long offset;
>   
> +	if (xmon_check_lockdown())
> +		return 0;
> +
>   	if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
>   		return 0;
>   
> @@ -739,6 +778,9 @@ static int xmon_sstep(struct pt_regs *regs)
>   
>   static int xmon_break_match(struct pt_regs *regs)
>   {
> +	if (xmon_check_lockdown())
> +		return 0;
> +
>   	if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
>   		return 0;
>   	if (dabr.enabled == 0)
> @@ -749,6 +791,9 @@ static int xmon_break_match(struct pt_regs *regs)
>   
>   static int xmon_iabr_match(struct pt_regs *regs)
>   {
> +	if (xmon_check_lockdown())
> +		return 0;
> +
>   	if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
>   		return 0;
>   	if (iabr == NULL)
> @@ -3742,6 +3787,9 @@ static void xmon_init(int enable)
>   #ifdef CONFIG_MAGIC_SYSRQ
>   static void sysrq_handle_xmon(int key)
>   {
> +	if (xmon_check_lockdown())
> +		return;
> +
>   	/* ensure xmon is enabled */
>   	xmon_init(1);
>   	debugger(get_irq_regs());
> @@ -3763,7 +3811,6 @@ static int __init setup_xmon_sysrq(void)
>   device_initcall(setup_xmon_sysrq);
>   #endif /* CONFIG_MAGIC_SYSRQ */
>   
> -#ifdef CONFIG_DEBUG_FS
>   static void clear_all_bpt(void)
>   {
>   	int i;
> @@ -3785,8 +3832,12 @@ static void clear_all_bpt(void)
>   	printf("xmon: All breakpoints cleared\n");
>   }
>   
> +#ifdef CONFIG_DEBUG_FS
>   static int xmon_dbgfs_set(void *data, u64 val)
>   {
> +	if (xmon_check_lockdown())
> +		return 0;
> +
>   	xmon_on = !!val;
>   	xmon_init(xmon_on);
>   
> @@ -3845,6 +3896,9 @@ early_param("xmon", early_parse_xmon);
>   
>   void __init xmon_setup(void)
>   {
> +	if (xmon_check_lockdown())
> +		return;
> +
>   	if (xmon_on)
>   		xmon_init(1);
>   	if (xmon_early)
> 

-- 
Andrew Donnellan              OzLabs, ADL Canberra
ajd@linux.ibm.com             IBM Australia Limited

  reply	other threads:[~2019-06-03  5:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24 12:38 [RFC PATCH v2] powerpc/xmon: restrict when kernel is locked down Christopher M. Riedl
2019-06-03  5:36 ` Andrew Donnellan [this message]
2019-06-04  3:05   ` Christopher M Riedl
2019-06-04  3:28     ` Andrew Donnellan
2019-06-19  6:24       ` Daniel Axtens
2019-07-29  7:00         ` Daniel Axtens
2019-08-03 19:04           ` 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=81549d40-e477-6552-9a12-7200933279af@linux.ibm.com \
    --to=ajd@linux.ibm.com \
    --cc=cmr@informatik.wtf \
    --cc=dja@axtens.net \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mjg59@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).