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
> ---
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
>
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
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
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]
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
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
On Mon, Mar 2, 2015 at 12:25 PM, Borislav Petkov b...@suse.de 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
---
On Mon, Mar 02, 2015 at 10:58:23AM -0800, Yinghai Lu wrote:
On Mon, Mar 2, 2015 at 6:53 AM, Borislav Petkov b...@suse.de 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.
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
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 matt.flem...@intel.com
Cc: Borislav Petkov b...@suse.de
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/kernel/setup.c | 8
On Mon, Mar 2, 2015 at 12:56 AM, Borislav Petkov b...@suse.de 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:
On Sat, 28 Feb 2015, Yinghai Lu wrote:
We should access variable with referrence instead of using physical
address as value.
Cc: Matt Fleming matt.flem...@intel.com
Cc: Borislav Petkov b...@suse.de
Signed-off-by: Yinghai Lu ying...@kernel.org
Acked-by: Jiri Kosina jkos...@suse.cz
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
On Mon, Mar 2, 2015 at 6:53 AM, Borislav Petkov b...@suse.de 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 -
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:
>
>
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:
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,
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:
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
(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:
>
>
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
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
On Sun, Mar 1, 2015 at 7:23 AM, Ingo Molnar mi...@kernel.org 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,
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:
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,
(Cc:-ed Jiri and Kees as well.)
* Borislav Petkov b...@suse.de 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:
On Sun, Mar 1, 2015 at 11:49 AM, Borislav Petkov b...@suse.de 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:
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 12:29 PM, Borislav Petkov b...@suse.de 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:
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(+),
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
We should access variable with referrence instead of using physical
address as value.
Cc: Matt Fleming matt.flem...@intel.com
Cc: Borislav Petkov b...@suse.de
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/kernel/setup.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
On Sat, Feb 28, 2015 at 6:17 PM, Yinghai Lu ying...@kernel.org wrote:
We should access variable with referrence instead of using physical
address as value.
Cc: Matt Fleming matt.flem...@intel.com
Cc: Borislav Petkov b...@suse.de
Signed-off-by: Yinghai Lu ying...@kernel.org
---
36 matches
Mail list logo
