Re: [PATCH v2] binfmt_elf: Update READ_IMPLIES_EXEC logic for modern CPUs

Hello Kees, all, Sorry for the delayed response, I haven't had time to see this until now. On 25/04/2019 17:51, Kees Cook wrote: > On Wed, Apr 24, 2019 at 10:42 PM Ingo Molnar wrote: >> Just to make clear, is the change from the old behavior, in essence: >> >> >>CPU: | lacks

Re: [PATCH] Fix bss mapping for the interpreter in binfmt_elf

> On Wed, May 11, 2016 at 3:37 AM, Hector Marco-Gisbert <hecma...@upv.es> wrote: >> While working on a new ASLR for userspace we detected an error in the >> interpret loader. >> >> The size of the bss section for some interpreters is not correctly >> ca

Re: [PATCH] Fix bss mapping for the interpreter in binfmt_elf

> On Wed, May 11, 2016 at 3:37 AM, Hector Marco-Gisbert wrote: >> While working on a new ASLR for userspace we detected an error in the >> interpret loader. >> >> The size of the bss section for some interpreters is not correctly >> calculated resulti

Re: [PATCH] Fix bss mapping for the interpreter in binfmt_elf

ef, if the end of the bss is in the same page than the last segment > loaded then the size of the last of bss segment is incorrectly calculated. > > > This patch set up to the page boundary of the last_bss variable and only do > the vm_brk() call when necessary. > > >

Re: [PATCH] Fix bss mapping for the interpreter in binfmt_elf

ef, if the end of the bss is in the same page than the last segment > loaded then the size of the last of bss segment is incorrectly calculated. > > > This patch set up to the page boundary of the last_bss variable and only do > the vm_brk() call when necessary. > > > S

Re: [PATCH] Honor mmap_min_addr with the actual minimum

Thanks for the clarification. Below some comments. > On Wed, 2016-05-11 at 14:54 +0200, Hector Marco-Gisbert wrote: >> >> El 21/04/16 a las 00:12, Kees Cook escribió: >>> On Tue, Apr 19, 2016 at 11:55 AM, Hector Marco-Gisbert <hecmargi@up >>> v.es> wrote

Re: [PATCH] Honor mmap_min_addr with the actual minimum

Thanks for the clarification. Below some comments. > On Wed, 2016-05-11 at 14:54 +0200, Hector Marco-Gisbert wrote: >> >> El 21/04/16 a las 00:12, Kees Cook escribió: >>> On Tue, Apr 19, 2016 at 11:55 AM, Hector Marco-Gisbert >> v.es> wrote: >>>>&g

Re: [PATCH] Honor mmap_min_addr with the actual minimum

El 21/04/16 a las 00:12, Kees Cook escribió: > On Tue, Apr 19, 2016 at 11:55 AM, Hector Marco-Gisbert <hecma...@upv.es> > wrote: >>> On Wed, Apr 6, 2016 at 12:07 PM, Hector Marco-Gisbert <hecma...@upv.es> >>> wrote: >>>> The minimum ad

Re: [PATCH] Honor mmap_min_addr with the actual minimum

El 21/04/16 a las 00:12, Kees Cook escribió: > On Tue, Apr 19, 2016 at 11:55 AM, Hector Marco-Gisbert > wrote: >>> On Wed, Apr 6, 2016 at 12:07 PM, Hector Marco-Gisbert >>> wrote: >>>> The minimum address that a process is allowed to mmap when L

[PATCH] x86_64: Disabling read-implies-exec when the stack is executable

the patch which removes this possibility. Signed-off-by: Hector Marco-Gisbert <hecma...@upv.es> Acked-by: Ismael Ripoll Ripoll <irip...@upv.es> --- arch/x86/include/asm/elf.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/elf.h b/arch/x86/inclu

[PATCH] x86_64: Disabling read-implies-exec when the stack is executable

the patch which removes this possibility. Signed-off-by: Hector Marco-Gisbert Acked-by: Ismael Ripoll Ripoll --- arch/x86/include/asm/elf.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h index 15340e3..87fd15e 100644

[PATCH] Fix bss mapping for the interpreter in binfmt_elf

ny error. Note that vm_brk() is not necessary at all. In brief, if the end of the bss is in the same page than the last segment loaded then the size of the last of bss segment is incorrectly calculated. This patch set up to the page boundary of the last_bss variable and only do the vm_brk() call when nec

[PATCH] Fix bss mapping for the interpreter in binfmt_elf

ny error. Note that vm_brk() is not necessary at all. In brief, if the end of the bss is in the same page than the last segment loaded then the size of the last of bss segment is incorrectly calculated. This patch set up to the page boundary of the last_bss variable and only do the vm_brk() call when nec

Re: [PATCH] Honor mmap_min_addr with the actual minimum

check is done in the security_mmap_addr(addr) function in mm/mmap.c file. It seems that we are exporting the dac_mmap_min_addr instead of the actual minimum. Is this behavior intended ? I'm missing something here ? Thanks, Hector. > On Wed, Apr 6, 2016 at 12:07 PM, Hector Marco-Gisbert <

Re: [PATCH] Honor mmap_min_addr with the actual minimum

check is done in the security_mmap_addr(addr) function in mm/mmap.c file. It seems that we are exporting the dac_mmap_min_addr instead of the actual minimum. Is this behavior intended ? I'm missing something here ? Thanks, Hector. > On Wed, Apr 6, 2016 at 12:07 PM, Hector Marco-Gisbert wr

[PATCH] Honor mmap_min_addr with the actual minimum

ddr $ cat /proc/sys/vm/mmap_min_addr 65536# <= It is correct Signed-off-by: Hector Marco-Gisbert <hecma...@upv.es> Acked-by: Ismael Ripoll Ripoll <irip...@upv.es> --- security/min_addr.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/security/min_addr

[PATCH] Honor mmap_min_addr with the actual minimum

ddr $ cat /proc/sys/vm/mmap_min_addr 65536# <= It is correct Signed-off-by: Hector Marco-Gisbert Acked-by: Ismael Ripoll Ripoll --- security/min_addr.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/security/min_addr.c b/security/min_addr.c index f7287

[tip:x86/mm] x86/mm/32: Enable full randomization on i386 and X86_32

Commit-ID: 8b8addf891de8a00e4d39fc32f93f7c5eb8feceb Gitweb: http://git.kernel.org/tip/8b8addf891de8a00e4d39fc32f93f7c5eb8feceb Author: Hector Marco-Gisbert <hecma...@upv.es> AuthorDate: Thu, 10 Mar 2016 20:51:00 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri,

[tip:x86/mm] x86/mm/32: Enable full randomization on i386 and X86_32

Commit-ID: 8b8addf891de8a00e4d39fc32f93f7c5eb8feceb Gitweb: http://git.kernel.org/tip/8b8addf891de8a00e4d39fc32f93f7c5eb8feceb Author: Hector Marco-Gisbert AuthorDate: Thu, 10 Mar 2016 20:51:00 +0100 Committer: Ingo Molnar CommitDate: Fri, 11 Mar 2016 09:53:19 +0100 x86/mm/32: Enable

[PATCH] x86: Enable full randomization on i386 and X86_32.

ortunately this doesn't work on setuid/setgid applications because there is security checks which clear Security-relevant flags. This patch always randomizes the mmap_legacy_base address, removing the possibility to disable the ASLR by setting the stack to "unlimited". Signed-off-by: Hector

[PATCH] x86: Enable full randomization on i386 and X86_32.

ortunately this doesn't work on setuid/setgid applications because there is security checks which clear Security-relevant flags. This patch always randomizes the mmap_legacy_base address, removing the possibility to disable the ASLR by setting the stack to "unlimited". Signed-off-by: Hector M

[tip:x86/mm] x86/mm: Improve AMD Bulldozer ASLR workaround

Commit-ID: 4e26d11f52684dc8b1632a8cfe450cb5197a8464 Gitweb: http://git.kernel.org/tip/4e26d11f52684dc8b1632a8cfe450cb5197a8464 Author: Hector Marco-Gisbert AuthorDate: Fri, 27 Mar 2015 12:38:21 +0100 Committer: Ingo Molnar CommitDate: Tue, 31 Mar 2015 10:01:17 +0200 x86/mm: Improve

[tip:x86/mm] x86/mm: Improve AMD Bulldozer ASLR workaround

Commit-ID: 4e26d11f52684dc8b1632a8cfe450cb5197a8464 Gitweb: http://git.kernel.org/tip/4e26d11f52684dc8b1632a8cfe450cb5197a8464 Author: Hector Marco-Gisbert hecma...@upv.es AuthorDate: Fri, 27 Mar 2015 12:38:21 +0100 Committer: Ingo Molnar mi...@kernel.org CommitDate: Tue, 31 Mar 2015 10

Re: [PATCH] mm/x86: AMD Bulldozer ASLR fix

Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll How am I to interpret Ismael's SOB here? Did he write the patch, did he create it, ...? Because this SOB chain is incorrect in this form. We have only one author per commit. If you want to accredit Ismael, you can say

[PATCH] mm/x86: AMD Bulldozer ASLR fix

not known by a potential remote attacker, the ASLR preserves its effectiveness. More details at: http://hmarco.org/bugs/AMD-Bulldozer-linux-ASLR-weakness-reducing-mmaped-files-by-eight.html Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll --- arch/x86/include/asm/elf.h | 1 + arch/x86/

[PATCH] mm/x86: AMD Bulldozer ASLR fix

remote attacker, the ASLR preserves its effectiveness. More details at: http://hmarco.org/bugs/AMD-Bulldozer-linux-ASLR-weakness-reducing-mmaped-files-by-eight.html Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@disca.upv.es --- arch/x86/include/asm

Re: [PATCH] mm/x86: AMD Bulldozer ASLR fix

Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@disca.upv.es How am I to interpret Ismael's SOB here? Did he write the patch, did he create it, ...? Because this SOB chain is incorrect in this form. We have only one author per commit. If you want

[PATCH] mm/x86: AMD Bulldozer ASLR fix

not known by a potential remote attacker, the ASLR preserves its effectiveness. More details at: http://hmarco.org/bugs/AMD-Bulldozer-linux-ASLR-weakness-reducing-mmaped-files-by-eight.html Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll --- arch/x86/include/asm/elf.h | 1 + arch/x86/

Re: [PATCH] mm/x86: AMD Bulldozer ASLR fix

El 24/03/15 a las 20:15, Borislav Petkov escribió: On Tue, Mar 24, 2015 at 07:00:48PM +0100, Hector Marco-Gisbert wrote: diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 15c5df9..a693d54 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -5,6

Re: [PATCH] mm/x86: AMD Bulldozer ASLR fix

El 24/03/15 a las 20:15, Borislav Petkov escribió: On Tue, Mar 24, 2015 at 07:00:48PM +0100, Hector Marco-Gisbert wrote: diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 15c5df9..a693d54 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -5,6

[PATCH] mm/x86: AMD Bulldozer ASLR fix

remote attacker, the ASLR preserves its effectiveness. More details at: http://hmarco.org/bugs/AMD-Bulldozer-linux-ASLR-weakness-reducing-mmaped-files-by-eight.html Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@disca.upv.es --- arch/x86/include/asm

[PATCH] mm/x86: AMD Bulldozer ASLR fix

not known by a potential remote attacker, the ASLR preserves its effectiveness. More details at: http://hmarco.org/bugs/AMD-Bulldozer-linux-ASLR-weakness-reducing-mmaped-files-by-eight.html Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll --- arch/x86/include/asm/amd_15h.h | 6 ++

[PATCH] mm/x86: AMD Bulldozer ASLR fix

by a potential remote attacker, the ASLR preserves its effectiveness. More details at: http://hmarco.org/bugs/AMD-Bulldozer-linux-ASLR-weakness-reducing-mmaped-files-by-eight.html Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@disca.upv.es --- arch/x86

Re: [PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS

b377f000 r-xp ... [vdso] Once corrected, the PIE linked application is loaded in a different area. We updated the "Fixing Offset2lib weakness" page: http://cybersecurity.upv.es/solutions/aslrv2/aslrv2.html Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll diff --gi

[PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS

ffb377d000-7fffb377f000 r-xp ... [vdso] Once corrected, the PIE linked application is loaded in a different area. We updated the "Fixing Offset2lib weakness" page: http://cybersecurity.upv.es/solutions/aslrv2/aslrv2.html Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll d

[PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS

-7fffb377f000 r-xp ... [vdso] Once corrected, the PIE linked application is loaded in a different area. We updated the Fixing Offset2lib weakness page: http://cybersecurity.upv.es/solutions/aslrv2/aslrv2.html Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@upv.es

Re: [PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS

-xp ... [vdso] Once corrected, the PIE linked application is loaded in a different area. We updated the Fixing Offset2lib weakness page: http://cybersecurity.upv.es/solutions/aslrv2/aslrv2.html Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@upv.es diff

[tip:x86/urgent] x86, mm/ASLR: Fix stack randomization on 64-bit systems

Commit-ID: 4e7c22d447bb6d7e37bfe39ff658486ae78e8d77 Gitweb: http://git.kernel.org/tip/4e7c22d447bb6d7e37bfe39ff658486ae78e8d77 Author: Hector Marco-Gisbert AuthorDate: Sat, 14 Feb 2015 09:33:50 -0800 Committer: Borislav Petkov CommitDate: Thu, 19 Feb 2015 12:21:36 +0100 x86, mm/ASLR

[tip:x86/urgent] x86, mm/ASLR: Fix stack randomization on 64-bit systems

Commit-ID: 4e7c22d447bb6d7e37bfe39ff658486ae78e8d77 Gitweb: http://git.kernel.org/tip/4e7c22d447bb6d7e37bfe39ff658486ae78e8d77 Author: Hector Marco-Gisbert hecma...@upv.es AuthorDate: Sat, 14 Feb 2015 09:33:50 -0800 Committer: Borislav Petkov b...@suse.de CommitDate: Thu, 19 Feb 2015 12

[PATH] Fix stack randomization on x86_64 bit

ting the types involved in the operations in the functions randomize_stack_top() and stack_maxrandom_size(). Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index 919b912..df4552b 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -35,1

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

the CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE option is not longer needed (removed). Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 97d07ed..ee7ea7e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1,7 +1,6 @@ config ARM bool

[PATH] Fix stack randomization on x86_64 bit

-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@upv.es diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index 919b912..df4552b 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -35,12 +35,12 @@ struct va_alignment __read_mostly va_align

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

the CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE option is not longer needed (removed). Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@upv.es diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 97d07ed..ee7ea7e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1,7 +1,6

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

our city than running out of memory because of fragmentation. Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 75511ef..dde92ee 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/k

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

. Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@upv.es diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 75511ef..dde92ee 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -704,6 +704,18

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

r-mmap randomization. Sorry if I'm mixing VDSO, and offset2lib issues, but they share a similar core problem. --Hector Marco. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

ddress is not valid. This is a rare case, but which occurs from time to time. Therefore, putting the VVAR/VDSO in the mmap area, as this patch does, should work smoothly. Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll diff --git a/arch/x86/vdso/vma.c b/arch/x86/

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

, but which occurs from time to time. Therefore, putting the VVAR/VDSO in the mmap area, as this patch does, should work smoothly. Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@upv.es diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c index 009495b

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

category than libraries. But I guess that it deserves a region for its own. Also, I think that executable code shall be apart from data.. which supports the idea of inter-mmap randomization. Sorry if I'm mixing VDSO, and offset2lib issues, but they share a similar core problem. --Hector Marco

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

El 12/12/14 a las 18:17, Andy Lutomirski escribió: On Dec 12, 2014 8:33 AM, "Hector Marco" wrote: Hello, I agree. I don't think a new randomization mode will be needed, just fix the current randomize_va_space=2. Said other way: fixing the offset2lib will not break any curre

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

El 12/12/14 a las 18:17, Andy Lutomirski escribió: On Dec 12, 2014 8:33 AM, Hector Marco hecma...@upv.es wrote: Hello, I agree. I don't think a new randomization mode will be needed, just fix the current randomize_va_space=2. Said other way: fixing the offset2lib will not break any current

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

. It would be better fix VDSO in a different patch ? I can send a patch which fixes the VDSO on 64 bit. Regards, Hector Marco. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo inf

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

. It would be better fix VDSO in a different patch ? I can send a patch which fixes the VDSO on 64 bit. Regards, Hector Marco. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

akness this approach need to be changed. From my point of view, moving to "PowerPC" approach is not the best solution. I've taken a look to PaX code and they implement a similar solution that I have been proposed. Anyway, if you are still thinking that the best approach is the "Pow

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

and they implement a similar solution that I have been proposed. Anyway, if you are still thinking that the best approach is the PowerPC one, then I could change the patch to fix the x86*, ARM* and MIPS following this approach. Best regards, Hector Marco. http://hmarco.org -- To unsubscribe from this list

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

processes. The patch has been tested on x86_64/32 and ARM/ARM64. Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 57baff5..1068492 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentat

Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

. The patch has been tested on x86_64/32 and ARM/ARM64. Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@upv.es diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 57baff5..1068492 100644 --- a/Documentation/sysctl/kernel.txt

[PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

it(struct mm_struct *mm, struct task_struct *p) { mm->mmap = NULL; + mm->exec_base = 0; mm->mm_rb = RB_ROOT; mm->vmacache_seqnum = 0; atomic_set(>mm_users, 1); Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll -- To unsubscri

[PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

task_struct *p) { mm-mmap = NULL; + mm-exec_base = 0; mm-mm_rb = RB_ROOT; mm-vmacache_seqnum = 0; atomic_set(mm-mm_users, 1); Signed-off-by: Hector Marco-Gisbert hecma...@upv.es Signed-off-by: Ismael Ripoll irip...@upv.es -- To unsubscribe from this list: send