On 5.10.2020 15.18, David Hildenbrand wrote:
On 05.10.20 13:21, David Laight wrote:
From: David Hildenbrand
Sent: 05 October 2020 10:55
...
If hardening and compatibility are seen as tradeoffs, perhaps there
could be a top level config choice (CONFIG_HARDENING_TRADEOFF) for this.
It would
On 5.10.2020 15.25, David Laight wrote:
From: David Hildenbrand
Sent: 05 October 2020 13:19
On 05.10.20 13:21, David Laight wrote:
From: David Hildenbrand
Sent: 05 October 2020 10:55
...
If hardening and compatibility are seen as tradeoffs, perhaps there
could be a top level config choice
On 5.10.2020 17.12, Jonathan Corbet wrote:
On Mon, 5 Oct 2020 11:11:35 +0300
Topi Miettinen wrote:
The point is not to shrink the kernel (it will shrink by one small
function) or get rid of complexity. The point is to disable an inferior
interface. Memory returned by mmap() is at a random
On Mon, 5 Oct 2020 11:11:35 +0300
Topi Miettinen wrote:
> The point is not to shrink the kernel (it will shrink by one small
> function) or get rid of complexity. The point is to disable an inferior
> interface. Memory returned by mmap() is at a random location but with
> brk() it is located
From: David Hildenbrand
> Sent: 05 October 2020 13:19
>
> On 05.10.20 13:21, David Laight wrote:
> > From: David Hildenbrand
> >> Sent: 05 October 2020 10:55
> > ...
> >>> If hardening and compatibility are seen as tradeoffs, perhaps there
> >>> could be a top level config choice
On 05.10.20 13:21, David Laight wrote:
> From: David Hildenbrand
>> Sent: 05 October 2020 10:55
> ...
>>> If hardening and compatibility are seen as tradeoffs, perhaps there
>>> could be a top level config choice (CONFIG_HARDENING_TRADEOFF) for this.
>>> It would have options
>>> - "compatibility"
From: David Hildenbrand
> Sent: 05 October 2020 10:55
...
> > If hardening and compatibility are seen as tradeoffs, perhaps there
> > could be a top level config choice (CONFIG_HARDENING_TRADEOFF) for this.
> > It would have options
> > - "compatibility" (default) to gear questions for maximum
On 05.10.20 11:47, Topi Miettinen wrote:
> On 5.10.2020 12.13, David Hildenbrand wrote:
>> On 05.10.20 08:12, Michal Hocko wrote:
>>> On Sat 03-10-20 00:44:09, Topi Miettinen wrote:
On 2.10.2020 20.52, David Hildenbrand wrote:
> On 02.10.20 19:19, Topi Miettinen wrote:
>> The brk()
On 5.10.2020 12.13, David Hildenbrand wrote:
On 05.10.20 08:12, Michal Hocko wrote:
On Sat 03-10-20 00:44:09, Topi Miettinen wrote:
On 2.10.2020 20.52, David Hildenbrand wrote:
On 02.10.20 19:19, Topi Miettinen wrote:
The brk() system call allows to change data segment size (heap). This
is
On Mon 05-10-20 11:13:48, David Hildenbrand wrote:
> On 05.10.20 08:12, Michal Hocko wrote:
> > On Sat 03-10-20 00:44:09, Topi Miettinen wrote:
> >> On 2.10.2020 20.52, David Hildenbrand wrote:
> >>> On 02.10.20 19:19, Topi Miettinen wrote:
> The brk() system call allows to change data
On 05.10.20 08:12, Michal Hocko wrote:
> On Sat 03-10-20 00:44:09, Topi Miettinen wrote:
>> On 2.10.2020 20.52, David Hildenbrand wrote:
>>> On 02.10.20 19:19, Topi Miettinen wrote:
The brk() system call allows to change data segment size (heap). This
is mainly used by glibc for memory
On 5.10.2020 11.22, Michal Hocko wrote:
On Mon 05-10-20 11:11:35, Topi Miettinen wrote:
[...]
I think hardened, security oriented systems should disable brk() completely
because it will increase the randomization of the process address space
(ASLR). This wouldn't be a good option to enable for
On Mon 05-10-20 11:11:35, Topi Miettinen wrote:
[...]
> I think hardened, security oriented systems should disable brk() completely
> because it will increase the randomization of the process address space
> (ASLR). This wouldn't be a good option to enable for systems where maximum
> compatibility
On 5.10.2020 9.12, Michal Hocko wrote:
On Sat 03-10-20 00:44:09, Topi Miettinen wrote:
On 2.10.2020 20.52, David Hildenbrand wrote:
On 02.10.20 19:19, Topi Miettinen wrote:
The brk() system call allows to change data segment size (heap). This
is mainly used by glibc for memory allocation, but
On Sat 03-10-20 00:44:09, Topi Miettinen wrote:
> On 2.10.2020 20.52, David Hildenbrand wrote:
> > On 02.10.20 19:19, Topi Miettinen wrote:
> > > The brk() system call allows to change data segment size (heap). This
> > > is mainly used by glibc for memory allocation, but it can use mmap()
> > >
On 2.10.2020 20.52, David Hildenbrand wrote:
On 02.10.20 19:19, Topi Miettinen wrote:
The brk() system call allows to change data segment size (heap). This
is mainly used by glibc for memory allocation, but it can use mmap()
and that results in more randomized memory mappings since the heap is
From: David Hildenbrand
> Sent: 02 October 2020 18:52
>
> On 02.10.20 19:19, Topi Miettinen wrote:
> > The brk() system call allows to change data segment size (heap). This
> > is mainly used by glibc for memory allocation, but it can use mmap()
> > and that results in more randomized memory
On 02.10.20 19:19, Topi Miettinen wrote:
> The brk() system call allows to change data segment size (heap). This
> is mainly used by glibc for memory allocation, but it can use mmap()
> and that results in more randomized memory mappings since the heap is
> always located at fixed offset to
The brk() system call allows to change data segment size (heap). This
is mainly used by glibc for memory allocation, but it can use mmap()
and that results in more randomized memory mappings since the heap is
always located at fixed offset to program while mmap()ed memory is
randomized.
19 matches
Mail list logo
