PaX Team wrote:
> On 7 Oct 2012 at 9:43, Ard Biesheuvel wrote:
>
>> 2012/10/6 PaX Team :
>>> sadly, this is not true at all, for multiple reasons:
>>>
>> .. snip ...
>>>
>>> cheers,
>>> PaX Team
>>>
>>
>> So can I summarize your position as that there is no merit at all in
>> the ability to inhi
On 7 Oct 2012 at 9:43, Ard Biesheuvel wrote:
> 2012/10/6 PaX Team :
> > sadly, this is not true at all, for multiple reasons:
> >
> .. snip ...
> >
> > cheers,
> > PaX Team
> >
>
> So can I summarize your position as that there is no merit at all in
> the ability to inhibit future permissions o
2012/10/6 PaX Team :
> sadly, this is not true at all, for multiple reasons:
>
.. snip ...
>
> cheers,
> PaX Team
>
So can I summarize your position as that there is no merit at all in
the ability to inhibit future permissions of existing mappings?
--
Ard.
--
To unsubscribe from this list: sen
On 4 Oct 2012 at 15:56, Ard Biesheuvel wrote:
> 2012/10/4 PaX Team :
> The main difference here is that it is much easier to doctor a set of
> stack frames that issues a mprotect(+PROT_EXEC) on the whole address
> space than it is to re-issue the exact same mmap() call (with
> MAP_FIXED this time,
2012/10/4 PaX Team :
Thanks for taking a look at this matter.
>> >> This is mainly intended for the dynamic linker,
>> >> which sets up the address space on behalf of
>> >> dynamic binaries. By using this flag, it can
>> >> prevent exploited code from remapping read-only
>> >> executable code or
On 3 Oct 2012 at 15:19, Kees Cook wrote:
> On Wed, Oct 3, 2012 at 2:18 PM, Andrew Morton
> wrote:
> > It sounds as though the PaX developers could provide useful review
> > input on this proposal. Do they know about it? If so, what is their
> > position?
>
> I'd rather not speak for them, but
2012/10/4 Mikael Pettersson :
> - If .text is mapped non-writable and final, how would a debugger
> (or any ptrace-using monitor-like application) plant a large
> number of breakpoints in a target process? Breakpoint registers
> aren't enough because (a) they're few in number, and (b) not
>
2012/10/4 Kees Cook :
> On Wed, Oct 3, 2012 at 2:18 PM, Andrew Morton
> wrote:
>> Again: has this proposal been reviewed by the glibc maintainers? If
>> so, what was their position on it?
>
> Ard have you talked with them? I would expect it would be welcomed.
> Roland, do you know who would be t
Ard Biesheuvel writes:
> This patch adds support for the PROT_FINAL flag to
> the mmap() and mprotect() syscalls.
>
> The PROT_FINAL flag indicates that the requested set
> of protection bits should be final, i.e., it shall
> not be allowed for a subsequent mprotect call to
> set protection
> > Again: has this proposal been reviewed by the glibc maintainers? If
> > so, what was their position on it?
>
> Ard have you talked with them? I would expect it would be welcomed.
> Roland, do you know who would be the right person to ask about this
> for glibc? (patch: https://lkml.org/lkml/2
On Wed, Oct 3, 2012 at 2:18 PM, Andrew Morton wrote:
> On Wed, 03 Oct 2012 16:43:53 +0200
> Ard Biesheuvel wrote:
>
>> This patch adds support for the PROT_FINAL flag to
>> the mmap() and mprotect() syscalls.
>>
>> The PROT_FINAL flag indicates that the requested set
>> of protection bits should
On Wed, 03 Oct 2012 16:43:53 +0200
Ard Biesheuvel wrote:
> This patch adds support for the PROT_FINAL flag to
> the mmap() and mprotect() syscalls.
>
> The PROT_FINAL flag indicates that the requested set
> of protection bits should be final, i.e., it shall
> not be allowed for a subsequent mpro
On Wed, 3 Oct 2012, Ard Biesheuvel wrote:
> This patch adds support for the PROT_FINAL flag to
> the mmap() and mprotect() syscalls.
>
> The PROT_FINAL flag indicates that the requested set
> of protection bits should be final, i.e., it shall
> not be allowed for a subsequent mprotect call to
> s
On Wed, Oct 3, 2012 at 7:43 AM, Ard Biesheuvel wrote:
> This patch adds support for the PROT_FINAL flag to
> the mmap() and mprotect() syscalls.
>
> The PROT_FINAL flag indicates that the requested set
> of protection bits should be final, i.e., it shall
> not be allowed for a subsequent mprotect
This patch adds support for the PROT_FINAL flag to
the mmap() and mprotect() syscalls.
The PROT_FINAL flag indicates that the requested set
of protection bits should be final, i.e., it shall
not be allowed for a subsequent mprotect call to
set protection bits that were not set already.
This is ma
15 matches
Mail list logo
