On Wed, Feb 06, 2019 at 03:29:06PM +, Kees Cook wrote:
> I'm fine adjusting all this to do things better. Ultimately, we're
> still walking two lists to process their intersection.
I'm wondering if we could start with a single range including all memory
and then keep exluding until we're done
On Wed, Feb 6, 2019 at 2:18 PM Borislav Petkov wrote:
>
> On Wed, Feb 06, 2019 at 01:50:57PM +0100, Julian Stecklina wrote:
> > Because at this point, we are not in a good position to handle an
> > unlimited amount of regions.
>
> We could save only the regions which are ok to kaslr into. And we d
On Wed, Feb 06, 2019 at 01:50:57PM +0100, Julian Stecklina wrote:
> Because at this point, we are not in a good position to handle an
> unlimited amount of regions.
We could save only the regions which are ok to kaslr into. And we do,
apparently:
static struct slot_area slot_areas[MAX_SLOT_AREA];
Borislav Petkov writes:
>> @@ -213,7 +213,7 @@ static void mem_avoid_memmap(char *str)
>> i++;
>> }
>>
>> -/* More than 4 memmaps, fail kaslr */
>> +/* Can't store all regions, fail kaslr */
>> if ((i >= MAX_MEMMAP_REGIONS) && str)
>> memmap_too_large
On Wed, Jan 30, 2019 at 05:40:03PM +0100, Julian Stecklina wrote:
> From: Julian Stecklina
>
> The boot code has a limit of 4 "non-standard" regions to avoid for
> KASLR. This limit is easy to reach when supplying memmap= parameters to
> the kernel. In this case, KASLR would be disabled.
>
> Inc
From: Julian Stecklina
The boot code has a limit of 4 "non-standard" regions to avoid for
KASLR. This limit is easy to reach when supplying memmap= parameters to
the kernel. In this case, KASLR would be disabled.
Increase the limit to avoid turning off KASLR even when the user is
heavily manipul
6 matches
Mail list logo