All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "jannh@google.com" <jannh@google.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"jeyu@kernel.org" <jeyu@kernel.org>,
	"arjan@linux.intel.com" <arjan@linux.intel.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"kristen@linux.intel.com" <kristen@linux.intel.com>,
	"Dock, Deneen T" <deneen.t.dock@intel.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>
Subject: Re: [PATCH v2 1/7] modules: Create rlimit for module space
Date: Sat, 13 Oct 2018 00:04:14 +0000	[thread overview]
Message-ID: <657e6d0ada18e8ca0350bc6b3a80c49b3c0b341c.camel@intel.com> (raw)
In-Reply-To: <CAG48ez0XfGFAWDYa75COMPCsKqqGfBFOtcNuGD4_dubGf2YeAQ@mail.gmail.com>

On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote:
> On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P
> <rick.p.edgecombe@intel.com> wrote:
> > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> > > Why all the rbtree stuff instead of stashing a pointer in struct
> > > vmap_area, or something like that?
> > 
> > Since the tracking was not for all vmalloc usage, the intention was to not
> > bloat
> > the structure for other usages likes stacks. I thought usually there
> > wouldn't be
> > nearly as much module space allocations as there would be kernel stacks, but
> > I
> > didn't do any actual measurements on the tradeoffs.
> 
> I imagine that one extra pointer in there - pointing to your struct
> mod_alloc_user - would probably not be terrible. 8 bytes more per
> kernel stack shouldn't be so bad?

I looked into this and it starts to look a little messy. The nommu.c version of
vmalloc doesn't use or expose access to vmap_area or vm_struct. So it starts to
look like a bunch of IFDEFs to remove the rlimit in the nommu case or making a
stand in that maintains pretend vm struct's in nommu.c. I had actually
previously tried to at least pull the allocations size from vmalloc structs, but it broke on nommu.

Thought I would check back and see. How important do you think this is?



WARNING: multiple messages have this Message-ID (diff)
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "jannh@google.com" <jannh@google.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"jeyu@kernel.org" <jeyu@kernel.org>,
	"arjan@linux.intel.com" <arjan@linux.intel.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"kristen@linux.intel.com" <kristen@linux.intel.com>,
	"Dock, Deneen T" <deneen.t.dock@intel.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v2 1/7] modules: Create rlimit for module space
Date: Sat, 13 Oct 2018 00:04:14 +0000	[thread overview]
Message-ID: <657e6d0ada18e8ca0350bc6b3a80c49b3c0b341c.camel@intel.com> (raw)
In-Reply-To: <CAG48ez0XfGFAWDYa75COMPCsKqqGfBFOtcNuGD4_dubGf2YeAQ@mail.gmail.com>

On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote:
> On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P
> <rick.p.edgecombe@intel.com> wrote:
> > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> > > Why all the rbtree stuff instead of stashing a pointer in struct
> > > vmap_area, or something like that?
> > 
> > Since the tracking was not for all vmalloc usage, the intention was to not
> > bloat
> > the structure for other usages likes stacks. I thought usually there
> > wouldn't be
> > nearly as much module space allocations as there would be kernel stacks, but
> > I
> > didn't do any actual measurements on the tradeoffs.
> 
> I imagine that one extra pointer in there - pointing to your struct
> mod_alloc_user - would probably not be terrible. 8 bytes more per
> kernel stack shouldn't be so bad?

I looked into this and it starts to look a little messy. The nommu.c version of
vmalloc doesn't use or expose access to vmap_area or vm_struct. So it starts to
look like a bunch of IFDEFs to remove the rlimit in the nommu case or making a
stand in that maintains pretend vm struct's in nommu.c. I had actually
previously tried to at least pull the allocations size from vmalloc structs, but it broke on nommu.

Thought I would check back and see. How important do you think this is?



WARNING: multiple messages have this Message-ID (diff)
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "jannh@google.com" <jannh@google.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"daniel@iogearbox.net" <daniel@iogearbox.net>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"jeyu@kernel.org" <jeyu@kernel.org>,
	"arjan@linux.intel.com" <arjan@linux.intel.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"kristen@linux.intel.com" <kristen@linux.intel.com>,
	"Dock, Deneen T" <deneen.t.dock@intel.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>
Subject: Re: [PATCH v2 1/7] modules: Create rlimit for module space
Date: Sat, 13 Oct 2018 00:04:14 +0000	[thread overview]
Message-ID: <657e6d0ada18e8ca0350bc6b3a80c49b3c0b341c.camel@intel.com> (raw)
In-Reply-To: <CAG48ez0XfGFAWDYa75COMPCsKqqGfBFOtcNuGD4_dubGf2YeAQ@mail.gmail.com>

T24gRnJpLCAyMDE4LTEwLTEyIGF0IDE5OjIyICswMjAwLCBKYW5uIEhvcm4gd3JvdGU6DQo+IE9u
IEZyaSwgT2N0IDEyLCAyMDE4IGF0IDc6MDQgUE0gRWRnZWNvbWJlLCBSaWNrIFANCj4gPHJpY2su
cC5lZGdlY29tYmVAaW50ZWwuY29tPiB3cm90ZToNCj4gPiBPbiBGcmksIDIwMTgtMTAtMTIgYXQg
MDI6MzUgKzAyMDAsIEphbm4gSG9ybiB3cm90ZToNCj4gPiA+IFdoeSBhbGwgdGhlIHJidHJlZSBz
dHVmZiBpbnN0ZWFkIG9mIHN0YXNoaW5nIGEgcG9pbnRlciBpbiBzdHJ1Y3QNCj4gPiA+IHZtYXBf
YXJlYSwgb3Igc29tZXRoaW5nIGxpa2UgdGhhdD8NCj4gPiANCj4gPiBTaW5jZSB0aGUgdHJhY2tp
bmcgd2FzIG5vdCBmb3IgYWxsIHZtYWxsb2MgdXNhZ2UsIHRoZSBpbnRlbnRpb24gd2FzIHRvIG5v
dA0KPiA+IGJsb2F0DQo+ID4gdGhlIHN0cnVjdHVyZSBmb3Igb3RoZXIgdXNhZ2VzIGxpa2VzIHN0
YWNrcy4gSSB0aG91Z2h0IHVzdWFsbHkgdGhlcmUNCj4gPiB3b3VsZG4ndCBiZQ0KPiA+IG5lYXJs
eSBhcyBtdWNoIG1vZHVsZSBzcGFjZSBhbGxvY2F0aW9ucyBhcyB0aGVyZSB3b3VsZCBiZSBrZXJu
ZWwgc3RhY2tzLCBidXQNCj4gPiBJDQo+ID4gZGlkbid0IGRvIGFueSBhY3R1YWwgbWVhc3VyZW1l
bnRzIG9uIHRoZSB0cmFkZW9mZnMuDQo+IA0KPiBJIGltYWdpbmUgdGhhdCBvbmUgZXh0cmEgcG9p
bnRlciBpbiB0aGVyZSAtIHBvaW50aW5nIHRvIHlvdXIgc3RydWN0DQo+IG1vZF9hbGxvY191c2Vy
IC0gd291bGQgcHJvYmFibHkgbm90IGJlIHRlcnJpYmxlLiA4IGJ5dGVzIG1vcmUgcGVyDQo+IGtl
cm5lbCBzdGFjayBzaG91bGRuJ3QgYmUgc28gYmFkPw0KDQpJIGxvb2tlZCBpbnRvIHRoaXMgYW5k
IGl0IHN0YXJ0cyB0byBsb29rIGEgbGl0dGxlIG1lc3N5LiBUaGUgbm9tbXUuYyB2ZXJzaW9uIG9m
DQp2bWFsbG9jIGRvZXNuJ3QgdXNlIG9yIGV4cG9zZSBhY2Nlc3MgdG8gdm1hcF9hcmVhIG9yIHZt
X3N0cnVjdC4gU28gaXQgc3RhcnRzIHRvDQpsb29rIGxpa2UgYSBidW5jaCBvZiBJRkRFRnMgdG8g
cmVtb3ZlIHRoZSBybGltaXQgaW4gdGhlIG5vbW11IGNhc2Ugb3IgbWFraW5nIGENCnN0YW5kIGlu
IHRoYXQgbWFpbnRhaW5zIHByZXRlbmQgdm0gc3RydWN0J3MgaW4gbm9tbXUuYy4gSSBoYWQgYWN0
dWFsbHkNCnByZXZpb3VzbHkgdHJpZWQgdG8gYXQgbGVhc3QgcHVsbCB0aGUgYWxsb2NhdGlvbnMg
c2l6ZSBmcm9tIHZtYWxsb2Mgc3RydWN0cywgYnV0IGl0IGJyb2tlIG9uIG5vbW11Lg0KDQpUaG91
Z2h0IEkgd291bGQgY2hlY2sgYmFjayBhbmQgc2VlLiBIb3cgaW1wb3J0YW50IGRvIHlvdSB0aGlu
ayB0aGlzIGlzPw0KDQoNCg=

WARNING: multiple messages have this Message-ID (diff)
From: rick.p.edgecombe@intel.com (Edgecombe, Rick P)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/7] modules: Create rlimit for module space
Date: Sat, 13 Oct 2018 00:04:14 +0000	[thread overview]
Message-ID: <657e6d0ada18e8ca0350bc6b3a80c49b3c0b341c.camel@intel.com> (raw)
In-Reply-To: <CAG48ez0XfGFAWDYa75COMPCsKqqGfBFOtcNuGD4_dubGf2YeAQ@mail.gmail.com>

On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote:
> On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P
> <rick.p.edgecombe@intel.com> wrote:
> > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> > > Why all the rbtree stuff instead of stashing a pointer in struct
> > > vmap_area, or something like that?
> > 
> > Since the tracking was not for all vmalloc usage, the intention was to not
> > bloat
> > the structure for other usages likes stacks. I thought usually there
> > wouldn't be
> > nearly as much module space allocations as there would be kernel stacks, but
> > I
> > didn't do any actual measurements on the tradeoffs.
> 
> I imagine that one extra pointer in there - pointing to your struct
> mod_alloc_user - would probably not be terrible. 8 bytes more per
> kernel stack shouldn't be so bad?

I looked into this and it starts to look a little messy. The nommu.c version of
vmalloc doesn't use or expose access to vmap_area or vm_struct. So it starts to
look like a bunch of IFDEFs to remove the rlimit in the nommu case or making a
stand in that maintains pretend vm struct's in nommu.c. I had actually
previously tried to at least pull the allocations size from vmalloc structs, but it broke on nommu.

Thought I would check back and see. How important do you think this is?

  reply	other threads:[~2018-10-13  0:04 UTC|newest]

Thread overview: 70+ 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 ` Rick Edgecombe
2018-10-11 23:31 ` Rick Edgecombe
2018-10-11 23:31 ` [PATCH v2 1/7] modules: Create rlimit " Rick Edgecombe
2018-10-11 23:31   ` Rick Edgecombe
2018-10-11 23:31   ` Rick Edgecombe
2018-10-12  0:35   ` Jann Horn
2018-10-12  0:35     ` Jann Horn
2018-10-12  0:35     ` Jann Horn
2018-10-12 17:04     ` Edgecombe, Rick P
2018-10-12 17:04       ` Edgecombe, Rick P
2018-10-12 17:04       ` Edgecombe, Rick P
2018-10-12 17:04       ` Edgecombe, Rick P
2018-10-12 17:04       ` Edgecombe, Rick P
2018-10-12 17:22       ` Jann Horn
2018-10-12 17:22         ` Jann Horn
2018-10-12 17:22         ` Jann Horn
2018-10-12 17:22         ` Jann Horn
2018-10-13  0:04         ` Edgecombe, Rick P [this message]
2018-10-13  0:04           ` Edgecombe, Rick P
2018-10-13  0:04           ` Edgecombe, Rick P
2018-10-13  0:04           ` Edgecombe, Rick P
2018-10-13  0:04           ` Edgecombe, Rick P
2018-10-13  0:09           ` Jann Horn
2018-10-13  0:09             ` Jann Horn
2018-10-13  0:09             ` Jann Horn
2018-10-13  0:09             ` Jann Horn
2018-10-23 11:32       ` Michal Hocko
2018-10-23 11:32         ` Michal Hocko
2018-10-23 11:32         ` Michal Hocko
2018-10-23 11:32         ` Michal Hocko
2018-10-23 11:32         ` Michal Hocko
2018-10-12 18:23     ` Jann Horn
2018-10-12 18:23       ` Jann Horn
2018-10-12 18:23       ` Jann Horn
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   ` Rick Edgecombe
2018-10-11 23:31   ` 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   ` Rick Edgecombe
2018-10-11 23:31   ` 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:31   ` Rick Edgecombe
2018-10-11 23:31   ` Rick Edgecombe
2018-10-11 23:47   ` Dave Hansen
2018-10-11 23:47     ` Dave Hansen
2018-10-11 23:47     ` Dave Hansen
2018-10-12 14:32     ` Jessica Yu
2018-10-12 14:32       ` Jessica Yu
2018-10-12 14:32       ` Jessica Yu
2018-10-12 22:01       ` Edgecombe, Rick P
2018-10-12 22:01         ` Edgecombe, Rick P
2018-10-12 22:01         ` Edgecombe, Rick P
2018-10-12 22:01         ` Edgecombe, Rick P
2018-10-12 22:01         ` Edgecombe, Rick P
2018-10-12 22:54         ` Edgecombe, Rick P
2018-10-12 22:54           ` Edgecombe, Rick P
2018-10-12 22:54           ` Edgecombe, Rick P
2018-10-12 22:54           ` Edgecombe, Rick P
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   ` Rick Edgecombe
2018-10-11 23:31   ` 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   ` Rick Edgecombe
2018-10-11 23:31   ` Rick Edgecombe
2018-10-11 23:31 ` [PATCH v2 7/7] s390/modules: Add rlimit checking for s390 modules Rick Edgecombe
2018-10-11 23:31   ` Rick Edgecombe
2018-10-11 23:31   ` 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=657e6d0ada18e8ca0350bc6b3a80c49b3c0b341c.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=arjan@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@intel.com \
    --cc=davem@davemloft.net \
    --cc=deneen.t.dock@intel.com \
    --cc=jannh@google.com \
    --cc=jeyu@kernel.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kristen@linux.intel.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    --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.