On Tue, Mar 16, 2021 at 10:01:46AM +0200, Topi Miettinen wrote:
> On 15.3.2021 19.47, Uladzislau Rezki wrote:
> > On Mon, Mar 15, 2021 at 09:16:26AM -0700, Kees Cook wrote:
> > > On Mon, Mar 15, 2021 at 01:24:10PM +0100, Uladzislau Rezki wrote:
> > > > On Mon, Mar 15, 2021 at 11:04:42AM +0200,
On 15.3.2021 19.47, Uladzislau Rezki wrote:
On Mon, Mar 15, 2021 at 09:16:26AM -0700, Kees Cook wrote:
On Mon, Mar 15, 2021 at 01:24:10PM +0100, Uladzislau Rezki wrote:
On Mon, Mar 15, 2021 at 11:04:42AM +0200, Topi Miettinen wrote:
What's the problem with that? It seems to me that nothing
On 15.3.2021 20.02, Uladzislau Rezki wrote:
On Mon, Mar 15, 2021 at 06:23:37PM +0200, Topi Miettinen wrote:
On 15.3.2021 17.35, Uladzislau Rezki wrote:
On 14.3.2021 19.23, Uladzislau Rezki wrote:
Also, using vmaloc test driver i can trigger a kernel BUG:
[ 24.627577] kernel BUG at
On Mon, Mar 15, 2021 at 06:23:37PM +0200, Topi Miettinen wrote:
> On 15.3.2021 17.35, Uladzislau Rezki wrote:
> > > On 14.3.2021 19.23, Uladzislau Rezki wrote:
> > > > Also, using vmaloc test driver i can trigger a kernel BUG:
> > > >
> > > >
> > > > [ 24.627577] kernel BUG at
On Mon, Mar 15, 2021 at 09:16:26AM -0700, Kees Cook wrote:
> On Mon, Mar 15, 2021 at 01:24:10PM +0100, Uladzislau Rezki wrote:
> > On Mon, Mar 15, 2021 at 11:04:42AM +0200, Topi Miettinen wrote:
> > > What's the problem with that? It seems to me that nothing relies on
> > > specific
> > >
On 15.3.2021 17.35, Uladzislau Rezki wrote:
On 14.3.2021 19.23, Uladzislau Rezki wrote:
Also, using vmaloc test driver i can trigger a kernel BUG:
[ 24.627577] kernel BUG at mm/vmalloc.c:1272!
It seems that most tests indeed fail. Perhaps the vmalloc subsystem isn't
very robust in face of
On Mon, Mar 15, 2021 at 01:24:10PM +0100, Uladzislau Rezki wrote:
> On Mon, Mar 15, 2021 at 11:04:42AM +0200, Topi Miettinen wrote:
> > What's the problem with that? It seems to me that nothing relies on specific
> > addresses of the chunks, so it should be possible to randomize these too.
> >
> On 14.3.2021 19.23, Uladzislau Rezki wrote:
> > Also, using vmaloc test driver i can trigger a kernel BUG:
> >
> >
> > [ 24.627577] kernel BUG at mm/vmalloc.c:1272!
>
> It seems that most tests indeed fail. Perhaps the vmalloc subsystem isn't
> very robust in face of fragmented virtual
On Mon, Mar 15, 2021 at 11:04:42AM +0200, Topi Miettinen wrote:
> On 14.3.2021 19.23, Uladzislau Rezki wrote:
> > > Memory mappings inside kernel allocated with vmalloc() are in
> > > predictable order and packed tightly toward the low addresses, except
> > > for per-cpu areas which start from top
On 14.3.2021 19.23, Uladzislau Rezki wrote:
Also, using vmaloc test driver i can trigger a kernel BUG:
[ 24.627577] kernel BUG at mm/vmalloc.c:1272!
It seems that most tests indeed fail. Perhaps the vmalloc subsystem
isn't very robust in face of fragmented virtual memory. What could be
On 14.3.2021 19.23, Uladzislau Rezki wrote:
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses, except
for per-cpu areas which start from top of the vmalloc area. With
new kernel boot parameter 'randomize_vmalloc=1', the
> Memory mappings inside kernel allocated with vmalloc() are in
> predictable order and packed tightly toward the low addresses, except
> for per-cpu areas which start from top of the vmalloc area. With
> new kernel boot parameter 'randomize_vmalloc=1', the entire area is
> used randomly to make
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses, except
for per-cpu areas which start from top of the vmalloc area. With
new kernel boot parameter 'randomize_vmalloc=1', the entire area is
used randomly to make the
13 matches
Mail list logo
