From: David Laight <David.Laight@ACULAB.COM>
To: "'Josh Poimboeuf'" <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: Jan Kara <jack@suse.cz>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-arch <linux-arch@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
Fenghua Yu <fenghua.yu@intel.com>, Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>,
Tony Luck <tony.luck@intel.com>,
Andy Lutomirski <luto@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Dmitry Vyukov <dvyukov@google.com>,
Laura Abbott <labbott@fedoraproject.org>,
Brad Spengler <spender@grsecurity.net>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@kernel.org>,
"Daniel Micay" <danielmicay@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Mon, 25 Jul 2016 09:27:31 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com> (raw)
In-Reply-To: <20160722174551.jddle6mf7zlq6xmb@treble>
From: Josh Poimboeuf
> Sent: 22 July 2016 18:46
..
> > >> +/*
> > >> + * Checks if a given pointer and length is contained by the current
> > >> + * stack frame (if possible).
> > >> + *
> > >> + * 0: not at all on the stack
> > >> + * 1: fully within a valid stack frame
> > >> + * 2: fully on the stack (when can't do frame-checking)
> > >> + * -1: error condition (invalid stack position or bad stack frame)
> > >> + */
> > >> +static noinline int check_stack_object(const void *obj, unsigned long len)
> > >> +{
> > >> + const void * const stack = task_stack_page(current);
> > >> + const void * const stackend = stack + THREAD_SIZE;
> > >
> > > That allows access to the entire stack, including the struct thread_info,
> > > is that what we want - it seems dangerous? Or did I miss a check
> > > somewhere else?
> >
> > That seems like a nice improvement to make, yeah.
> >
> > > We have end_of_stack() which computes the end of the stack taking
> > > thread_info into account (end being the opposite of your end above).
> >
> > Amusingly, the object_is_on_stack() check in sched.h doesn't take
> > thread_info into account either. :P Regardless, I think using
> > end_of_stack() may not be best. To tighten the check, I think we could
> > add this after checking that the object is on the stack:
> >
> > #ifdef CONFIG_STACK_GROWSUP
> > stackend -= sizeof(struct thread_info);
> > #else
> > stack += sizeof(struct thread_info);
> > #endif
> >
> > e.g. then if the pointer was in the thread_info, the second test would
> > fail, triggering the protection.
>
> FWIW, this won't work right on x86 after Andy's
> CONFIG_THREAD_INFO_IN_TASK patches get merged.
What ends up in the 'thread_info' area?
If it contains the fp save area then programs like gdb may end up requesting
copy_in/out directly from that area.
Interestingly the avx registers don't need saving on a normal system call
entry (they are all caller-saved) so the kernel stack can safely overwrite
that area.
Syscall entry probably ought to execute the 'zero all avx registers' instruction.
They do need saving on interrupt entry - but the stack used will be less.
David
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Josh Poimboeuf' <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: Jan Kara <jack@suse.cz>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-arch <linux-arch@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
Fenghua Yu <fenghua.yu@intel.com>, Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>,
Tony Luck <tony.luck@intel.com>,
Andy Lutomirski <luto@kernel.org>, Joonsoo Kim <iamjoonsoo.kim@l>
Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Mon, 25 Jul 2016 09:27:31 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com> (raw)
In-Reply-To: <20160722174551.jddle6mf7zlq6xmb@treble>
From: Josh Poimboeuf
> Sent: 22 July 2016 18:46
..
> > >> +/*
> > >> + * Checks if a given pointer and length is contained by the current
> > >> + * stack frame (if possible).
> > >> + *
> > >> + * 0: not at all on the stack
> > >> + * 1: fully within a valid stack frame
> > >> + * 2: fully on the stack (when can't do frame-checking)
> > >> + * -1: error condition (invalid stack position or bad stack frame)
> > >> + */
> > >> +static noinline int check_stack_object(const void *obj, unsigned long len)
> > >> +{
> > >> + const void * const stack = task_stack_page(current);
> > >> + const void * const stackend = stack + THREAD_SIZE;
> > >
> > > That allows access to the entire stack, including the struct thread_info,
> > > is that what we want - it seems dangerous? Or did I miss a check
> > > somewhere else?
> >
> > That seems like a nice improvement to make, yeah.
> >
> > > We have end_of_stack() which computes the end of the stack taking
> > > thread_info into account (end being the opposite of your end above).
> >
> > Amusingly, the object_is_on_stack() check in sched.h doesn't take
> > thread_info into account either. :P Regardless, I think using
> > end_of_stack() may not be best. To tighten the check, I think we could
> > add this after checking that the object is on the stack:
> >
> > #ifdef CONFIG_STACK_GROWSUP
> > stackend -= sizeof(struct thread_info);
> > #else
> > stack += sizeof(struct thread_info);
> > #endif
> >
> > e.g. then if the pointer was in the thread_info, the second test would
> > fail, triggering the protection.
>
> FWIW, this won't work right on x86 after Andy's
> CONFIG_THREAD_INFO_IN_TASK patches get merged.
What ends up in the 'thread_info' area?
If it contains the fp save area then programs like gdb may end up requesting
copy_in/out directly from that area.
Interestingly the avx registers don't need saving on a normal system call
entry (they are all caller-saved) so the kernel stack can safely overwrite
that area.
Syscall entry probably ought to execute the 'zero all avx registers' instruction.
They do need saving on interrupt entry - but the stack used will be less.
David
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Josh Poimboeuf' <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: Jan Kara <jack@suse.cz>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-arch <linux-arch@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
Fenghua Yu <fenghua.yu@intel.com>, Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>,
Tony Luck <tony.luck@intel.com>,
Andy Lutomirski <luto@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Dmitry Vyukov <dvyukov@google.com>,
Laura Abbott <labbott@fedoraproject.org>,
Brad Spengler <spender@grsecurity.net>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@kernel.org>,
Daniel Micay <danielmicay@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Mon, 25 Jul 2016 09:27:31 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com> (raw)
In-Reply-To: <20160722174551.jddle6mf7zlq6xmb@treble>
RnJvbTogSm9zaCBQb2ltYm9ldWYNCj4gU2VudDogMjIgSnVseSAyMDE2IDE4OjQ2DQouLg0KPiA+
ID4+ICsvKg0KPiA+ID4+ICsgKiBDaGVja3MgaWYgYSBnaXZlbiBwb2ludGVyIGFuZCBsZW5ndGgg
aXMgY29udGFpbmVkIGJ5IHRoZSBjdXJyZW50DQo+ID4gPj4gKyAqIHN0YWNrIGZyYW1lIChpZiBw
b3NzaWJsZSkuDQo+ID4gPj4gKyAqDQo+ID4gPj4gKyAqICAgMDogbm90IGF0IGFsbCBvbiB0aGUg
c3RhY2sNCj4gPiA+PiArICogICAxOiBmdWxseSB3aXRoaW4gYSB2YWxpZCBzdGFjayBmcmFtZQ0K
PiA+ID4+ICsgKiAgIDI6IGZ1bGx5IG9uIHRoZSBzdGFjayAod2hlbiBjYW4ndCBkbyBmcmFtZS1j
aGVja2luZykNCj4gPiA+PiArICogICAtMTogZXJyb3IgY29uZGl0aW9uIChpbnZhbGlkIHN0YWNr
IHBvc2l0aW9uIG9yIGJhZCBzdGFjayBmcmFtZSkNCj4gPiA+PiArICovDQo+ID4gPj4gK3N0YXRp
YyBub2lubGluZSBpbnQgY2hlY2tfc3RhY2tfb2JqZWN0KGNvbnN0IHZvaWQgKm9iaiwgdW5zaWdu
ZWQgbG9uZyBsZW4pDQo+ID4gPj4gK3sNCj4gPiA+PiArICAgICBjb25zdCB2b2lkICogY29uc3Qg
c3RhY2sgPSB0YXNrX3N0YWNrX3BhZ2UoY3VycmVudCk7DQo+ID4gPj4gKyAgICAgY29uc3Qgdm9p
ZCAqIGNvbnN0IHN0YWNrZW5kID0gc3RhY2sgKyBUSFJFQURfU0laRTsNCj4gPiA+DQo+ID4gPiBU
aGF0IGFsbG93cyBhY2Nlc3MgdG8gdGhlIGVudGlyZSBzdGFjaywgaW5jbHVkaW5nIHRoZSBzdHJ1
Y3QgdGhyZWFkX2luZm8sDQo+ID4gPiBpcyB0aGF0IHdoYXQgd2Ugd2FudCAtIGl0IHNlZW1zIGRh
bmdlcm91cz8gT3IgZGlkIEkgbWlzcyBhIGNoZWNrDQo+ID4gPiBzb21ld2hlcmUgZWxzZT8NCj4g
Pg0KPiA+IFRoYXQgc2VlbXMgbGlrZSBhIG5pY2UgaW1wcm92ZW1lbnQgdG8gbWFrZSwgeWVhaC4N
Cj4gPg0KPiA+ID4gV2UgaGF2ZSBlbmRfb2Zfc3RhY2soKSB3aGljaCBjb21wdXRlcyB0aGUgZW5k
IG9mIHRoZSBzdGFjayB0YWtpbmcNCj4gPiA+IHRocmVhZF9pbmZvIGludG8gYWNjb3VudCAoZW5k
IGJlaW5nIHRoZSBvcHBvc2l0ZSBvZiB5b3VyIGVuZCBhYm92ZSkuDQo+ID4NCj4gPiBBbXVzaW5n
bHksIHRoZSBvYmplY3RfaXNfb25fc3RhY2soKSBjaGVjayBpbiBzY2hlZC5oIGRvZXNuJ3QgdGFr
ZQ0KPiA+IHRocmVhZF9pbmZvIGludG8gYWNjb3VudCBlaXRoZXIuIDpQIFJlZ2FyZGxlc3MsIEkg
dGhpbmsgdXNpbmcNCj4gPiBlbmRfb2Zfc3RhY2soKSBtYXkgbm90IGJlIGJlc3QuIFRvIHRpZ2h0
ZW4gdGhlIGNoZWNrLCBJIHRoaW5rIHdlIGNvdWxkDQo+ID4gYWRkIHRoaXMgYWZ0ZXIgY2hlY2tp
bmcgdGhhdCB0aGUgb2JqZWN0IGlzIG9uIHRoZSBzdGFjazoNCj4gPg0KPiA+ICNpZmRlZiBDT05G
SUdfU1RBQ0tfR1JPV1NVUA0KPiA+ICAgICAgICAgc3RhY2tlbmQgLT0gc2l6ZW9mKHN0cnVjdCB0
aHJlYWRfaW5mbyk7DQo+ID4gI2Vsc2UNCj4gPiAgICAgICAgIHN0YWNrICs9IHNpemVvZihzdHJ1
Y3QgdGhyZWFkX2luZm8pOw0KPiA+ICNlbmRpZg0KPiA+DQo+ID4gZS5nLiB0aGVuIGlmIHRoZSBw
b2ludGVyIHdhcyBpbiB0aGUgdGhyZWFkX2luZm8sIHRoZSBzZWNvbmQgdGVzdCB3b3VsZA0KPiA+
IGZhaWwsIHRyaWdnZXJpbmcgdGhlIHByb3RlY3Rpb24uDQo+IA0KPiBGV0lXLCB0aGlzIHdvbid0
IHdvcmsgcmlnaHQgb24geDg2IGFmdGVyIEFuZHkncw0KPiBDT05GSUdfVEhSRUFEX0lORk9fSU5f
VEFTSyBwYXRjaGVzIGdldCBtZXJnZWQuDQoNCldoYXQgZW5kcyB1cCBpbiB0aGUgJ3RocmVhZF9p
bmZvJyBhcmVhPw0KSWYgaXQgY29udGFpbnMgdGhlIGZwIHNhdmUgYXJlYSB0aGVuIHByb2dyYW1z
IGxpa2UgZ2RiIG1heSBlbmQgdXAgcmVxdWVzdGluZw0KY29weV9pbi9vdXQgZGlyZWN0bHkgZnJv
bSB0aGF0IGFyZWEuDQoNCkludGVyZXN0aW5nbHkgdGhlIGF2eCByZWdpc3RlcnMgZG9uJ3QgbmVl
ZCBzYXZpbmcgb24gYSBub3JtYWwgc3lzdGVtIGNhbGwNCmVudHJ5ICh0aGV5IGFyZSBhbGwgY2Fs
bGVyLXNhdmVkKSBzbyB0aGUga2VybmVsIHN0YWNrIGNhbiBzYWZlbHkgb3ZlcndyaXRlDQp0aGF0
IGFyZWEuDQpTeXNjYWxsIGVudHJ5IHByb2JhYmx5IG91Z2h0IHRvIGV4ZWN1dGUgdGhlICd6ZXJv
IGFsbCBhdnggcmVnaXN0ZXJzJyBpbnN0cnVjdGlvbi4NClRoZXkgZG8gbmVlZCBzYXZpbmcgb24g
aW50ZXJydXB0IGVudHJ5IC0gYnV0IHRoZSBzdGFjayB1c2VkIHdpbGwgYmUgbGVzcy4NCg0KCURh
dmlkDQoNCg=
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Josh Poimboeuf' <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: Jan Kara <jack@suse.cz>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-arch <linux-arch@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
Fenghua Yu <fenghua.yu@intel.com>, Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>,
Tony Luck <tony.luck@intel.com>,
Andy Lutomirski <luto@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Dmitry Vyukov <dvyukov@google.com>,
Laura Abbott <labbott@fedoraproject.org>,
Brad Spengler <spender@grsecurity.net>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@kernel.org>,
"Daniel Micay" <danielmicay@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Mon, 25 Jul 2016 09:27:31 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com> (raw)
In-Reply-To: <20160722174551.jddle6mf7zlq6xmb@treble>
RnJvbTogSm9zaCBQb2ltYm9ldWYNCj4gU2VudDogMjIgSnVseSAyMDE2IDE4OjQ2DQouLg0KPiA+
ID4+ICsvKg0KPiA+ID4+ICsgKiBDaGVja3MgaWYgYSBnaXZlbiBwb2ludGVyIGFuZCBsZW5ndGgg
aXMgY29udGFpbmVkIGJ5IHRoZSBjdXJyZW50DQo+ID4gPj4gKyAqIHN0YWNrIGZyYW1lIChpZiBw
b3NzaWJsZSkuDQo+ID4gPj4gKyAqDQo+ID4gPj4gKyAqICAgMDogbm90IGF0IGFsbCBvbiB0aGUg
c3RhY2sNCj4gPiA+PiArICogICAxOiBmdWxseSB3aXRoaW4gYSB2YWxpZCBzdGFjayBmcmFtZQ0K
PiA+ID4+ICsgKiAgIDI6IGZ1bGx5IG9uIHRoZSBzdGFjayAod2hlbiBjYW4ndCBkbyBmcmFtZS1j
aGVja2luZykNCj4gPiA+PiArICogICAtMTogZXJyb3IgY29uZGl0aW9uIChpbnZhbGlkIHN0YWNr
IHBvc2l0aW9uIG9yIGJhZCBzdGFjayBmcmFtZSkNCj4gPiA+PiArICovDQo+ID4gPj4gK3N0YXRp
YyBub2lubGluZSBpbnQgY2hlY2tfc3RhY2tfb2JqZWN0KGNvbnN0IHZvaWQgKm9iaiwgdW5zaWdu
ZWQgbG9uZyBsZW4pDQo+ID4gPj4gK3sNCj4gPiA+PiArICAgICBjb25zdCB2b2lkICogY29uc3Qg
c3RhY2sgPSB0YXNrX3N0YWNrX3BhZ2UoY3VycmVudCk7DQo+ID4gPj4gKyAgICAgY29uc3Qgdm9p
ZCAqIGNvbnN0IHN0YWNrZW5kID0gc3RhY2sgKyBUSFJFQURfU0laRTsNCj4gPiA+DQo+ID4gPiBU
aGF0IGFsbG93cyBhY2Nlc3MgdG8gdGhlIGVudGlyZSBzdGFjaywgaW5jbHVkaW5nIHRoZSBzdHJ1
Y3QgdGhyZWFkX2luZm8sDQo+ID4gPiBpcyB0aGF0IHdoYXQgd2Ugd2FudCAtIGl0IHNlZW1zIGRh
bmdlcm91cz8gT3IgZGlkIEkgbWlzcyBhIGNoZWNrDQo+ID4gPiBzb21ld2hlcmUgZWxzZT8NCj4g
Pg0KPiA+IFRoYXQgc2VlbXMgbGlrZSBhIG5pY2UgaW1wcm92ZW1lbnQgdG8gbWFrZSwgeWVhaC4N
Cj4gPg0KPiA+ID4gV2UgaGF2ZSBlbmRfb2Zfc3RhY2soKSB3aGljaCBjb21wdXRlcyB0aGUgZW5k
IG9mIHRoZSBzdGFjayB0YWtpbmcNCj4gPiA+IHRocmVhZF9pbmZvIGludG8gYWNjb3VudCAoZW5k
IGJlaW5nIHRoZSBvcHBvc2l0ZSBvZiB5b3VyIGVuZCBhYm92ZSkuDQo+ID4NCj4gPiBBbXVzaW5n
bHksIHRoZSBvYmplY3RfaXNfb25fc3RhY2soKSBjaGVjayBpbiBzY2hlZC5oIGRvZXNuJ3QgdGFr
ZQ0KPiA+IHRocmVhZF9pbmZvIGludG8gYWNjb3VudCBlaXRoZXIuIDpQIFJlZ2FyZGxlc3MsIEkg
dGhpbmsgdXNpbmcNCj4gPiBlbmRfb2Zfc3RhY2soKSBtYXkgbm90IGJlIGJlc3QuIFRvIHRpZ2h0
ZW4gdGhlIGNoZWNrLCBJIHRoaW5rIHdlIGNvdWxkDQo+ID4gYWRkIHRoaXMgYWZ0ZXIgY2hlY2tp
bmcgdGhhdCB0aGUgb2JqZWN0IGlzIG9uIHRoZSBzdGFjazoNCj4gPg0KPiA+ICNpZmRlZiBDT05G
SUdfU1RBQ0tfR1JPV1NVUA0KPiA+ICAgICAgICAgc3RhY2tlbmQgLT0gc2l6ZW9mKHN0cnVjdCB0
aHJlYWRfaW5mbyk7DQo+ID4gI2Vsc2UNCj4gPiAgICAgICAgIHN0YWNrICs9IHNpemVvZihzdHJ1
Y3QgdGhyZWFkX2luZm8pOw0KPiA+ICNlbmRpZg0KPiA+DQo+ID4gZS5nLiB0aGVuIGlmIHRoZSBw
b2ludGVyIHdhcyBpbiB0aGUgdGhyZWFkX2luZm8sIHRoZSBzZWNvbmQgdGVzdCB3b3VsZA0KPiA+
IGZhaWwsIHRyaWdnZXJpbmcgdGhlIHByb3RlY3Rpb24uDQo+IA0KPiBGV0lXLCB0aGlzIHdvbid0
IHdvcmsgcmlnaHQgb24geDg2IGFmdGVyIEFuZHkncw0KPiBDT05GSUdfVEhSRUFEX0lORk9fSU5f
VEFTSyBwYXRjaGVzIGdldCBtZXJnZWQuDQoNCldoYXQgZW5kcyB1cCBpbiB0aGUgJ3RocmVhZF9p
bmZvJyBhcmVhPw0KSWYgaXQgY29udGFpbnMgdGhlIGZwIHNhdmUgYXJlYSB0aGVuIHByb2dyYW1z
IGxpa2UgZ2RiIG1heSBlbmQgdXAgcmVxdWVzdGluZw0KY29weV9pbi9vdXQgZGlyZWN0bHkgZnJv
bSB0aGF0IGFyZWEuDQoNCkludGVyZXN0aW5nbHkgdGhlIGF2eCByZWdpc3RlcnMgZG9uJ3QgbmVl
ZCBzYXZpbmcgb24gYSBub3JtYWwgc3lzdGVtIGNhbGwNCmVudHJ5ICh0aGV5IGFyZSBhbGwgY2Fs
bGVyLXNhdmVkKSBzbyB0aGUga2VybmVsIHN0YWNrIGNhbiBzYWZlbHkgb3ZlcndyaXRlDQp0aGF0
IGFyZWEuDQpTeXNjYWxsIGVudHJ5IHByb2JhYmx5IG91Z2h0IHRvIGV4ZWN1dGUgdGhlICd6ZXJv
IGFsbCBhdnggcmVnaXN0ZXJzJyBpbnN0cnVjdGlvbi4NClRoZXkgZG8gbmVlZCBzYXZpbmcgb24g
aW50ZXJydXB0IGVudHJ5IC0gYnV0IHRoZSBzdGFjayB1c2VkIHdpbGwgYmUgbGVzcy4NCg0KCURh
dmlkDQoNCg==
WARNING: multiple messages have this Message-ID (diff)
From: David.Laight@ACULAB.COM (David Laight)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 02/11] mm: Hardened usercopy
Date: Mon, 25 Jul 2016 09:27:31 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com> (raw)
In-Reply-To: <20160722174551.jddle6mf7zlq6xmb@treble>
From: Josh Poimboeuf
> Sent: 22 July 2016 18:46
..
> > >> +/*
> > >> + * Checks if a given pointer and length is contained by the current
> > >> + * stack frame (if possible).
> > >> + *
> > >> + * 0: not at all on the stack
> > >> + * 1: fully within a valid stack frame
> > >> + * 2: fully on the stack (when can't do frame-checking)
> > >> + * -1: error condition (invalid stack position or bad stack frame)
> > >> + */
> > >> +static noinline int check_stack_object(const void *obj, unsigned long len)
> > >> +{
> > >> + const void * const stack = task_stack_page(current);
> > >> + const void * const stackend = stack + THREAD_SIZE;
> > >
> > > That allows access to the entire stack, including the struct thread_info,
> > > is that what we want - it seems dangerous? Or did I miss a check
> > > somewhere else?
> >
> > That seems like a nice improvement to make, yeah.
> >
> > > We have end_of_stack() which computes the end of the stack taking
> > > thread_info into account (end being the opposite of your end above).
> >
> > Amusingly, the object_is_on_stack() check in sched.h doesn't take
> > thread_info into account either. :P Regardless, I think using
> > end_of_stack() may not be best. To tighten the check, I think we could
> > add this after checking that the object is on the stack:
> >
> > #ifdef CONFIG_STACK_GROWSUP
> > stackend -= sizeof(struct thread_info);
> > #else
> > stack += sizeof(struct thread_info);
> > #endif
> >
> > e.g. then if the pointer was in the thread_info, the second test would
> > fail, triggering the protection.
>
> FWIW, this won't work right on x86 after Andy's
> CONFIG_THREAD_INFO_IN_TASK patches get merged.
What ends up in the 'thread_info' area?
If it contains the fp save area then programs like gdb may end up requesting
copy_in/out directly from that area.
Interestingly the avx registers don't need saving on a normal system call
entry (they are all caller-saved) so the kernel stack can safely overwrite
that area.
Syscall entry probably ought to execute the 'zero all avx registers' instruction.
They do need saving on interrupt entry - but the stack used will be less.
David
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Josh Poimboeuf' <jpoimboe@redhat.com>,
Kees Cook <keescook@chromium.org>
Cc: Jan Kara <jack@suse.cz>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Will Deacon <will.deacon@arm.com>, Linux-MM <linux-mm@kvack.org>,
sparclinux <sparclinux@vger.kernel.org>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-arch <linux-arch@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
PaX Team <pageexec@freemail.hu>, Borislav Petkov <bp@suse.de>,
Mathias Krause <minipli@googlemail.com>,
Fenghua Yu <fenghua.yu@intel.com>, Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>,
Tony Luck <tony.luck@intel.com>,
Andy Lutomirski <luto@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Dmitry Vyukov <dvyukov@google.com>,
Laura Abbott <labbott@fedoraproject.org>,
Brad Spengler <spender@grsecurity.net>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@kernel.org>,
Daniel Micay <danielmicay@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: [kernel-hardening] RE: [PATCH v3 02/11] mm: Hardened usercopy
Date: Mon, 25 Jul 2016 09:27:31 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com> (raw)
In-Reply-To: <20160722174551.jddle6mf7zlq6xmb@treble>
From: Josh Poimboeuf
> Sent: 22 July 2016 18:46
..
> > >> +/*
> > >> + * Checks if a given pointer and length is contained by the current
> > >> + * stack frame (if possible).
> > >> + *
> > >> + * 0: not at all on the stack
> > >> + * 1: fully within a valid stack frame
> > >> + * 2: fully on the stack (when can't do frame-checking)
> > >> + * -1: error condition (invalid stack position or bad stack frame)
> > >> + */
> > >> +static noinline int check_stack_object(const void *obj, unsigned long len)
> > >> +{
> > >> + const void * const stack = task_stack_page(current);
> > >> + const void * const stackend = stack + THREAD_SIZE;
> > >
> > > That allows access to the entire stack, including the struct thread_info,
> > > is that what we want - it seems dangerous? Or did I miss a check
> > > somewhere else?
> >
> > That seems like a nice improvement to make, yeah.
> >
> > > We have end_of_stack() which computes the end of the stack taking
> > > thread_info into account (end being the opposite of your end above).
> >
> > Amusingly, the object_is_on_stack() check in sched.h doesn't take
> > thread_info into account either. :P Regardless, I think using
> > end_of_stack() may not be best. To tighten the check, I think we could
> > add this after checking that the object is on the stack:
> >
> > #ifdef CONFIG_STACK_GROWSUP
> > stackend -= sizeof(struct thread_info);
> > #else
> > stack += sizeof(struct thread_info);
> > #endif
> >
> > e.g. then if the pointer was in the thread_info, the second test would
> > fail, triggering the protection.
>
> FWIW, this won't work right on x86 after Andy's
> CONFIG_THREAD_INFO_IN_TASK patches get merged.
What ends up in the 'thread_info' area?
If it contains the fp save area then programs like gdb may end up requesting
copy_in/out directly from that area.
Interestingly the avx registers don't need saving on a normal system call
entry (they are all caller-saved) so the kernel stack can safely overwrite
that area.
Syscall entry probably ought to execute the 'zero all avx registers' instruction.
They do need saving on interrupt entry - but the stack used will be less.
David
next prev parent reply other threads:[~2016-07-25 9:29 UTC|newest]
Thread overview: 257+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-15 21:44 [PATCH v3 00/11] mm: Hardened usercopy Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 01/11] mm: Implement stack frame object validation Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 02/11] mm: Hardened usercopy Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-19 1:06 ` Laura Abbott
2016-07-19 1:06 ` [kernel-hardening] " Laura Abbott
2016-07-19 1:06 ` Laura Abbott
2016-07-19 1:06 ` Laura Abbott
2016-07-19 1:06 ` Laura Abbott
2016-07-19 1:06 ` Laura Abbott
2016-07-19 18:48 ` Kees Cook
2016-07-19 18:48 ` [kernel-hardening] " Kees Cook
2016-07-19 18:48 ` Kees Cook
2016-07-19 18:48 ` Kees Cook
2016-07-19 18:48 ` Kees Cook
2016-07-19 18:48 ` Kees Cook
2016-07-19 18:48 ` Kees Cook
2016-07-19 22:00 ` [PATCH] mm: Add is_migrate_cma_page Laura Abbott
2016-07-19 22:00 ` [kernel-hardening] " Laura Abbott
2016-07-19 22:00 ` Laura Abbott
2016-07-19 22:00 ` Laura Abbott
2016-07-19 22:00 ` Laura Abbott
2016-07-19 22:00 ` Laura Abbott
2016-07-19 22:40 ` Kees Cook
2016-07-19 22:40 ` [kernel-hardening] " Kees Cook
2016-07-19 22:40 ` Kees Cook
2016-07-19 22:40 ` Kees Cook
2016-07-19 22:40 ` Kees Cook
2016-07-19 22:40 ` Kees Cook
2016-07-19 22:40 ` Kees Cook
2016-07-20 10:24 ` [PATCH v3 02/11] mm: Hardened usercopy Balbir Singh
2016-07-20 10:24 ` [kernel-hardening] " Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 10:24 ` Balbir Singh
2016-07-20 15:36 ` Laura Abbott
2016-07-20 15:36 ` [kernel-hardening] " Laura Abbott
2016-07-20 15:36 ` Laura Abbott
2016-07-20 15:36 ` Laura Abbott
2016-07-20 15:36 ` Laura Abbott
2016-07-20 15:36 ` Laura Abbott
2016-07-20 15:36 ` Laura Abbott
2016-07-19 1:52 ` Laura Abbott
2016-07-19 1:52 ` [kernel-hardening] " Laura Abbott
2016-07-19 1:52 ` Laura Abbott
2016-07-19 1:52 ` Laura Abbott
2016-07-19 1:52 ` Laura Abbott
2016-07-19 1:52 ` Laura Abbott
2016-07-19 19:12 ` Kees Cook
2016-07-19 19:12 ` [kernel-hardening] " Kees Cook
2016-07-19 19:12 ` Kees Cook
2016-07-19 19:12 ` Kees Cook
2016-07-19 19:12 ` Kees Cook
2016-07-19 19:12 ` Kees Cook
2016-07-19 19:12 ` Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 22:55 ` [kernel-hardening] " Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 22:55 ` Kees Cook
2016-07-19 9:21 ` Christian Borntraeger
2016-07-19 9:21 ` [kernel-hardening] " Christian Borntraeger
2016-07-19 9:21 ` Christian Borntraeger
2016-07-19 9:21 ` Christian Borntraeger
2016-07-19 9:21 ` Christian Borntraeger
2016-07-19 9:21 ` Christian Borntraeger
2016-07-19 19:31 ` Kees Cook
2016-07-19 19:31 ` [kernel-hardening] " Kees Cook
2016-07-19 19:31 ` Kees Cook
2016-07-19 19:31 ` Kees Cook
2016-07-19 19:31 ` Kees Cook
2016-07-19 19:31 ` Kees Cook
2016-07-19 19:31 ` Kees Cook
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:14 ` [kernel-hardening] " Christian Borntraeger
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:14 ` Christian Borntraeger
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:34 ` [kernel-hardening] " Kees Cook
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:34 ` Kees Cook
2016-07-19 20:44 ` Christian Borntraeger
2016-07-19 20:44 ` [kernel-hardening] " Christian Borntraeger
2016-07-19 20:44 ` Christian Borntraeger
2016-07-19 20:44 ` Christian Borntraeger
2016-07-19 20:44 ` Christian Borntraeger
2016-07-19 20:44 ` Christian Borntraeger
2016-07-19 20:44 ` Christian Borntraeger
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` [kernel-hardening] " Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
2016-07-21 6:52 ` Michael Ellerman
[not found] ` <5790711f.2350420a.b4287.2cc0SMTPIN_ADDED_BROKEN@mx.google.com>
2016-07-21 18:34 ` Kees Cook
2016-07-21 18:34 ` [kernel-hardening] " Kees Cook
2016-07-21 18:34 ` Kees Cook
2016-07-21 18:34 ` Kees Cook
2016-07-21 18:34 ` Kees Cook
2016-07-21 18:34 ` Kees Cook
2016-07-21 18:34 ` Kees Cook
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-22 17:45 ` [kernel-hardening] " Josh Poimboeuf
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-22 17:45 ` Josh Poimboeuf
2016-07-25 9:27 ` David Laight [this message]
2016-07-25 9:27 ` [kernel-hardening] " David Laight
2016-07-25 9:27 ` David Laight
2016-07-25 9:27 ` David Laight
2016-07-25 9:27 ` David Laight
2016-07-25 9:27 ` David Laight
2016-07-25 9:27 ` David Laight
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` [kernel-hardening] " Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:09 ` Michael Ellerman
2016-07-26 2:03 ` Michael Ellerman
2016-07-26 2:03 ` [kernel-hardening] " Michael Ellerman
2016-07-26 2:03 ` Michael Ellerman
2016-07-26 2:03 ` Michael Ellerman
2016-07-26 4:46 ` Kees Cook
2016-07-26 4:46 ` [kernel-hardening] " Kees Cook
2016-07-26 4:46 ` Kees Cook
2016-07-26 4:46 ` Kees Cook
2016-07-26 4:46 ` Kees Cook
2016-07-26 4:46 ` Kees Cook
2016-07-26 4:46 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 03/11] x86/uaccess: Enable hardened usercopy Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 04/11] ARM: uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 05/11] arm64/uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 06/11] ia64/uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 07/11] powerpc/uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 08/11] sparc/uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 09/11] s390/uaccess: " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 10/11] mm: SLAB hardened usercopy support Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` [PATCH v3 11/11] mm: SLUB " Kees Cook
2016-07-15 21:44 ` [kernel-hardening] " Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-15 21:44 ` Kees Cook
2016-07-18 8:26 ` [PATCH v3 00/11] mm: Hardened usercopy Balbir Singh
2016-07-18 8:26 ` [kernel-hardening] " Balbir Singh
2016-07-18 8:26 ` Balbir Singh
2016-07-18 8:26 ` Balbir Singh
2016-07-18 8:26 ` Balbir Singh
2016-07-18 8:26 ` Balbir Singh
2016-07-18 8:26 ` Balbir Singh
2016-07-20 9:52 ` David Laight
2016-07-20 9:52 ` [kernel-hardening] " David Laight
2016-07-20 9:52 ` David Laight
2016-07-20 9:52 ` David Laight
2016-07-20 9:52 ` David Laight
2016-07-20 9:52 ` David Laight
2016-07-20 9:52 ` David Laight
2016-07-20 15:31 ` Kees Cook
2016-07-20 15:31 ` [kernel-hardening] " Kees Cook
2016-07-20 15:31 ` Kees Cook
2016-07-20 15:31 ` Kees Cook
2016-07-20 15:31 ` Kees Cook
2016-07-20 15:31 ` Kees Cook
2016-07-20 15:31 ` Kees Cook
2016-07-20 16:02 ` David Laight
2016-07-20 16:02 ` [kernel-hardening] " David Laight
2016-07-20 16:02 ` David Laight
2016-07-20 16:02 ` David Laight
2016-07-20 16:02 ` David Laight
2016-07-20 16:02 ` David Laight
2016-07-20 16:02 ` David Laight
2016-07-20 16:22 ` Rik van Riel
2016-07-20 16:22 ` [kernel-hardening] " Rik van Riel
2016-07-20 16:22 ` Rik van Riel
2016-07-20 16:22 ` Rik van Riel
2016-07-20 16:22 ` Rik van Riel
2016-07-20 16:22 ` Rik van Riel
2016-07-20 17:44 ` Kees Cook
2016-07-20 17:44 ` [kernel-hardening] " Kees Cook
2016-07-20 17:44 ` Kees Cook
2016-07-20 17:44 ` Kees Cook
2016-07-20 17:44 ` Kees Cook
2016-07-20 17:44 ` Kees Cook
2016-07-20 17:44 ` Kees Cook
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=063D6719AE5E284EB5DD2968C1650D6D5F502102@AcuExch.aculab.com \
--to=david.laight@aculab.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=bp@suse.de \
--cc=casey@schaufler-ca.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=danielmicay@gmail.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=fenghua.yu@intel.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jack@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@fedoraproject.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=minipli@googlemail.com \
--cc=pageexec@freemail.hu \
--cc=penberg@kernel.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
--cc=sparclinux@vger.kernel.org \
--cc=spender@grsecurity.net \
--cc=tony.luck@intel.com \
--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.