All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Seth Jennings <sjenning@redhat.com>,
	Vojtech Pavlik <vojtech@suse.cz>,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] livepatch: x86: make kASLR logic more accurate
Date: Fri, 24 Apr 2015 16:40:38 -0500	[thread overview]
Message-ID: <20150424214038.GA27123@treble.redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1504242157480.3695@pobox.suse.cz>

On Fri, Apr 24, 2015 at 09:59:03PM +0200, Jiri Kosina wrote:
> We give up old_addr hint from the coming patch module in cases when kernel load
> base has been randomized (as in such case, the coming module has no idea about
> the exact randomization offset).
> 
> We are currently too pessimistic, and give up immediately as soon as 
> CONFIG_RANDOMIZE_BASE is set; this doesn't however directly imply that the 
> load base has actually been randomized. There are config options that 
> disable kASLR (such as hibernation), user could have disabled kaslr on 
> kernel command-line, etc.
> 
> The loader propagates the information whether kernel has been randomized 
> through bootparams. This allows us to have the condition more accurate.
> 
> On top of that, it seems unnecessary to give up old_addr hints even if 
> randomization is active. The relocation offset can be computed as 
> difference between _text start and __START_KERNEL, and therefore old_addr 
> can be adjusted accordingly.
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
> 
> v1 -> v2: I accidentally used kgr_ suffix (which we use in kGraft) instead 
> 	  of klp_ in v1.
> 
>  arch/x86/include/asm/livepatch.h | 4 ++++
>  arch/x86/kernel/livepatch.c      | 5 +++++
>  kernel/livepatch/core.c          | 5 +++--
>  3 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/livepatch.h b/arch/x86/include/asm/livepatch.h
> index 2d29197..84a3247 100644
> --- a/arch/x86/include/asm/livepatch.h
> +++ b/arch/x86/include/asm/livepatch.h
> @@ -23,8 +23,12 @@
>  
>  #include <linux/module.h>
>  #include <linux/ftrace.h>
> +#include <asm/setup.h>
>  
>  #ifdef CONFIG_LIVEPATCH
> +
> +extern unsigned long klp_vmlinux_relocation_offset(void);
> +
>  static inline int klp_check_compiler_support(void)
>  {
>  #ifndef CC_USING_FENTRY
> diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
> index ff3c3101d..6df7902 100644
> --- a/arch/x86/kernel/livepatch.c
> +++ b/arch/x86/kernel/livepatch.c
> @@ -88,3 +88,8 @@ int klp_write_module_reloc(struct module *mod, unsigned long type,
>  
>  	return ret;
>  }
> +
> +unsigned long klp_vmlinux_relocation_offset(void)
> +{
> +	return (unsigned long)&_text - __START_KERNEL;
> +}
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index 284e269..ff4c35c 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -234,8 +234,9 @@ static int klp_find_verify_func_addr(struct klp_object *obj,
>  	int ret;
>  
>  #if defined(CONFIG_RANDOMIZE_BASE)
> -	/* KASLR is enabled, disregard old_addr from user */
> -	func->old_addr = 0;
> +	/* If KASLR has been enabled, adjust old_addr accordingly */
> +	if (kaslr_enabled())
> +		func->old_addr += klp_vmlinux_relocation_offset();

The old_addr field is optional, where a value of 0 means "lookup the
address in kallsyms".  So its value should only be adjusted if old_addr
is already non-zero.  Otherwise the zero value will be replaced with a
bad address and it will mistakenly call klp_verify_vmlinux_symbol() with
the bad address instead of klp_find_object_symbol().

-- 
Josh

  reply	other threads:[~2015-04-24 21:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24 19:53 [PATCH] livepatch: x86: make kASLR logic more accurate Jiri Kosina
2015-04-24 19:59 ` [PATCH v2] " Jiri Kosina
2015-04-24 21:40   ` Josh Poimboeuf [this message]
2015-04-25 20:39     ` Jiri Kosina
2015-04-24 21:55   ` Josh Poimboeuf
2015-04-25 20:42     ` Jiri Kosina
2015-04-25  3:11   ` Minfei Huang
2015-04-25 20:44     ` Jiri Kosina

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=20150424214038.GA27123@treble.redhat.com \
    --to=jpoimboe@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=sjenning@redhat.com \
    --cc=vojtech@suse.cz \
    /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.