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/

[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

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

Before I even *consider* the code, I want to know two things: > > 1. Is there actually a problem in the first place? The vdso > randomization in all released kernels is blatantly buggy, but it's > fixed in -tip, so it should be fixed by the time that 3.19-rc2 comes > out, and the fix is

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

Before I even *consider* the code, I want to know two things: 1. Is there actually a problem in the first place? The vdso randomization in all released kernels is blatantly buggy, but it's fixed in -tip, so it should be fixed by the time that 3.19-rc2 comes out, and the fix is marked

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