On 15.2.2021 14.51, Uladzislau Rezki wrote:
On Sat, Feb 13, 2021 at 03:43:39PM +0200, Topi Miettinen wrote:
On 13.2.2021 13.55, Uladzislau Rezki wrote:
Hello,
Is there a chance of getting this reviewed and maybe even merged, please?
-Topi
I can review it and help with it. But before that i
On Sat, Feb 13, 2021 at 03:43:39PM +0200, Topi Miettinen wrote:
> On 13.2.2021 13.55, Uladzislau Rezki wrote:
> > > Hello,
> > >
> > > Is there a chance of getting this reviewed and maybe even merged, please?
> > >
> > > -Topi
> > >
> > I can review it and help with it. But before that i would l
On 13.2.2021 13.55, Uladzislau Rezki wrote:
Hello,
Is there a chance of getting this reviewed and maybe even merged, please?
-Topi
I can review it and help with it. But before that i would like to
clarify if such "randomization" is something that you can not leave?
This happens to interest
> Hello,
>
> Is there a chance of getting this reviewed and maybe even merged, please?
>
> -Topi
>
I can review it and help with it. But before that i would like to
clarify if such "randomization" is something that you can not leave?
For example on 32bit system vmalloc space is limited, such ra
Hello,
Is there a chance of getting this reviewed and maybe even merged, please?
-Topi
On 12.12.2020 19.56, Topi Miettinen wrote:
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses. With
new kernel boot parameter 'randomi
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses. With
new kernel boot parameter 'randomize_vmalloc=1', the entire area is
used randomly to make the allocations less predictable and harder to
guess for attackers. Also module
6 matches
Mail list logo