linux-kernel - Re: [PATCH v5 1/2] kprobes: textmem API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240327000520.ec13b2646ed1cd621e5b1d9d@kernel.org>
Date: Wed, 27 Mar 2024 00:05:20 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>
Cc: <linux-riscv@...ts.infradead.org>, "Paul Walmsley"
 <paul.walmsley@...ive.com>, "Palmer Dabbelt" <palmer@...belt.com>,
 "Albert Ou" <aou@...s.berkeley.edu>, <linux-kernel@...r.kernel.org>,
 "Luis Chamberlain" <mcgrof@...nel.org>, <linux-modules@...r.kernel.org>,
 "Naveen N . Rao" <naveen.n.rao@...ux.ibm.com>, "Anil S Keshavamurthy"
 <anil.s.keshavamurthy@...el.com>, "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH v5 1/2] kprobes: textmem API

On Tue, 26 Mar 2024 15:18:21 +0200
"Jarkko Sakkinen" <jarkko@...nel.org> wrote:

> On Tue Mar 26, 2024 at 4:01 AM EET, Jarkko Sakkinen wrote:
> > On Tue Mar 26, 2024 at 3:31 AM EET, Jarkko Sakkinen wrote:
> > > > > +#endif /* _LINUX_EXECMEM_H */
> > > > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > > > > index 9d9095e81792..87fd8c14a938 100644
> > > > > --- a/kernel/kprobes.c
> > > > > +++ b/kernel/kprobes.c
> > > > > @@ -44,6 +44,7 @@
> > > > >  #include <asm/cacheflush.h>
> > > > >  #include <asm/errno.h>
> > > > >  #include <linux/uaccess.h>
> > > > > +#include <linux/execmem.h>
> > > > >  
> > > > >  #define KPROBE_HASH_BITS 6
> > > > >  #define KPROBE_TABLE_SIZE (1 << KPROBE_HASH_BITS)
> > > > > @@ -113,17 +114,17 @@ enum kprobe_slot_state {
> > > > >  void __weak *alloc_insn_page(void)
> > > > >  {
> > > > >  	/*
> > > > > -	 * Use module_alloc() so this page is within +/- 2GB of where the
> > > > > +	 * Use alloc_execmem() so this page is within +/- 2GB of where the
> > > > >  	 * kernel image and loaded module images reside. This is required
> > > > >  	 * for most of the architectures.
> > > > >  	 * (e.g. x86-64 needs this to handle the %rip-relative fixups.)
> > > > >  	 */
> > > > > -	return module_alloc(PAGE_SIZE);
> > > > > +	return alloc_execmem(PAGE_SIZE, GFP_KERNEL);
> > > > >  }
> > > > >  
> > > > >  static void free_insn_page(void *page)
> > > > >  {
> > > > > -	module_memfree(page);
> > > > > +	free_execmem(page);
> > > > >  }
> > > > >  
> > > > >  struct kprobe_insn_cache kprobe_insn_slots = {
> > > > > @@ -1580,6 +1581,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
> > > > >  		goto out;
> > > > >  	}
> > > > >  
> > > > > +#ifdef CONFIG_MODULES
> > > >
> > > > You don't need this block, because these APIs have dummy functions.
> > >
> > > Hmm... I'll verify this tomorrow.
> >
> > It depends on having struct module available given "(*probed_mod)->state".

Ah, indeed. We need module_state() function to avoid it.

> >
> > It is non-existent unless CONFIG_MODULES is set given how things are
> > flagged in include/linux/module.h.
> 
> Hey, noticed kconfig issue.
> 
> According to kconfig-language.txt:
> 
> "select should be used with care. select will force a symbol to a value
> without visiting the dependencies."
> 
> So the problem here lies in KPROBES config entry using select statement
> to pick ALLOC_EXECMEM. It will not take the depends on statement into
> account and thus will allow to select kprobes without any allocator in
> place.

OK, in that case "depend on" is good.

> 
> So to address this I'd suggest to use depends on statement also for
> describing relation between KPROBES and ALLOC_EXECMEM. It does not make
> life worse than before for anyone because even with the current kernel
> you have to select MODULES before you can move forward with kprobes.

Yeah, since ALLOC_EXECMEM is enabled by default.

Thank you!

> 
> BR, Jarkko


-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>