From: rick.p.edgecombe@intel.com (Edgecombe, Rick P)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/7] arm64/modules: Add rlimit checking for arm64 modules
Date: Fri, 12 Oct 2018 22:01:45 +0000 [thread overview]
Message-ID: <a89e6d7bbcfba2ebaad927fac0da131ded59aa28.camel@intel.com> (raw)
In-Reply-To: <20181012143254.idy65qbvaaw5k3ge@linux-8ccs>
On Fri, 2018-10-12 at 16:32 +0200, Jessica Yu wrote:
> +++ Dave Hansen [11/10/18 16:47 -0700]:
> > On 10/11/2018 04:31 PM, Rick Edgecombe wrote:
> > > + if (check_inc_mod_rlimit(size))
> > > + return NULL;
> > > +
> > > p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> > > module_alloc_base + MODULES_VSIZE,
> > > gfp_mask, PAGE_KERNEL_EXEC, 0,
> > > @@ -65,6 +68,8 @@ void *module_alloc(unsigned long size)
> > > return NULL;
> > > }
> > >
> > > + update_mod_rlimit(p, size);
> >
> > Is there a reason we couldn't just rename all of the existing per-arch
> > module_alloc() calls to be called, say, "arch_module_alloc()", then put
> > this new rlimit code in a generic helper that does:
> >
> >
> > if (check_inc_mod_rlimit(size))
> > return NULL;
> >
> > p = arch_module_alloc(...);
> >
> > ...
> >
> > update_mod_rlimit(p, size);
> >
>
> I second this suggestion. Just make module_{alloc,memfree} generic,
> non-weak functions that call the rlimit helpers in addition to the
> arch-specific arch_module_{alloc,memfree} functions.
>
> Jessica
Ok, thanks. I am going to try another version of this with just a system wide
BPF JIT limit based on the problems Jann brought up. I think it would be nice to
have a module space limit, but as far as I know the only way today un-privlidged
users could fill the space is from BPF JIT. Unless you see another purpose long
term?
Rick
next prev parent reply other threads:[~2018-10-12 22:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 23:31 [PATCH v2 0/7] Rlimit for module space Rick Edgecombe
2018-10-11 23:31 ` [PATCH v2 1/7] modules: Create rlimit " Rick Edgecombe
2018-10-12 0:35 ` Jann Horn
2018-10-12 17:04 ` Edgecombe, Rick P
2018-10-12 17:22 ` Jann Horn
2018-10-13 0:04 ` Edgecombe, Rick P
2018-10-13 0:09 ` Jann Horn
2018-10-23 11:32 ` Michal Hocko
2018-10-12 18:23 ` Jann Horn
2018-10-11 23:31 ` [PATCH v2 2/7] x86/modules: Add rlimit checking for x86 modules Rick Edgecombe
2018-10-11 23:31 ` [PATCH v2 3/7] arm/modules: Add rlimit checking for arm modules Rick Edgecombe
2018-10-11 23:31 ` [PATCH v2 4/7] arm64/modules: Add rlimit checking for arm64 modules Rick Edgecombe
2018-10-11 23:47 ` Dave Hansen
2018-10-12 14:32 ` Jessica Yu
2018-10-12 22:01 ` Edgecombe, Rick P [this message]
2018-10-12 22:54 ` Edgecombe, Rick P
2018-10-11 23:31 ` [PATCH v2 5/7] mips/modules: Add rlimit checking for mips modules Rick Edgecombe
2018-10-11 23:31 ` [PATCH v2 6/7] sparc/modules: Add rlimit for sparc modules Rick Edgecombe
2018-10-11 23:31 ` [PATCH v2 7/7] s390/modules: Add rlimit checking for s390 modules Rick Edgecombe
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=a89e6d7bbcfba2ebaad927fac0da131ded59aa28.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=linux-arm-kernel@lists.infradead.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 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).