* Saidi, Ali wrote:
> On 3/27/19, 2:52 PM, "linux-arm-kernel on behalf of Kees Cook"
> keesc...@chromium.org> wrote:
>
> Adding some more people to CC... what do people think about this
> moving of the brk to ELF_ET_DYN_BASE in this corner-case? Anything
> that worked before sho
On Fri, Apr 19, 2019 at 3:51 AM Ingo Molnar wrote:
> I'd suggest incorporating all feedback and sending a v2 series - it's
> much easier to get people's attention via code submitted. ;-)
I sent my patch out, akpm added it to -mm and then xtensa broke, and
it got removed. S... I'm looking at i
On 3/27/19, 2:52 PM, "linux-arm-kernel on behalf of Kees Cook"
wrote:
Adding some more people to CC... what do people think about this
moving of the brk to ELF_ET_DYN_BASE in this corner-case? Anything
that worked before should still work (i.e. the ultimately-launched
binary a
On Wed, Mar 13, 2019 at 3:58 PM Kees Cook wrote:
>
> On Tue, Mar 12, 2019 at 10:33 AM Ali Saidi wrote:
> >
> > Increase mmap_base by the worst-case brk randomization so that
> > the stack and heap remain apart.
> >
> > In Linux 4.13 a change was committed that special cased the kernel ELF
> > loa
On Tue, 26 Mar 2019, Saidi, Ali wrote:
> On 3/21/19, 9:11 AM, "linux-arm-kernel on behalf of Thomas Gleixner"
> t...@linutronix.de> wrote:
>
> On Tue, 12 Mar 2019, Ali Saidi wrote:
>
> > Increase mmap_base by the worst-case brk randomization so that
> > the stack and heap remai
On 3/21/19, 9:11 AM, "linux-arm-kernel on behalf of Thomas Gleixner"
wrote:
On Tue, 12 Mar 2019, Ali Saidi wrote:
> Increase mmap_base by the worst-case brk randomization so that
> the stack and heap remain apart.
>
> In Linux 4.13 a change was committed that specia
On Tue, 12 Mar 2019, Ali Saidi wrote:
> Increase mmap_base by the worst-case brk randomization so that
> the stack and heap remain apart.
>
> In Linux 4.13 a change was committed that special cased the kernel ELF
> loader when the loader is invoked directly (eab09532d400; binfmt_elf: use
> ELF_ET
> On Mar 13, 2019, at 11:26 AM, Dave Hansen wrote:
>
>> On 3/12/19 10:32 AM, Ali Saidi wrote:
>> +/* Provide space for brk randomization */
>> +pad += SZ_32M;
>
> Just curious: Why is the padding in your other patch conditional on the
> 32-bit vs. 64-bit apps, but here it's always 32M
On Tue, Mar 12, 2019 at 10:33 AM Ali Saidi wrote:
>
> Increase mmap_base by the worst-case brk randomization so that
> the stack and heap remain apart.
>
> In Linux 4.13 a change was committed that special cased the kernel ELF
> loader when the loader is invoked directly (eab09532d400; binfmt_elf:
On 3/12/19 10:32 AM, Ali Saidi wrote:
> + /* Provide space for brk randomization */
> + pad += SZ_32M;
Just curious: Why is the padding in your other patch conditional on the
32-bit vs. 64-bit apps, but here it's always 32M?
Also, did you hit this problem in practice somehow?
Increase mmap_base by the worst-case brk randomization so that
the stack and heap remain apart.
In Linux 4.13 a change was committed that special cased the kernel ELF
loader when the loader is invoked directly (eab09532d400; binfmt_elf: use
ELF_ET_DYN_BASE only for PIE). Generally, the loader isn’
11 matches
Mail list logo
