On Sat, Feb 28, 2015 at 07:20:09PM +, Matt Fleming wrote:
> Doing a static allocation is fine, and the memory is even reserved from
> being overwritten via memblock_x86_reserve_range_setup_data(), but it
First of all, the naming of that function has failed really badly
somewhere along the way.
On Sat, 28 Feb, at 11:50:49AM, Borislav Petkov wrote:
>
> Yeah, too many hmms means this still needed staring at to find out what
> exactly the problem is. And the problem is that allocating that struct
> setup_data statically in arch/x86/boot/compressed/aslr.c works only by
> chance, when the ker
On Thu, Feb 26, 2015 at 01:16:17PM +0100, Borislav Petkov wrote:
> The proper fix should be to say, don't ioremap setup_data which is
> kernel memory but I'm not sure I have a good idea at the moment how to
> do that *without* ioremapping the thing to inspect it first...
>
> More hmm...
Yeah, too
On Thu, Feb 26, 2015 at 12:12:50PM +0100, Ingo Molnar wrote:
> Why is it ioremap()-ed to begin with, why cannot the kernel
> access its own data structure in RAM directly?
Probably because those setup_data structs refer to !RAM objects and
there we need to ioremap. But from looking at arch/x86/ke
* Borislav Petkov wrote:
> thanks for the report.
>
> So, AFAICT, this is caused by ksysfs ioremapping struct
> setup_data for a short time so that it can count it and
> show it in /sys/kernel/boot_params/setup_data/*
>
> And, of course, the setup_data thing which we're using
> for kaslr pa
Hi,
On Thu, Feb 26, 2015 at 01:37:01PM +0800, Huang Ying wrote:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit f47233c2d34f243ecdaac179c3408a39ff9216a7 ("x86/mm/ASLR: Propagate base
> load address calculation")
>
>
>
6 matches
Mail list logo