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
PaX Team wrote:
On 7 Oct 2012 at 9:43, Ard Biesheuvel wrote:
2012/10/6 PaX Team pagee...@freemail.hu:
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
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
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:
2012/10/6 PaX Team pagee...@freemail.hu:
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
On 7 Oct 2012 at 9:43, Ard Biesheuvel wrote:
2012/10/6 PaX Team pagee...@freemail.hu:
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
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
On 4 Oct 2012 at 15:56, Ard Biesheuvel wrote:
2012/10/4 PaX Team pagee...@freemail.hu:
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
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
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
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 bits
2012/10/4 Kees Cook keesc...@chromium.org:
On Wed, Oct 3, 2012 at 2:18 PM, Andrew Morton a...@linux-foundation.org
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
2012/10/4 Mikael Pettersson mi...@it.uu.se:
- 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
On 3 Oct 2012 at 15:19, Kees Cook wrote:
On Wed, Oct 3, 2012 at 2:18 PM, Andrew Morton a...@linux-foundation.org
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
2012/10/4 PaX Team pagee...@freemail.hu:
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
> > 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:
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
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
>
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
On Wed, Oct 3, 2012 at 7:43 AM, Ard Biesheuvel ard.biesheu...@gmail.com 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
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
set
On Wed, 03 Oct 2012 16:43:53 +0200
Ard Biesheuvel ard.biesheu...@gmail.com 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
On Wed, Oct 3, 2012 at 2:18 PM, Andrew Morton a...@linux-foundation.org wrote:
On Wed, 03 Oct 2012 16:43:53 +0200
Ard Biesheuvel ard.biesheu...@gmail.com wrote:
This patch adds support for the PROT_FINAL flag to
the mmap() and mprotect() syscalls.
The PROT_FINAL flag indicates that the
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:
28 matches
Mail list logo
