Re: [PATCH v2] x86/efi: Disable runtime services on kexec kernel if booted with efi=old_map

at we don't > panic. > > Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> > Cc: Borislav Petkov <b...@alien8.de> > Cc: Ricardo Neri <ricardo.n...@intel.com> > Cc: Matt Fleming <m...@codeblueprint.co.uk> > Cc: Ard Biesheuvel <a

Re: [PATCH v2] x86/efi: Disable runtime services on kexec kernel if booted with efi=old_map

gt; else is mapped at the virtual address we allocated for runtime service > regions in the initial boot] - Matt Fleming > > Since kexec was never intended to work with efi=old_map, disable > runtime services in kexec if booted with efi=old_map, so that we don't > panic. > >

Re: [PATCH] x86/efi: Fix kexec kernel panic when efi=old_map is enabled

On 05/15/17 at 02:23pm, Matt Fleming wrote: > (Pulling in Dave, Mr. Kexec on EFI) > > On Mon, 08 May, at 12:25:23PM, Sai Praneeth Prakhya wrote: > > From: Sai Praneeth > > > > Booting kexec kernel with "efi=old_map" in kernel command line hits > > kernel panic as

Re: [PATCH] x86/efi: Fix kexec kernel panic when efi=old_map is enabled

On 05/15/17 at 02:23pm, Matt Fleming wrote: > (Pulling in Dave, Mr. Kexec on EFI) > > On Mon, 08 May, at 12:25:23PM, Sai Praneeth Prakhya wrote: > > From: Sai Praneeth > > > > Booting kexec kernel with "efi=old_map" in kernel command line hits > > kernel panic as shown below. > > > > [

[PATCH] efi/bgrt: skip efi_bgrt_init in case non-efi boot

1 ---[ end trace f68728a0d3053b52 ]--- Kernel panic - not syncing: Attempted to kill the idle task! ---[ end Kernel panic - not syncing: Attempted to kill the idle task! Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code") Signed-off-by: Dave Young <dyo...@r

[PATCH] efi/bgrt: skip efi_bgrt_init in case non-efi boot

1 ---[ end trace f68728a0d3053b52 ]--- Kernel panic - not syncing: Attempted to kill the idle task! ---[ end Kernel panic - not syncing: Attempted to kill the idle task! Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code") Signed-off-by: Dave Young Tested-by: Sab

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

On 05/15/17 at 01:10pm, Sabrina Dubroca wrote: > 2017-05-15, 16:37:40 +0800, Dave Young wrote: > > Hi, > > > > Thanks for the report. > > On 05/14/17 at 01:18am, Sabrina Dubroca wrote: > > > 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > &g

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

On 05/15/17 at 01:10pm, Sabrina Dubroca wrote: > 2017-05-15, 16:37:40 +0800, Dave Young wrote: > > Hi, > > > > Thanks for the report. > > On 05/14/17 at 01:18am, Sabrina Dubroca wrote: > > > 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > > >

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

Hi, Thanks for the report. On 05/14/17 at 01:18am, Sabrina Dubroca wrote: > 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > > From: Dave Young <dyo...@redhat.com> > > > > Before invoking the arch specific handler, efi_mem_reserve() reserves > > the giv

Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

Hi, Thanks for the report. On 05/14/17 at 01:18am, Sabrina Dubroca wrote: > 2017-01-31, 13:21:40 +, Ard Biesheuvel wrote: > > From: Dave Young > > > > Before invoking the arch specific handler, efi_mem_reserve() reserves > > the given memory region through membl

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/27/17 at 08:52am, Dave Hansen wrote: > On 04/27/2017 12:25 AM, Dave Young wrote: > > On 04/21/17 at 02:55pm, Dave Hansen wrote: > >> On 04/18/2017 02:22 PM, Tom Lendacky wrote: > >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can &g

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/27/17 at 08:52am, Dave Hansen wrote: > On 04/27/2017 12:25 AM, Dave Young wrote: > > On 04/21/17 at 02:55pm, Dave Hansen wrote: > >> On 04/18/2017 02:22 PM, Tom Lendacky wrote: > >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can &g

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Correct Vivek's email address On 04/28/17 at 01:19pm, Dave Young wrote: > Vivek, can you help to give some comments about the locate hole isssue > in kexec_file? > > On 04/28/17 at 09:51am, AKASHI Takahiro wrote: > > Thiago, > > > > Thank you for the comment. >

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Correct Vivek's email address On 04/28/17 at 01:19pm, Dave Young wrote: > Vivek, can you help to give some comments about the locate hole isssue > in kexec_file? > > On 04/28/17 at 09:51am, AKASHI Takahiro wrote: > > Thiago, > > > > Thank you for the comment. >

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Vivek, can you help to give some comments about the locate hole isssue in kexec_file? On 04/28/17 at 09:51am, AKASHI Takahiro wrote: > Thiago, > > Thank you for the comment. > > On Thu, Apr 27, 2017 at 07:00:04PM -0300, Thiago Jung Bauermann wrote: > > Hello, > > > > Am Mittwoch, 26. April

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Vivek, can you help to give some comments about the locate hole isssue in kexec_file? On 04/28/17 at 09:51am, AKASHI Takahiro wrote: > Thiago, > > Thank you for the comment. > > On Thu, Apr 27, 2017 at 07:00:04PM -0300, Thiago Jung Bauermann wrote: > > Hello, > > > > Am Mittwoch, 26. April

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Hi AKASHI On 04/26/17 at 05:22pm, AKASHI Takahiro wrote: > The current kexec_locate_mem_hole(kbuf.top_down == 1) stops searching at > the first memory region that has enough space for requested size even if > some of higher regions may also have. > This behavior is not consistent with

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Hi AKASHI On 04/26/17 at 05:22pm, AKASHI Takahiro wrote: > The current kexec_locate_mem_hole(kbuf.top_down == 1) stops searching at > the first memory region that has enough space for requested size even if > some of higher regions may also have. > This behavior is not consistent with

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/21/17 at 02:55pm, Dave Hansen wrote: > On 04/18/2017 02:22 PM, Tom Lendacky wrote: > > Add sysfs support for SME so that user-space utilities (kdump, etc.) can > > determine if SME is active. > > > > A new directory will be created: > > /sys/kernel/mm/sme/ > > > > And two entries within

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/21/17 at 02:55pm, Dave Hansen wrote: > On 04/18/2017 02:22 PM, Tom Lendacky wrote: > > Add sysfs support for SME so that user-space utilities (kdump, etc.) can > > determine if SME is active. > > > > A new directory will be created: > > /sys/kernel/mm/sme/ > > > > And two entries within

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

Hi Xunlei, On 04/27/17 at 01:25pm, Xunlei Pang wrote: > On 04/27/2017 at 11:06 AM, Dave Young wrote: > > [snip] > >>>>> > >>>>> static int __init crash_save_vmcoreinfo_init(void) > >>>>> { > >>>>> + /* One

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

Hi Xunlei, On 04/27/17 at 01:25pm, Xunlei Pang wrote: > On 04/27/2017 at 11:06 AM, Dave Young wrote: > > [snip] > >>>>> > >>>>> static int __init crash_save_vmcoreinfo_init(void) > >>>>> { > >>>>> + /* One

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

[snip] > >>> > >>> static int __init crash_save_vmcoreinfo_init(void) > >>> { > >>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */ > >> Can we add a comment in the VMCOREINFO_BYTES header file about the one > >> page assumption? > >> > >> Or just define the

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

[snip] > >>> > >>> static int __init crash_save_vmcoreinfo_init(void) > >>> { > >>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */ > >> Can we add a comment in the VMCOREINFO_BYTES header file about the one > >> page assumption? > >> > >> Or just define the

Re: [PATCH v4 3/3] kdump: Protect vmcoreinfo data under the crash memory

[snip] > >> index 43cdb00..a29e9ad 100644 > >> --- a/kernel/crash_core.c > >> +++ b/kernel/crash_core.c > >> @@ -15,9 +15,12 @@ > >> > >> /* vmcoreinfo stuff */ > >> static unsigned char *vmcoreinfo_data; > >> -size_t vmcoreinfo_size; > >> +static size_t vmcoreinfo_size; > >> u32

Re: [PATCH v4 3/3] kdump: Protect vmcoreinfo data under the crash memory

[snip] > >> index 43cdb00..a29e9ad 100644 > >> --- a/kernel/crash_core.c > >> +++ b/kernel/crash_core.c > >> @@ -15,9 +15,12 @@ > >> > >> /* vmcoreinfo stuff */ > >> static unsigned char *vmcoreinfo_data; > >> -size_t vmcoreinfo_size; > >> +static size_t vmcoreinfo_size; > >> u32

Re: [PATCH] memmap: Parse "Reserved" together with "reserved"

On 04/26/17 at 03:28pm, Dave Young wrote: > On 04/26/17 at 08:22am, Ingo Molnar wrote: > > > > * Yinghai Lu <ying...@kernel.org> wrote: > > > > > For x86 with recent kernel after > > > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820

Re: [PATCH] memmap: Parse "Reserved" together with "reserved"

On 04/26/17 at 03:28pm, Dave Young wrote: > On 04/26/17 at 08:22am, Ingo Molnar wrote: > > > > * Yinghai Lu wrote: > > > > > For x86 with recent kernel after > > > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c") > > &g

Re: [PATCH] memmap: Parse "Reserved" together with "reserved"

On 04/26/17 at 08:22am, Ingo Molnar wrote: > > * Yinghai Lu wrote: > > > For x86 with recent kernel after > > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c") > > change "reserved" to "Reserved" in /sys firmware memmap and /proc/iomem. > > > > So here, we add

Re: [PATCH] memmap: Parse "Reserved" together with "reserved"

On 04/26/17 at 08:22am, Ingo Molnar wrote: > > * Yinghai Lu wrote: > > > For x86 with recent kernel after > > commit 640e1b38b0 ("x86/boot/e820: Basic cleanup of e820.c") > > change "reserved" to "Reserved" in /sys firmware memmap and /proc/iomem. > > > > So here, we add handling for that

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

Add ia64i list, and s390 list although Michael has tested it On 04/20/17 at 07:39pm, Xunlei Pang wrote: > As Eric said, > "what we need to do is move the variable vmcoreinfo_note out > of the kernel's .bss section. And modify the code to regenerate > and keep this information in something like

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

Add ia64i list, and s390 list although Michael has tested it On 04/20/17 at 07:39pm, Xunlei Pang wrote: > As Eric said, > "what we need to do is move the variable vmcoreinfo_note out > of the kernel's .bss section. And modify the code to regenerate > and keep this information in something like

Re: [PATCH v4 2/3] powerpc/fadump: Use the correct VMCOREINFO_NOTE_SIZE for phdr

..) > r = vscnprintf(buf, sizeof(buf), fmt, args); > va_end(args); > > - r = min(r, vmcoreinfo_max_size - vmcoreinfo_size); > + r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size); > > memcpy(_data[vmcoreinfo_size], buf, r); > > -- > 1.8.3.1 > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec Reviewed-by: Dave Young <dyo...@redhat.com> Thanks Dave

Re: [PATCH v4 2/3] powerpc/fadump: Use the correct VMCOREINFO_NOTE_SIZE for phdr

= min(r, vmcoreinfo_max_size - vmcoreinfo_size); > + r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size); > > memcpy(_data[vmcoreinfo_size], buf, r); > > -- > 1.8.3.1 > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec Reviewed-by: Dave Young Thanks Dave

Re: [PATCH v4 3/3] kdump: Protect vmcoreinfo data under the crash memory

On 04/20/17 at 07:39pm, Xunlei Pang wrote: > Currently vmcoreinfo data is updated at boot time subsys_initcall(), > it has the risk of being modified by some wrong code during system > is running. > > As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on, > when using "crash",

Re: [PATCH v4 3/3] kdump: Protect vmcoreinfo data under the crash memory

On 04/20/17 at 07:39pm, Xunlei Pang wrote: > Currently vmcoreinfo data is updated at boot time subsys_initcall(), > it has the risk of being modified by some wrong code during system > is running. > > As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on, > when using "crash",

Re: KASLR causes intermittent boot failures on some systems

On 04/12/17 at 04:24pm, Dave Young wrote: > On 04/07/17 at 10:41am, Jeff Moyer wrote: > > Hi, > > > > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory > > regions") causes some of my systems with persistent memory (whether real > >

Re: KASLR causes intermittent boot failures on some systems

On 04/12/17 at 04:24pm, Dave Young wrote: > On 04/07/17 at 10:41am, Jeff Moyer wrote: > > Hi, > > > > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory > > regions") causes some of my systems with persistent memory (whether real > >

Re: KASLR causes intermittent boot failures on some systems

On 04/12/17 at 04:24pm, Dave Young wrote: > On 04/07/17 at 10:41am, Jeff Moyer wrote: > > Hi, > > > > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory > > regions") causes some of my systems with persistent memory (whether real > >

Re: KASLR causes intermittent boot failures on some systems

On 04/12/17 at 04:24pm, Dave Young wrote: > On 04/07/17 at 10:41am, Jeff Moyer wrote: > > Hi, > > > > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory > > regions") causes some of my systems with persistent memory (whether real > >

Re: KASLR causes intermittent boot failures on some systems

On 04/07/17 at 10:41am, Jeff Moyer wrote: > Hi, > > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory > regions") causes some of my systems with persistent memory (whether real > or emulated) to fail to boot with a couple of different crash > signatures. The first signature

Re: KASLR causes intermittent boot failures on some systems

On 04/07/17 at 10:41am, Jeff Moyer wrote: > Hi, > > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory > regions") causes some of my systems with persistent memory (whether real > or emulated) to fail to boot with a couple of different crash > signatures. The first signature

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On 04/07/17 at 04:28am, Mimi Zohar wrote: > On Fri, 2017-04-07 at 15:41 +0800, Dave Young wrote: > > On 04/07/17 at 08:07am, David Howells wrote: > > > Dave Young <dyo...@redhat.com> wrote: > > > > > > > > > > + /* Don't permit images to

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On 04/07/17 at 04:28am, Mimi Zohar wrote: > On Fri, 2017-04-07 at 15:41 +0800, Dave Young wrote: > > On 04/07/17 at 08:07am, David Howells wrote: > > > Dave Young wrote: > > > > > > > > > > + /* Don't permit images to be loa

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On 04/07/17 at 03:45am, Mimi Zohar wrote: > On Fri, 2017-04-07 at 14:19 +0800, Dave Young wrote: > > On 04/06/17 at 11:49pm, Mimi Zohar wrote: > > > On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote: > > > > On 04/05/17 at 09:15pm, David Howells wrote: > >

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On 04/07/17 at 03:45am, Mimi Zohar wrote: > On Fri, 2017-04-07 at 14:19 +0800, Dave Young wrote: > > On 04/06/17 at 11:49pm, Mimi Zohar wrote: > > > On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote: > > > > On 04/05/17 at 09:15pm, David Howells wrot

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On 04/07/17 at 08:07am, David Howells wrote: > Dave Young <dyo...@redhat.com> wrote: > > > > > > + /* Don't permit images to be loaded into trusted kernels if > > > > > we're not > > > > > + * going to verify the signature on

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On 04/07/17 at 08:07am, David Howells wrote: > Dave Young wrote: > > > > > > + /* Don't permit images to be loaded into trusted kernels if > > > > > we're not > > > > > + * going to verify the signature on them > > > > >

Re: [PATCH 17/24] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

On 04/07/17 at 08:05am, David Howells wrote: > Dave Young <dyo...@redhat.com> wrote: > > > > > This option allows userspace to pass the RSDP address to the kernel, > > > > which > > > > makes it possible for a user to circumvent any restrict

Re: [PATCH 17/24] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

On 04/07/17 at 08:05am, David Howells wrote: > Dave Young wrote: > > > > > This option allows userspace to pass the RSDP address to the kernel, > > > > which > > > > makes it possible for a user to circumvent any restrictions imposed on > &

Re: [PATCH 17/24] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

On 04/06/17 at 09:43pm, Rafael J. Wysocki wrote: > On Wed, Apr 5, 2017 at 10:16 PM, David Howells wrote: > > From: Josh Boyer > > > > This option allows userspace to pass the RSDP address to the kernel, which > > makes it possible for a user to circumvent

Re: [PATCH 17/24] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

On 04/06/17 at 09:43pm, Rafael J. Wysocki wrote: > On Wed, Apr 5, 2017 at 10:16 PM, David Howells wrote: > > From: Josh Boyer > > > > This option allows userspace to pass the RSDP address to the kernel, which > > makes it possible for a user to circumvent any restrictions imposed on > > loading

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On 04/06/17 at 11:49pm, Mimi Zohar wrote: > On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote: > > On 04/05/17 at 09:15pm, David Howells wrote: > > > From: Chun-Yi Lee <joeyli.ker...@gmail.com> > > > > > > When KEXEC_VERIFY_SIG is not enabled, k

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On 04/06/17 at 11:49pm, Mimi Zohar wrote: > On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote: > > On 04/05/17 at 09:15pm, David Howells wrote: > > > From: Chun-Yi Lee > > > > > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image

Re: [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down

return -EPERM; > + > + /* >* Verify we have a legal set of flags >* This leaves us room for future extensions. >*/ > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec Acked-by: Dave Young <dyo...@redhat.com> Thanks Dave

Re: [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down

>* Verify we have a legal set of flags >* This leaves us room for future extensions. >*/ > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec Acked-by: Dave Young Thanks Dave

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

ABLED(CONFIG_KEXEC_VERIFY_SIG) && kernel_is_locked_down()) > + return -EPERM; > + > /* Make sure we have a legal set of flags */ > if (flags != (flags & KEXEC_FILE_FLAGS)) > return -EINVAL; > > > _____

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

t; + > /* Make sure we have a legal set of flags */ > if (flags != (flags & KEXEC_FILE_FLAGS)) > return -EINVAL; > > > _______ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec Acked-by: Dave Young Thanks Dave

Re: kexec regression since 4.9 caused by efi

On 04/04/17 at 02:37pm, Matt Fleming wrote: > On Mon, 20 Mar, at 10:14:12AM, Dave Young wrote: > > > > Matt, I'm fine if you prefer to capture the range checking errors. > > Would you like me to post it or just you send it out? > > Can you please send out the pa

Re: kexec regression since 4.9 caused by efi

On 04/04/17 at 02:37pm, Matt Fleming wrote: > On Mon, 20 Mar, at 10:14:12AM, Dave Young wrote: > > > > Matt, I'm fine if you prefer to capture the range checking errors. > > Would you like me to post it or just you send it out? > > Can you please send out the pa

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

.c fixes this problem. > > > > Cc: <sta...@vger.kernel.org> #4.8+ > > Signed-off-by: Baoquan He <b...@redhat.com> > > Acked-by: Dave Young <dyo...@redhat.com> > > Reviewed-by: Bhupesh Sharma <bhsha...@redhat.com> > > Acked-by: Thomas Garnie

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

ffef - fffe (=64 GB) EFI region mapping space > > EFI use the space from -4G to -64G thus EFI_VA_START > EFI_VA_END, > > Here EFI_VA_START = -4G, and EFI_VA_END = -64G. > > > > Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this probl

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

On 03/24/17 at 04:34pm, Baoquan He wrote: > On 03/24/17 at 09:08am, Ingo Molnar wrote: > > > Cc: <sta...@vger.kernel.org> #4.8+ > > > Signed-off-by: Baoquan He <b...@redhat.com> > > > Acked-by: Dave Young <dyo...@redhat.com> > > > Revi

Re: [PATCH v2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

On 03/24/17 at 04:34pm, Baoquan He wrote: > On 03/24/17 at 09:08am, Ingo Molnar wrote: > > > Cc: #4.8+ > > > Signed-off-by: Baoquan He > > > Acked-by: Dave Young > > > Reviewed-by: Bhupesh Sharma > > > Acked-by: Thomas Garnier > > >

Re: [PATCH v1 RESEND 1/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

This should also cc linux-efi On 03/24/17 at 10:29am, Dave Young wrote: > Hi, Baoquan > > On 03/23/17 at 11:27am, Baoquan He wrote: > > Currently KASLR is enabled on three regions: the direct mapping of physical > > memory, vamlloc and vmemmap. However EFI region is als

Re: [PATCH v1 RESEND 1/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

This should also cc linux-efi On 03/24/17 at 10:29am, Dave Young wrote: > Hi, Baoquan > > On 03/23/17 at 11:27am, Baoquan He wrote: > > Currently KASLR is enabled on three regions: the direct mapping of physical > > memory, vamlloc and vmemmap. However EFI region is als

Re: [PATCH v1 RESEND 1/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

ping space > EFI use the space from -4G to -64G thus EFI_VA_START > EFI_VA_END > Here EFI_VA_START = -4G, and EFI_VA_END = -64G > > Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem. > > Cc: <sta...@vger.kernel.org> #4.8+ > Signed-off-by: B

Re: [PATCH v1 RESEND 1/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

ping space > EFI use the space from -4G to -64G thus EFI_VA_START > EFI_VA_END > Here EFI_VA_START = -4G, and EFI_VA_END = -64G > > Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem. > > Cc: #4.8+ > Signed-off-by: Baoquan He > Acked-by: Dave Youn

Re: kexec regression since 4.9 caused by efi

On 03/22/17 at 04:10pm, Ard Biesheuvel wrote: > On 21 March 2017 at 07:48, Dave Young <dyo...@redhat.com> wrote: > > On 03/20/17 at 10:14am, Dave Young wrote: > >> On 03/17/17 at 01:32pm, Matt Fleming wrote: > >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wr

Re: kexec regression since 4.9 caused by efi

On 03/22/17 at 04:10pm, Ard Biesheuvel wrote: > On 21 March 2017 at 07:48, Dave Young wrote: > > On 03/20/17 at 10:14am, Dave Young wrote: > >> On 03/17/17 at 01:32pm, Matt Fleming wrote: > >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > >> >

Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

On 03/21/17 at 10:18pm, Eric W. Biederman wrote: > Dave Young <dyo...@redhat.com> writes: > > > On 03/20/17 at 10:33pm, Eric W. Biederman wrote: > >> Xunlei Pang <xlp...@redhat.com> writes: > >> > >> > As Eric said, > >>

Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

On 03/21/17 at 10:18pm, Eric W. Biederman wrote: > Dave Young writes: > > > On 03/20/17 at 10:33pm, Eric W. Biederman wrote: > >> Xunlei Pang writes: > >> > >> > As Eric said, > >> > "what we need to do is move the variable vmcoreinf

Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

On 03/20/17 at 10:33pm, Eric W. Biederman wrote: > Xunlei Pang writes: > > > As Eric said, > > "what we need to do is move the variable vmcoreinfo_note out > > of the kernel's .bss section. And modify the code to regenerate > > and keep this information in something like the

Re: [PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

On 03/20/17 at 10:33pm, Eric W. Biederman wrote: > Xunlei Pang writes: > > > As Eric said, > > "what we need to do is move the variable vmcoreinfo_note out > > of the kernel's .bss section. And modify the code to regenerate > > and keep this information in something like the control page. > > >

Re: kexec regression since 4.9 caused by efi

On 03/20/17 at 10:14am, Dave Young wrote: > On 03/17/17 at 01:32pm, Matt Fleming wrote: > > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > > > > > > Matt, I think it should be fine although I think the md type checking in > > > efi_mem_desc_lookup

Re: kexec regression since 4.9 caused by efi

On 03/20/17 at 10:14am, Dave Young wrote: > On 03/17/17 at 01:32pm, Matt Fleming wrote: > > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > > > > > > Matt, I think it should be fine although I think the md type checking in > > > efi_mem_desc_lookup

Re: kexec regression since 4.9 caused by efi

On 03/17/17 at 01:32pm, Matt Fleming wrote: > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > > > > Matt, I think it should be fine although I think the md type checking in > > efi_mem_desc_lookup() is causing confusion and not easy to understand.. > > Could you

Re: kexec regression since 4.9 caused by efi

On 03/17/17 at 01:32pm, Matt Fleming wrote: > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > > > > Matt, I think it should be fine although I think the md type checking in > > efi_mem_desc_lookup() is causing confusion and not easy to understand.. > > Could you

Re: kexec regression since 4.9 caused by efi

On 03/16/17 at 12:41pm, Matt Fleming wrote: > On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote: > > > > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is > > not > > correct to be used in efi_arch_mem_reserve, if it passed your test, I > >

Re: kexec regression since 4.9 caused by efi

On 03/16/17 at 12:41pm, Matt Fleming wrote: > On Mon, 13 Mar, at 03:37:48PM, Dave Young wrote: > > > > Omar, could you try below patch? Looking at the efi_mem_desc_lookup, it is > > not > > correct to be used in efi_arch_mem_reserve, if it passed your test, I > >

Re: kexec regression since 4.9 caused by efi

On 03/09/17 at 01:54am, Omar Sandoval wrote: > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote: > > Add efi/kexec list. > > > > On 03/08/17 at 12:16pm, Omar Sandoval wrote: > > [snip] > > > I have no more clue yet from your provided log, bu

Re: kexec regression since 4.9 caused by efi

On 03/09/17 at 01:54am, Omar Sandoval wrote: > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote: > > Add efi/kexec list. > > > > On 03/08/17 at 12:16pm, Omar Sandoval wrote: > > [snip] > > > I have no more clue yet from your provided log, bu

Re: kexec regression since 4.9 caused by efi

On 03/09/17 at 01:54am, Omar Sandoval wrote: > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote: > > Add efi/kexec list. > > > > On 03/08/17 at 12:16pm, Omar Sandoval wrote: > > [snip] > > > I have no more clue yet from your provided log, bu

Re: kexec regression since 4.9 caused by efi

On 03/09/17 at 01:54am, Omar Sandoval wrote: > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote: > > Add efi/kexec list. > > > > On 03/08/17 at 12:16pm, Omar Sandoval wrote: > > [snip] > > > I have no more clue yet from your provided log, bu

Re: kexec regression since 4.9 caused by efi

On 03/09/17 at 12:53pm, Ard Biesheuvel wrote: > On 9 March 2017 at 10:54, Omar Sandoval <osan...@osandov.com> wrote: > > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote: > >> Add efi/kexec list. > >> > >> On 03/08/17 at 12:16pm, Omar Sand

Re: kexec regression since 4.9 caused by efi

On 03/09/17 at 12:53pm, Ard Biesheuvel wrote: > On 9 March 2017 at 10:54, Omar Sandoval wrote: > > On Thu, Mar 09, 2017 at 02:38:06PM +0800, Dave Young wrote: > >> Add efi/kexec list. > >> > >> On 03/08/17 at 12:16pm, Omar Sandoval wrote: > > > > [

Re: kexec regression since 4.9 caused by efi

Add efi/kexec list. On 03/08/17 at 12:16pm, Omar Sandoval wrote: > Hi, everyone, > > Since 4.9, kexec results in the following panic on some of our servers: > > [0.001000] general protection fault: [#1] SMP > [0.001000] Modules linked in: > [0.001000] CPU: 0 PID: 0 Comm:

Re: kexec regression since 4.9 caused by efi

Add efi/kexec list. On 03/08/17 at 12:16pm, Omar Sandoval wrote: > Hi, everyone, > > Since 4.9, kexec results in the following panic on some of our servers: > > [0.001000] general protection fault: [#1] SMP > [0.001000] Modules linked in: > [0.001000] CPU: 0 PID: 0 Comm:

Re: kexec regression since 4.9 caused by efi

On 03/08/17 at 12:16pm, Omar Sandoval wrote: > Hi, everyone, > > Since 4.9, kexec results in the following panic on some of our servers: > > [0.001000] general protection fault: [#1] SMP > [0.001000] Modules linked in: > [0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted

Re: kexec regression since 4.9 caused by efi

On 03/08/17 at 12:16pm, Omar Sandoval wrote: > Hi, everyone, > > Since 4.9, kexec results in the following panic on some of our servers: > > [0.001000] general protection fault: [#1] SMP > [0.001000] Modules linked in: > [0.001000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

Hi, On 03/08/17 at 04:45pm, Baoquan He wrote: > Forgot cc to Boris, add him. > > On 03/08/17 at 04:18pm, Dave Young wrote: > > On 03/08/17 at 03:47pm, Baoquan He wrote: > > > EFI allocate runtime services regions down from EFI_VA_START, -4G. > > &g

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

Hi, On 03/08/17 at 04:45pm, Baoquan He wrote: > Forgot cc to Boris, add him. > > On 03/08/17 at 04:18pm, Dave Young wrote: > > On 03/08/17 at 03:47pm, Baoquan He wrote: > > > EFI allocate runtime services regions down from EFI_VA_START, -4G. > > &g

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

On 03/08/17 at 11:50am, Borislav Petkov wrote: > On Wed, Mar 08, 2017 at 06:17:50PM +0800, Baoquan He wrote: > > All right, I will just update the code comment. Just back ported kaslr > > to our OS product, people reviewed and found the upper boundary of kaslr > > mm region is EFI_VA_START, that's

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

On 03/08/17 at 11:50am, Borislav Petkov wrote: > On Wed, Mar 08, 2017 at 06:17:50PM +0800, Baoquan He wrote: > > All right, I will just update the code comment. Just back ported kaslr > > to our OS product, people reviewed and found the upper boundary of kaslr > > mm region is EFI_VA_START, that's

Re: [PATCH 2/2] x86/mm/KASLR: Correct the upper boundary of KALSR mm regions if adjacent to EFI

_X86_ESPFIX64) || > IS_ENABLED(CONFIG_EFI)) && >vaddr_end >= __START_KERNEL_map); > -- > 2.5.5 > Acked-by: Dave Young <dyo...@redhat.com> Thanks Dave

Re: [PATCH 2/2] x86/mm/KASLR: Correct the upper boundary of KALSR mm regions if adjacent to EFI

IS_ENABLED(CONFIG_EFI)) && >vaddr_end >= __START_KERNEL_map); > -- > 2.5.5 > Acked-by: Dave Young Thanks Dave

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

On 03/08/17 at 03:47pm, Baoquan He wrote: > EFI allocate runtime services regions down from EFI_VA_START, -4G. > It should be top-down handling. > > Signed-off-by: Baoquan He > --- > arch/x86/platform/efi/efi_64.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >

Re: [PATCH 1/2] x86/efi: Correct a tiny mistake in code comment

On 03/08/17 at 03:47pm, Baoquan He wrote: > EFI allocate runtime services regions down from EFI_VA_START, -4G. > It should be top-down handling. > > Signed-off-by: Baoquan He > --- > arch/x86/platform/efi/efi_64.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

On 03/06/17 at 11:58am, Tom Lendacky wrote: > On 3/1/2017 3:25 AM, Dave Young wrote: > > Hi Tom, > > Hi Dave, > > > > > On 02/17/17 at 10:43am, Tom Lendacky wrote: > > > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote: > > > > On Thu, F

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

On 03/06/17 at 11:58am, Tom Lendacky wrote: > On 3/1/2017 3:25 AM, Dave Young wrote: > > Hi Tom, > > Hi Dave, > > > > > On 02/17/17 at 10:43am, Tom Lendacky wrote: > > > On 2/17/2017 9:57 AM, Konrad Rzeszutek Wilk wrote: > > > > On Thu, F

<    1   2   3   4   5   6   7   8   9   10   >