All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Ilya Smith <blackzert@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com,
	vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com,
	fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org,
	Helge Deller <deller@gmx.de>,
	benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	x86@kernel.org, nyc@holomorphy.com, viro@zeniv.linux.org.uk,
	arnd@arndb.de, gregkh@linuxfoundation.org,
	deepa.kernel@gmail.com, Hugh Dickins <hughd@google.com>,
	kstewart@linuxfoundation.org, pombredanne@nexb.com,
	Andrew Morton <akpm@linux-foundation.org>,
	steve.capper@arm.com, punit.agrawal@arm.com,
	aneesh.kumar@linux.vnet.ibm.com, npiggin@gmail.com,
	Kees Cook <keescook@chromium.org>,
	bhsharma@redhat.com, riel@redhat.com, nitin.m.gupta@oracle.com,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>, Jan Kara <jack@suse.cz>,
	ross.zwisler@linux.intel.com, Jerome Glisse <jglisse@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-alpha@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-metag@vger.kernel.org, linux-mips@linux-mips.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, Linux-MM <linux-mm@kvack.org>
Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
Date: Tue, 27 Mar 2018 14:38:20 +0000	[thread overview]
Message-ID: <20180327143820.GH5652@dhcp22.suse.cz> (raw)
In-Reply-To: <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com>

On Tue 27-03-18 16:51:08, Ilya Smith wrote:
> 
> > On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
> > 
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >> 
> >>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >>> 
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>>> 
> >>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>>> 
> >>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>>>> Current implementation doesn't randomize address returned by mmap.
> >>>>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>>>> creation. After that mmap build very predictable layout of address
> >>>>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>>>> randomization of address on any mmap call.
> >>>>> 
> >>>>> Why should this be done in the kernel rather than libc?  libc is perfectly
> >>>>> capable of specifying random numbers in the first argument of mmap.
> >>>> Well, there is following reasons:
> >>>> 1. It should be done in any libc implementation, what is not possible IMO;
> >>> 
> >>> Is this really so helpful?
> >> 
> >> Yes, ASLR is one of very important mitigation techniques which are really used 
> >> to protect applications. If there is no ASLR, it is very easy to exploit 
> >> vulnerable application and compromise the system. We can’t just fix all the 
> >> vulnerabilities right now, thats why we have mitigations - techniques which are 
> >> makes exploitation more hard or impossible in some cases.
> >> 
> >> Thats why it is helpful.
> > 
> > I am not questioning ASLR in general. I am asking whether we really need
> > per mmap ASLR in general. I can imagine that some environments want to
> > pay the additional price and other side effects, but considering this
> > can be achieved by libc, why to add more code to the kernel?
> 
> I believe this is the only one right place for it. Adding these 200+ lines of 
> code we give this feature for any user - on desktop, on server, on IoT device, 
> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA 
> devices will never get it.

I guess it would really help if you could be more specific about the
class of security issues this would help to mitigate. My first
understanding was that we we need some randomization between program
executable segments to reduce the attack space when a single address
leaks and you know the segments layout (ordering). But why do we need
_all_ mmaps to be randomized. Because that complicates the
implementation consirably for different reasons you have mentioned
earlier.

Do you have any specific CVE that would be mitigated by this
randomization approach?

I am sorry, I am not a security expert to see all the cosequences but a
vague - the more randomization the better - sounds rather weak to me.
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Ilya Smith <blackzert@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com,
	vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com,
	fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org,
	Helge Deller <deller@gmx.de>,
	benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	x86@kernel.org, nyc@holomorphy.com, viro@zeniv.linux.org.uk,
	arnd@arndb.de, gregkh@linuxfoundation.org,
	deepa.kernel@gmail.com, Hugh Dickins <hughd@google.com>,
	kstewart@linuxfoundation.org, pombredanne@nexb.com,
	Andrew Morton <akpm@linux-foundation.org>,
	steve.capper@arm.com, punit.agrawal@arm.
Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
Date: Tue, 27 Mar 2018 16:38:20 +0200	[thread overview]
Message-ID: <20180327143820.GH5652@dhcp22.suse.cz> (raw)
In-Reply-To: <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com>

On Tue 27-03-18 16:51:08, Ilya Smith wrote:
> 
> > On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
> > 
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >> 
> >>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >>> 
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>>> 
> >>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>>> 
> >>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>>>> Current implementation doesn't randomize address returned by mmap.
> >>>>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>>>> creation. After that mmap build very predictable layout of address
> >>>>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>>>> randomization of address on any mmap call.
> >>>>> 
> >>>>> Why should this be done in the kernel rather than libc?  libc is perfectly
> >>>>> capable of specifying random numbers in the first argument of mmap.
> >>>> Well, there is following reasons:
> >>>> 1. It should be done in any libc implementation, what is not possible IMO;
> >>> 
> >>> Is this really so helpful?
> >> 
> >> Yes, ASLR is one of very important mitigation techniques which are really used 
> >> to protect applications. If there is no ASLR, it is very easy to exploit 
> >> vulnerable application and compromise the system. We can’t just fix all the 
> >> vulnerabilities right now, thats why we have mitigations - techniques which are 
> >> makes exploitation more hard or impossible in some cases.
> >> 
> >> Thats why it is helpful.
> > 
> > I am not questioning ASLR in general. I am asking whether we really need
> > per mmap ASLR in general. I can imagine that some environments want to
> > pay the additional price and other side effects, but considering this
> > can be achieved by libc, why to add more code to the kernel?
> 
> I believe this is the only one right place for it. Adding these 200+ lines of 
> code we give this feature for any user - on desktop, on server, on IoT device, 
> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA 
> devices will never get it.

I guess it would really help if you could be more specific about the
class of security issues this would help to mitigate. My first
understanding was that we we need some randomization between program
executable segments to reduce the attack space when a single address
leaks and you know the segments layout (ordering). But why do we need
_all_ mmaps to be randomized. Because that complicates the
implementation consirably for different reasons you have mentioned
earlier.

Do you have any specific CVE that would be mitigated by this
randomization approach?

I am sorry, I am not a security expert to see all the cosequences but a
vague - the more randomization the better - sounds rather weak to me.
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Ilya Smith <blackzert@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com,
	vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com,
	fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org,
	Helge Deller <deller@gmx.de>,
	benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	x86@kernel.org, nyc@holomorphy.com, viro@zeniv.linux.org.uk,
	arnd@arndb.de, gregkh@linuxfoundation.org,
	deepa.kernel@gmail.com, Hugh Dickins <hughd@google.com>,
	kstewart@linuxfoundation.org, pombredanne@nexb.com,
	Andrew Morton <akpm@linux-foundation.org>,
	steve.capper@arm.com, punit.agrawal@arm.com,
	aneesh.kumar@linux.vnet.ibm.com, npiggin@gmail.com,
	Kees Cook <keescook@chromium.org>,
	bhsharma@redhat.com, riel@redhat.com, nitin.m.gupta@oracle.com,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>, Jan Kara <jack@suse.cz>,
	ross.zwisler@linux.intel.com, Jerome Glisse <jglisse@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-alpha@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-metag@vger.kernel.org, linux-mips@linux-mips.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, Linux-MM <linux-mm@kvack.org>
Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
Date: Tue, 27 Mar 2018 16:38:20 +0200	[thread overview]
Message-ID: <20180327143820.GH5652@dhcp22.suse.cz> (raw)
In-Reply-To: <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com>

On Tue 27-03-18 16:51:08, Ilya Smith wrote:
> 
> > On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
> > 
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >> 
> >>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >>> 
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>>> 
> >>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>>> 
> >>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>>>> Current implementation doesn't randomize address returned by mmap.
> >>>>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>>>> creation. After that mmap build very predictable layout of address
> >>>>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>>>> randomization of address on any mmap call.
> >>>>> 
> >>>>> Why should this be done in the kernel rather than libc?  libc is perfectly
> >>>>> capable of specifying random numbers in the first argument of mmap.
> >>>> Well, there is following reasons:
> >>>> 1. It should be done in any libc implementation, what is not possible IMO;
> >>> 
> >>> Is this really so helpful?
> >> 
> >> Yes, ASLR is one of very important mitigation techniques which are really used 
> >> to protect applications. If there is no ASLR, it is very easy to exploit 
> >> vulnerable application and compromise the system. We can’t just fix all the 
> >> vulnerabilities right now, thats why we have mitigations - techniques which are 
> >> makes exploitation more hard or impossible in some cases.
> >> 
> >> Thats why it is helpful.
> > 
> > I am not questioning ASLR in general. I am asking whether we really need
> > per mmap ASLR in general. I can imagine that some environments want to
> > pay the additional price and other side effects, but considering this
> > can be achieved by libc, why to add more code to the kernel?
> 
> I believe this is the only one right place for it. Adding these 200+ lines of 
> code we give this feature for any user - on desktop, on server, on IoT device, 
> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA 
> devices will never get it.

I guess it would really help if you could be more specific about the
class of security issues this would help to mitigate. My first
understanding was that we we need some randomization between program
executable segments to reduce the attack space when a single address
leaks and you know the segments layout (ordering). But why do we need
_all_ mmaps to be randomized. Because that complicates the
implementation consirably for different reasons you have mentioned
earlier.

Do you have any specific CVE that would be mitigated by this
randomization approach?

I am sorry, I am not a security expert to see all the cosequences but a
vague - the more randomization the better - sounds rather weak to me.
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Ilya Smith <blackzert@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com,
	vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com,
	fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org,
	Helge Deller <deller@gmx.de>,
	benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	ysato@users.sourceforge.jp, dalias@libc.org, davem@davemloft.net,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	x86@kernel.org, nyc@holomorphy.com, viro@zeniv.linux.org.uk,
	arnd@arndb.de, gregkh@linuxfoundation.org,
	deepa.kernel@gmail.com, Hugh Dickins <hughd@google.com>,
	kstewart@linuxfoundation.org, pombredanne@nexb.com,
	Andrew Morton <akpm@linux-foundation.org>,
	steve.capper@arm.com, punit.agrawal@arm.com,
	aneesh.kumar@linux.vnet.ibm.com, npiggin@gmail.com,
	Kees Cook <keescook@chromium.org>,
	bhsharma@redhat.com, riel@redhat.com, nitin.m.gupta@oracle.com,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>, Jan Kara <jack@suse.cz>,
	ross.zwisler@linux.intel.com, Jerome Glisse <jglisse@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-alpha@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-metag@vger.kernel.org, linux-mips@linux-mips.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, Linux-MM <linux-mm@kvack.org>
Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
Date: Tue, 27 Mar 2018 16:38:20 +0200	[thread overview]
Message-ID: <20180327143820.GH5652@dhcp22.suse.cz> (raw)
In-Reply-To: <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com>

On Tue 27-03-18 16:51:08, Ilya Smith wrote:
> 
> > On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
> > 
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >> 
> >>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >>> 
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>>> 
> >>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>>> 
> >>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>>>> Current implementation doesn't randomize address returned by mmap.
> >>>>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>>>> creation. After that mmap build very predictable layout of address
> >>>>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>>>> randomization of address on any mmap call.
> >>>>> 
> >>>>> Why should this be done in the kernel rather than libc?  libc is perfectly
> >>>>> capable of specifying random numbers in the first argument of mmap.
> >>>> Well, there is following reasons:
> >>>> 1. It should be done in any libc implementation, what is not possible IMO;
> >>> 
> >>> Is this really so helpful?
> >> 
> >> Yes, ASLR is one of very important mitigation techniques which are really used 
> >> to protect applications. If there is no ASLR, it is very easy to exploit 
> >> vulnerable application and compromise the system. We cana??t just fix all the 
> >> vulnerabilities right now, thats why we have mitigations - techniques which are 
> >> makes exploitation more hard or impossible in some cases.
> >> 
> >> Thats why it is helpful.
> > 
> > I am not questioning ASLR in general. I am asking whether we really need
> > per mmap ASLR in general. I can imagine that some environments want to
> > pay the additional price and other side effects, but considering this
> > can be achieved by libc, why to add more code to the kernel?
> 
> I believe this is the only one right place for it. Adding these 200+ lines of 
> code we give this feature for any user - on desktop, on server, on IoT device, 
> on SCADA, etc. But if only glibc will implement a??user-mode-aslra?? IoT and SCADA 
> devices will never get it.

I guess it would really help if you could be more specific about the
class of security issues this would help to mitigate. My first
understanding was that we we need some randomization between program
executable segments to reduce the attack space when a single address
leaks and you know the segments layout (ordering). But why do we need
_all_ mmaps to be randomized. Because that complicates the
implementation consirably for different reasons you have mentioned
earlier.

Do you have any specific CVE that would be mitigated by this
randomization approach?

I am sorry, I am not a security expert to see all the cosequences but a
vague - the more randomization the better - sounds rather weak to me.
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: mhocko@kernel.org (Michal Hocko)
To: linux-snps-arc@lists.infradead.org
Subject: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
Date: Tue, 27 Mar 2018 16:38:20 +0200	[thread overview]
Message-ID: <20180327143820.GH5652@dhcp22.suse.cz> (raw)
In-Reply-To: <0549F29C-12FC-4401-9E85-A430BC11DA78@gmail.com>

On Tue 27-03-18 16:51:08, Ilya Smith wrote:
> 
> > On 27 Mar 2018,@10:24, Michal Hocko <mhocko@kernel.org> wrote:
> > 
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >> 
> >>> On 26 Mar 2018,@11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >>> 
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>>> 
> >>>>> On 23 Mar 2018,@15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>>> 
> >>>>> On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
> >>>>>> Current implementation doesn't randomize address returned by mmap.
> >>>>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>>>> creation. After that mmap build very predictable layout of address
> >>>>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>>>> randomization of address on any mmap call.
> >>>>> 
> >>>>> Why should this be done in the kernel rather than libc?  libc is perfectly
> >>>>> capable of specifying random numbers in the first argument of mmap.
> >>>> Well, there is following reasons:
> >>>> 1. It should be done in any libc implementation, what is not possible IMO;
> >>> 
> >>> Is this really so helpful?
> >> 
> >> Yes, ASLR is one of very important mitigation techniques which are really used 
> >> to protect applications. If there is no ASLR, it is very easy to exploit 
> >> vulnerable application and compromise the system. We can?t just fix all the 
> >> vulnerabilities right now, thats why we have mitigations - techniques which are 
> >> makes exploitation more hard or impossible in some cases.
> >> 
> >> Thats why it is helpful.
> > 
> > I am not questioning ASLR in general. I am asking whether we really need
> > per mmap ASLR in general. I can imagine that some environments want to
> > pay the additional price and other side effects, but considering this
> > can be achieved by libc, why to add more code to the kernel?
> 
> I believe this is the only one right place for it. Adding these 200+ lines of 
> code we give this feature for any user - on desktop, on server, on IoT device, 
> on SCADA, etc. But if only glibc will implement ?user-mode-aslr? IoT and SCADA 
> devices will never get it.

I guess it would really help if you could be more specific about the
class of security issues this would help to mitigate. My first
understanding was that we we need some randomization between program
executable segments to reduce the attack space when a single address
leaks and you know the segments layout (ordering). But why do we need
_all_ mmaps to be randomized. Because that complicates the
implementation consirably for different reasons you have mentioned
earlier.

Do you have any specific CVE that would be mitigated by this
randomization approach?

I am sorry, I am not a security expert to see all the cosequences but a
vague - the more randomization the better - sounds rather weak to me.
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2018-03-27 14:38 UTC|newest]

Thread overview: 185+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-22 16:36 [RFC PATCH v2 0/2] Randomization of address chosen by mmap Ilya Smith
2018-03-22 16:36 ` Ilya Smith
2018-03-22 16:36 ` Ilya Smith
2018-03-22 16:36 ` [RFC PATCH v2 1/2] " Ilya Smith
2018-03-22 16:36   ` Ilya Smith
2018-03-22 16:36   ` Ilya Smith
2018-03-22 20:53   ` Andrew Morton
2018-03-22 20:53     ` Andrew Morton
2018-03-22 20:53     ` Andrew Morton
2018-03-22 20:53     ` Andrew Morton
2018-03-23 17:43     ` Ilya Smith
2018-03-23 17:43       ` Ilya Smith
2018-03-23 17:43       ` Ilya Smith
2018-03-23 17:43       ` Ilya Smith
2018-03-23 17:43       ` Ilya Smith
2018-03-23 17:43       ` Ilya Smith
2018-03-22 16:36 ` [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift Ilya Smith
2018-03-22 16:36   ` Ilya Smith
2018-03-22 16:36   ` Ilya Smith
2018-03-22 20:54   ` Andrew Morton
2018-03-22 20:54     ` Andrew Morton
2018-03-22 20:54     ` Andrew Morton
2018-03-22 20:54     ` Andrew Morton
2018-03-23 17:48     ` Ilya Smith
2018-03-23 17:48       ` Ilya Smith
2018-03-23 17:49     ` Ilya Smith
2018-03-23 17:49       ` Ilya Smith
2018-03-23 17:49       ` Ilya Smith
2018-03-23 17:49       ` Ilya Smith
2018-03-23 17:49       ` Ilya Smith
2018-03-23 17:49       ` Ilya Smith
2018-03-22 20:57 ` [RFC PATCH v2 0/2] Randomization of address chosen by mmap Andrew Morton
2018-03-22 20:57   ` Andrew Morton
2018-03-22 20:57   ` Andrew Morton
2018-03-22 20:57   ` Andrew Morton
2018-03-23 17:25   ` Ilya Smith
2018-03-23 17:25     ` Ilya Smith
2018-03-23 17:25     ` Ilya Smith
2018-03-23 17:25     ` Ilya Smith
2018-03-23 17:25     ` Ilya Smith
2018-03-23 17:25     ` Ilya Smith
2018-03-23 12:48 ` Matthew Wilcox
2018-03-23 12:48   ` Matthew Wilcox
2018-03-23 12:48   ` Matthew Wilcox
2018-03-23 12:48   ` Matthew Wilcox
2018-03-23 17:55   ` Ilya Smith
2018-03-23 17:55     ` Ilya Smith
2018-03-23 17:55     ` Ilya Smith
2018-03-23 17:55     ` Ilya Smith
2018-03-23 17:55     ` Ilya Smith
2018-03-23 17:55     ` Ilya Smith
2018-03-26  8:46     ` Michal Hocko
2018-03-26  8:46       ` Michal Hocko
2018-03-26  8:46       ` Michal Hocko
2018-03-26  8:46       ` Michal Hocko
2018-03-26  8:46       ` Michal Hocko
2018-03-26 19:45       ` Ilya Smith
2018-03-26 19:45         ` Ilya Smith
2018-03-26 19:45         ` Ilya Smith
2018-03-26 19:45         ` Ilya Smith
2018-03-26 19:45         ` Ilya Smith
2018-03-26 19:45         ` Ilya Smith
2018-03-27  7:24         ` Michal Hocko
2018-03-27  7:24           ` Michal Hocko
2018-03-27  7:24           ` Michal Hocko
2018-03-27  7:24           ` Michal Hocko
2018-03-27  7:24           ` Michal Hocko
2018-03-27 13:51           ` Ilya Smith
2018-03-27 13:51             ` Ilya Smith
2018-03-27 13:51             ` Ilya Smith
2018-03-27 13:51             ` Ilya Smith
2018-03-27 13:51             ` Ilya Smith
2018-03-27 13:51             ` Ilya Smith
2018-03-27 14:38             ` Michal Hocko [this message]
2018-03-27 14:38               ` Michal Hocko
2018-03-27 14:38               ` Michal Hocko
2018-03-27 14:38               ` Michal Hocko
2018-03-27 14:38               ` Michal Hocko
2018-03-28 18:47               ` Ilya Smith
2018-03-28 18:47                 ` Ilya Smith
2018-03-28 18:47                 ` Ilya Smith
2018-03-28 18:47                 ` Ilya Smith
2018-03-28 18:47                 ` Ilya Smith
2018-03-28 18:47                 ` Ilya Smith
2018-03-27 22:16             ` Theodore Y. Ts'o
2018-03-27 22:16               ` Theodore Y. Ts'o
2018-03-27 22:16               ` Theodore Y. Ts'o
2018-03-27 22:16               ` Theodore Y. Ts'o
2018-03-27 22:16               ` Theodore Y. Ts'o
2018-03-27 23:58               ` Rich Felker
2018-03-27 23:58                 ` Rich Felker
2018-03-27 23:58                 ` Rich Felker
2018-03-27 23:58                 ` Rich Felker
2018-03-28 18:48               ` Ilya Smith
2018-03-28 18:48                 ` Ilya Smith
2018-03-28 18:48                 ` Ilya Smith
2018-03-28 18:48                 ` Ilya Smith
2018-03-28 18:48                 ` Ilya Smith
2018-03-28 18:48                 ` Ilya Smith
2018-03-27 22:53             ` Kees Cook
2018-03-27 22:53               ` Kees Cook
2018-03-27 22:53               ` Kees Cook
2018-03-27 22:53               ` Kees Cook
2018-03-27 22:53               ` Kees Cook
2018-03-27 23:49               ` Matthew Wilcox
2018-03-27 23:49                 ` Matthew Wilcox
2018-03-27 23:49                 ` Matthew Wilcox
2018-03-27 23:49                 ` Matthew Wilcox
2018-03-27 23:57                 ` Kees Cook
2018-03-27 23:57                   ` Kees Cook
2018-03-27 23:57                   ` Kees Cook
2018-03-27 23:57                   ` Kees Cook
2018-03-28  0:00                 ` Rich Felker
2018-03-28  0:00                   ` Rich Felker
2018-03-28  0:00                   ` Rich Felker
2018-03-28  0:00                   ` Rich Felker
2018-03-28 21:07                   ` Luck, Tony
2018-03-28 21:07                     ` Luck, Tony
2018-03-28 21:07                     ` Luck, Tony
2018-03-28 21:07                     ` Luck, Tony
2018-03-28 21:07                     ` Luck, Tony
2018-04-03  0:11                     ` Ilya Smith
2018-04-03  0:11                       ` Ilya Smith
2018-04-03  0:11                       ` Ilya Smith
2018-04-03  0:11                       ` Ilya Smith
2018-04-03  0:11                       ` Ilya Smith
2018-04-03  0:11                       ` Ilya Smith
2018-03-28 21:07                 ` Ilya Smith
2018-03-28 21:07                   ` Ilya Smith
2018-03-28 21:07                   ` Ilya Smith
2018-03-28 21:07                   ` Ilya Smith
2018-03-28 21:07                   ` Ilya Smith
2018-03-23 18:00   ` Rich Felker
2018-03-23 18:00     ` Rich Felker
2018-03-23 18:00     ` Rich Felker
2018-03-23 18:00     ` Rich Felker
2018-03-23 18:00     ` Rich Felker
2018-03-23 19:06     ` Matthew Wilcox
2018-03-23 19:06       ` Matthew Wilcox
2018-03-23 19:06       ` Matthew Wilcox
2018-03-23 19:06       ` Matthew Wilcox
2018-03-23 19:16       ` Rich Felker
2018-03-23 19:16         ` Rich Felker
2018-03-23 19:16         ` Rich Felker
2018-03-23 19:16         ` Rich Felker
2018-03-23 19:16         ` Rich Felker
2018-03-23 19:29         ` Matthew Wilcox
2018-03-23 19:29           ` Matthew Wilcox
2018-03-23 19:29           ` Matthew Wilcox
2018-03-23 19:29           ` Matthew Wilcox
2018-03-23 19:35           ` Rich Felker
2018-03-23 19:35             ` Rich Felker
2018-03-23 19:35             ` Rich Felker
2018-03-23 19:35             ` Rich Felker
2018-03-23 19:35             ` Rich Felker
2018-03-28  4:50       ` Rob Landley
2018-03-28  4:50         ` Rob Landley
2018-03-28  4:50         ` Rob Landley
2018-03-28  4:50         ` Rob Landley
2018-03-28  4:50         ` Rob Landley
2018-03-30  7:55 ` Pavel Machek
2018-03-30  7:55   ` Pavel Machek
2018-03-30  7:55   ` Pavel Machek
2018-03-30  7:55   ` Pavel Machek
2018-03-30  9:07   ` Ilya Smith
2018-03-30  9:07     ` Ilya Smith
2018-03-30  9:07     ` Ilya Smith
2018-03-30  9:07     ` Ilya Smith
2018-03-30  9:07     ` Ilya Smith
2018-03-30  9:07     ` Ilya Smith
2018-03-30  9:57     ` Pavel Machek
2018-03-30  9:57       ` Pavel Machek
2018-03-30  9:57       ` Pavel Machek
2018-03-30  9:57       ` Pavel Machek
2018-03-30 11:10       ` Ilya Smith
2018-03-30 11:10         ` Ilya Smith
2018-03-30 11:10         ` Ilya Smith
2018-03-30 11:10         ` Ilya Smith
2018-03-30 11:10         ` Ilya Smith
2018-03-30 11:10         ` Ilya Smith
2018-03-30 13:33   ` Rich Felker
2018-03-30 13:33     ` Rich Felker
2018-03-30 13:33     ` Rich Felker
2018-03-30 13:33     ` Rich Felker
2018-03-30 13:33     ` Rich Felker

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=20180327143820.GH5652@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=bhsharma@redhat.com \
    --cc=blackzert@gmail.com \
    --cc=dalias@libc.org \
    --cc=dan.j.williams@intel.com \
    --cc=davem@davemloft.net \
    --cc=deepa.kernel@gmail.com \
    --cc=deller@gmx.de \
    --cc=fenghua.yu@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jack@suse.cz \
    --cc=jejb@parisc-linux.org \
    --cc=jglisse@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-metag@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mattst88@gmail.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=nitin.m.gupta@oracle.com \
    --cc=npiggin@gmail.com \
    --cc=nyc@holomorphy.com \
    --cc=oleg@redhat.com \
    --cc=paulus@samba.org \
    --cc=pombredanne@nexb.com \
    --cc=punit.agrawal@arm.com \
    --cc=ralf@linux-mips.org \
    --cc=riel@redhat.com \
    --cc=ross.zwisler@linux.intel.com \
    --cc=rth@twiddle.net \
    --cc=schwidefsky@de.ibm.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=steve.capper@arm.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vgupta@synopsys.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=ysato@users.sourceforge.jp \
    /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.