On Mon, Mar 2, 2015 at 12:25 PM, Borislav Petkov wrote:
> unsigned char *choose_kernel_location(struct boot_params *params,
> diff --git a/arch/x86/boot/compressed/vmlinux.lds.S
> b/arch/x86/boot/compressed/vmlinux.lds.S
> index 34d047c98284..26d62f4b27b9 100644
> --- a/arch/x86/boot/compressed
On Mon, Mar 02, 2015 at 10:58:23AM -0800, Yinghai Lu wrote:
> On Mon, Mar 2, 2015 at 6:53 AM, Borislav Petkov wrote:
> > Well, it seems to work here but it still doesn't look reliable enough to
> > me. And this addon_zo thing of arbitrary 256K is strange.
>
> Thanks for check that out.
>
> That
On Mon, Mar 2, 2015 at 6:53 AM, Borislav Petkov wrote:
> Well, it seems to work here but it still doesn't look reliable enough to
> me. And this addon_zo thing of arbitrary 256K is strange.
Thanks for check that out.
That is not arbitrary number. Need to make that bigger than _end - _rodata
> o
On Mon, Mar 02, 2015 at 03:04:30AM -0800, Yinghai Lu wrote:
> We can not assume that range is safe to use.
>
> Please check attach one that should fix the problem really.
Well, it seems to work here but it still doesn't look reliable enough to
me. And this addon_zo thing of arbitrary 256K is stra
On Sat, 28 Feb, at 06:17:32PM, Yinghai Lu wrote:
> We should access variable with referrence instead of using physical
> address as value.
>
> Cc: Matt Fleming
> Cc: Borislav Petkov
> Signed-off-by: Yinghai Lu
> ---
> arch/x86/kernel/setup.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 d
On Mon, Mar 2, 2015 at 12:56 AM, Borislav Petkov wrote:
> On Sun, Mar 01, 2015 at 12:41:10PM -0800, Yinghai Lu wrote:
>> Does not look safe yet...
>
> Why?
We can not assume that range is safe to use.
Please check attach one that should fix the problem really.
Thanks
Yinghai
Subject: [PATCH] x
On Sat, 28 Feb 2015, Yinghai Lu wrote:
> We should access variable with referrence instead of using physical
> address as value.
>
> Cc: Matt Fleming
> Cc: Borislav Petkov
> Signed-off-by: Yinghai Lu
Acked-by: Jiri Kosina
Thanks for fixing my brainfart. This is not fixing the probl
On Sun, Mar 01, 2015 at 12:41:10PM -0800, Yinghai Lu wrote:
> Does not look safe yet...
Why?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
On Sun, Mar 1, 2015 at 12:29 PM, Borislav Petkov wrote:
> On Sun, Mar 01, 2015 at 12:24:08PM -0800, Yinghai Lu wrote:
>> static allocation in misc.c can not be used to kernel/head_64.S stage safely.
>
> Correct. One possibility that works is sticking it right below
> LOAD_PHYSICAL_ADDR:
>
> +stati
On Sun, Mar 01, 2015 at 12:24:08PM -0800, Yinghai Lu wrote:
> static allocation in misc.c can not be used to kernel/head_64.S stage safely.
Correct. One possibility that works is sticking it right below
LOAD_PHYSICAL_ADDR:
+static void add_kaslr_setup_data(struct boot_params *params,
+
On Sun, Mar 1, 2015 at 11:49 AM, Borislav Petkov wrote:
> On Sun, Mar 01, 2015 at 11:27:48AM -0800, Yinghai Lu wrote:
>> other 7 should also address the problem in
>>http://lkml.kernel.org/r/1424929021.10337.24.ca...@intel.com
>
> No, they don't:
>
> [0.00] parse_setup_data: data: 0x22
On Sun, Mar 01, 2015 at 11:27:48AM -0800, Yinghai Lu wrote:
> other 7 should also address the problem in
>http://lkml.kernel.org/r/1424929021.10337.24.ca...@intel.com
No, they don't:
[0.00] parse_setup_data: data: 0x2206e50 (va: ff200e50) { next:
0x0, type: 0x0, len: 16, data
On Sun, Mar 01, 2015 at 04:23:51PM +0100, Ingo Molnar wrote:
> I think that's a different bug.
>
> parse_kaslr_setup() is simply bogus, it does:
>
> kaslr_enabled = (bool)(pa_data + sizeof(struct setup_data));
Well, we found that while debugging the other issue too:
https://lkml.kernel.
On Sun, Mar 1, 2015 at 7:23 AM, Ingo Molnar wrote:
>
> I think that's a different bug.
>
> parse_kaslr_setup() is simply bogus, it does:
>
> kaslr_enabled = (bool)(pa_data + sizeof(struct setup_data));
>
> which makes no sense whatsoever: it randomly enables (or disables,
> depending on th
(Cc:-ed Jiri and Kees as well.)
* Borislav Petkov wrote:
> On Sat, Feb 28, 2015 at 06:40:39PM -0800, Yinghai Lu wrote:
> >
> > oh, no. the offending commit already got into linus tree.
>
> We're working on it, follow this thread:
>
> http://lkml.kernel.org/r/1424929021.10337.24.ca...@intel.co
On Sat, Feb 28, 2015 at 06:40:39PM -0800, Yinghai Lu wrote:
> oh, no. the offending commit already got into linus tree.
We're working on it, follow this thread:
http://lkml.kernel.org/r/1424929021.10337.24.ca...@intel.com
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you repl
On Sat, Feb 28, 2015 at 6:17 PM, Yinghai Lu wrote:
> We should access variable with referrence instead of using physical
> address as value.
>
> Cc: Matt Fleming
> Cc: Borislav Petkov
> Signed-off-by: Yinghai Lu
> ---
> arch/x86/kernel/setup.c | 8 +++-
> 1 file changed, 7 insertions(+), 1
We should access variable with referrence instead of using physical
address as value.
Cc: Matt Fleming
Cc: Borislav Petkov
Signed-off-by: Yinghai Lu
---
arch/x86/kernel/setup.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/
18 matches
Mail list logo
