On 09/12/18 at 08:31am, Ingo Molnar wrote:
> Would you like to work on this? These would be really nice additions, once
> the code is cleaned
> up to be maintainable and the pending bug fixes you have are merged.
>
> In terms of patch logistics I'd suggest this ordering:
>
> - documentation fi
* Baoquan He wrote:
> > BTW., isn't that 'vaddr_end for KASLR' entry position inaccurate? In the
> > typical case it could
> > very well be that by chance all 3 areas end up being randomized into the
> > first 64 TB region,
> > right?
>
> Hmm, I think it means the whole space where KASLR c
On 09/12/18 at 08:31am, Ingo Molnar wrote:
>
> * Baoquan He wrote:
>
> > On 09/11/18 at 08:08pm, Baoquan He wrote:
> > > On 09/11/18 at 11:28am, Ingo Molnar wrote:
> > > > Yeah, so proper context is still missing, this paragraph appears to
> > > > assume from the reader a
> > > > whole lot of
* Baoquan He wrote:
> On 09/11/18 at 08:08pm, Baoquan He wrote:
> > On 09/11/18 at 11:28am, Ingo Molnar wrote:
> > > Yeah, so proper context is still missing, this paragraph appears to
> > > assume from the reader a
> > > whole lot of prior knowledge, and this is one of the top comments in
>
On 09/11/18 at 08:08pm, Baoquan He wrote:
> On 09/11/18 at 11:28am, Ingo Molnar wrote:
> > Yeah, so proper context is still missing, this paragraph appears to assume
> > from the reader a
> > whole lot of prior knowledge, and this is one of the top comments in
> > kaslr.c so there's nowhere
> >
On 09/11/18 at 11:28am, Ingo Molnar wrote:
> Yeah, so proper context is still missing, this paragraph appears to assume
> from the reader a
> whole lot of prior knowledge, and this is one of the top comments in kaslr.c
> so there's nowhere
> else to go read about the background.
>
> For exampl
* Baoquan He wrote:
> On 09/11/18 at 09:59am, Ingo Molnar wrote:
> >
> > * Baoquan He wrote:
> >
> > > /*
> > > + * Memory regions randomized by KASLR (except modules that use a separate
> > > + * logic earlier during boot). Currently they are the physical memory
> > > + * mapping, vmalloc
On 09/11/18 at 09:59am, Ingo Molnar wrote:
>
> * Baoquan He wrote:
>
> > /*
> > + * Memory regions randomized by KASLR (except modules that use a separate
> > + * logic earlier during boot). Currently they are the physical memory
> > + * mapping, vmalloc and vmemmap regions, are ordered based o
* Baoquan He wrote:
> /*
> + * Memory regions randomized by KASLR (except modules that use a separate
> + * logic earlier during boot). Currently they are the physical memory
> + * mapping, vmalloc and vmemmap regions, are ordered based on virtual
> + * addresses. The order is kept after rando
On 09/10/18 at 08:11am, Ingo Molnar wrote:
>
> * Baoquan He wrote:
>
> > @@ -108,6 +109,14 @@ void __init kernel_randomize_memory(void)
> > if (memory_tb < kaslr_regions[0].size_tb)
> > kaslr_regions[0].size_tb = memory_tb;
> >
> > + /*
> > +* Calculate how many TB vmemma
* Baoquan He wrote:
> Vmemmap region has different maximum size depending on paging mode.
> Now its size is hardcoded as 1TB in memory KASLR, this is not
> right for 5-level paging mode. It will cause overflow if vmemmap
> region is randomized to be adjacent to cpu_entry_area region and
> its a
Vmemmap region has different maximum size depending on paging mode.
Now its size is hardcoded as 1TB in memory KASLR, this is not
right for 5-level paging mode. It will cause overflow if vmemmap
region is randomized to be adjacent to cpu_entry_area region and
its actual size is bigger than 1TB.
So
12 matches
Mail list logo
