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
> 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
> 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
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.
>
>
>
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
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
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
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
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
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
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
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
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
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 <
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
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
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
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,
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
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
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
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
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
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
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/
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
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
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/
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
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 ++
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
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
-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
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
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
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
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
-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
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
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
.
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
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
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/
, 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
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
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
.
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
47 matches
Mail list logo