t the
efi.flags itself, it maybe useful for other arches and use cases.
Signed-off-by: Dave Young
---
drivers/firmware/efi/efi.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6/drivers/firmware/efi/efi.c
===
--- linu
On 05/26/14 at 04:39pm, Dave Young wrote:
>
> For efi=old_map and any old_map quirks like SGI UV in current
> tree kexec/kdump will fail because it depends on the new 1:1 mapping.
>
> Thus export the mapping method to sysfs so kexec tools can switch
> to original way to boot.
On 05/27/14 at 02:36pm, Fleming, Matt wrote:
> On 27 May 2014 04:00, Dave Young wrote:
> > On 05/26/14 at 04:39pm, Dave Young wrote:
> >>
> >> For efi=old_map and any old_map quirks like SGI UV in current
> >> tree kexec/kdump will fail because it depends on
On 05/27/14 at 09:34am, Vivek Goyal wrote:
> On Mon, May 26, 2014 at 04:39:35PM +0800, Dave Young wrote:
> >
> > For efi=old_map and any old_map quirks like SGI UV in current
> > tree kexec/kdump will fail because it depends on the new 1:1 mapping.
> >
> > Thus e
Add Alex to cc
> > The 1:1 mapping was required to make kexec + EFI work in the first
> > instance. If a machine implements the EFI 1:1 mapping, kexec should
> > work. If it doesn't implement the 1:1 mapping, then it's probably not
> > going to work, right?
> >
> > The crux of the question: are y
On 05/28/14 at 08:40am, Vivek Goyal wrote:
> On Wed, May 28, 2014 at 10:13:59AM +0800, Dave Young wrote:
> > On 05/27/14 at 09:34am, Vivek Goyal wrote:
> > > On Mon, May 26, 2014 at 04:39:35PM +0800, Dave Young wrote:
> > > >
> > > > For efi=old_map and
> > Question to Alex, if userspace can get the firmware version there might
> > be another option that kexec-tools checking the firmware version and
> > switch to old noefi way automaticlly. Is it doable?
>
> Userspace can get the firmware version easily, as long as our hwperf
> module is installe
On 05/29/14 at 10:08am, Dave Young wrote:
> On 05/28/14 at 08:40am, Vivek Goyal wrote:
> > On Wed, May 28, 2014 at 10:13:59AM +0800, Dave Young wrote:
> > > On 05/27/14 at 09:34am, Vivek Goyal wrote:
> > > > On Mon, May 26, 2014 at 04:39:35PM +0800, Dave Young wrote
On 05/29/14 at 02:10pm, Fleming, Matt wrote:
> On 29 May 2014 13:59, Vivek Goyal wrote:
> >
> > Only second kernel boots with "noefi" and this parameter is appened by
> > kexec-tools to second kernel command line. So first kernel will still
> > boot *without noefi* and kexec-tools wil think that t
On 05/29/14 at 08:45am, Vivek Goyal wrote:
> On Thu, May 29, 2014 at 10:08:37AM +0800, Dave Young wrote:
> > On 05/28/14 at 08:40am, Vivek Goyal wrote:
> > > On Wed, May 28, 2014 at 10:13:59AM +0800, Dave Young wrote:
> > > > On 05/27/14 at 09:34am, Vivek Goyal w
in case efi old_map so
userspace can use no efi boot instead.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 3781dd3..4d36932 100644
--- a/arch/x86/platform/efi/efi.c
one is still
safe.
On 05/30/14 at 11:20am, Dave Young wrote:
>
> For ioremapped efi memory aka old_map the virt addresses are not persistant
> across kexec reboot. kexec-tools will read the runtime maps from sysfs then
> pass them to 2nd kernel and assuming kexec efi boot is ok. Thi
On 05/30/14 at 03:08pm, Simon Horman wrote:
> On Fri, May 30, 2014 at 01:54:47PM +0800, Dave Young wrote:
> > Ccing Simon.
> >
> > Simon, appologize for not ccing you about this kernel patch. I see you have
> > applied the userspace patch for checking sysfs runt
On 08/06/14 at 03:01pm, Matt Fleming wrote:
> On Wed, 06 Aug, at 02:29:41PM, Leif Lindholm wrote:
> > On Wed, Aug 06, 2014 at 02:20:21PM +0100, Matt Fleming wrote:
> > > > Since this is really turning an x86-specific feature into a generic
> > > > one, could it be moved to core code?
> > > > Maybe
On 08/06/14 at 03:18pm, Matt Fleming wrote:
> On Wed, 06 Aug, at 04:10:45PM, Ard Biesheuvel wrote:
> >
> > Shouldn't we clear the bit here if we failed to enable runtime
> > services for some reason? Other code may test the bit assuming that it
> > signifies that runtime services have been enabled
On 08/07/14 at 09:26pm, Matt Fleming wrote:
> On Thu, 07 Aug, at 02:19:45PM, Dave Young wrote:
> >
> > The current efi_runtime_init() enables the bit after getting the efi
> > callback phyaddr of SetVirtualAddressMap.
> >
> > Thinking more about it, since
In case efi runtime disabled via noefi kernel cmdline arm64_enter_virtual_mode
should error out.
At the same time move early_memunmap(memmap.map, mapsize) to the beginning of
the function or it will leak early mem.
Signed-off-by: Dave Young
---
arch/arm64/kernel/efi.c | 7 ---
1 file
efi rtc depends on efi runtime services, so if efi runtime services are not
usable it should error out.
Without this patch rtc-efi will panic with 'noefi' boot
Signed-off-by: Dave Young
---
drivers/rtc/rtc-efi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/rtc/r
noefi kernel param means actually disabling efi runtime, Per suggestion from
Leif Lindholm efi=noruntime should be better. But since noefi is already used
in X86 thus just adding another param efi=noruntime for same purpose.
Signed-off-by: Dave Young
---
Documentation/kernel-parameters.txt | 4
will be not sure it's safe
to make any assumptions about the state of the system. so kernel panics instead
of clears EFI_RUNTIME_SERVICES bit.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/x86/pla
noefi param can be used for arches other than X86 later, thus move it out of
x86 platform code.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c | 10 +-
drivers/firmware/efi/efi.c | 13 +
include/linux/efi.h | 1 +
3 files changed, 15 insertions(+), 9
On 08/11/14 at 11:52pm, Randy Dunlap wrote:
> On 08/11/14 23:10, Dave Young wrote:
> > noefi param can be used for arches other than X86 later, thus move it out of
> > x86 platform code.
> >
> > Signed-off-by: Dave Young
> > ---
> > arch/x86/platform
On 08/12/14 at 11:46am, Will Deacon wrote:
> On Tue, Aug 12, 2014 at 07:10:20AM +0100, Dave Young wrote:
> > In case efi runtime disabled via noefi kernel cmdline
> > arm64_enter_virtual_mode
> > should error out.
> >
> > At the same time move early_memunmap(memm
On 08/12/14 at 02:10pm, Dave Young wrote:
> noefi kernel param means actually disabling efi runtime, Per suggestion from
> Leif Lindholm efi=noruntime should be better. But since noefi is already used
> in X86 thus just adding another param efi=noruntime for same purpose.
>
> Sign
There should be a generic function to parse params like a=b,c
Adding parse_option_str in lib/cmdline.c which will return true
if there's specified option set in the params.
Also updated efi=old_map parsing code to use the new function
Signed-off-by: Dave Young
---
arch/x86/platform/efi/
will be not sure it's safe
to make any assumptions about the state of the system. so kernel panics instead
of clears EFI_RUNTIME_SERVICES bit.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/platfor
noefi kernel param means actually disabling efi runtime, Per suggestion from
Leif Lindholm efi=noruntime should be better. But since noefi is already used
in X86 thus just adding another param efi=noruntime for same purpose.
Signed-off-by: Dave Young
---
Documentation/kernel-parameters.txt | 3
There's one early memmap leak in uefi_init error path, fix it and slightly tune
the error handling code.
Signed-off-by: Dave Young
---
arch/arm64/kernel/efi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
noefi param can be used for arches other than X86 later, thus move it out of
x86 platform code.
Signed-off-by: Dave Young
---
Documentation/kernel-parameters.txt | 2 +-
arch/x86/platform/efi/efi.c | 10 +-
drivers/firmware/efi/efi.c | 13 +
include/linux
In case efi runtime disabled via noefi kernel cmdline arm64_enter_virtual_mode
should error out.
At the same time move early_memunmap(memmap.map, mapsize) to the beginning of
the function or it will leak early mem.
Signed-off-by: Dave Young
---
arch/arm64/kernel/efi.c | 9 +++--
1 file
efi rtc depends on efi runtime services, so if efi runtime services are not
usable it should error out.
Without this patch rtc-efi will panic with 'noefi' boot
Signed-off-by: Dave Young
---
drivers/rtc/rtc-efi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/rtc/r
Hi,
I addressed several comments from Matt, Randy and Will in this post.
Also rewrote the patch for efi=noruntime with using a generic param handling
function.
CCed Xen and SGI people, removed rtc list in cc for [1-6]/7 patches
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubs
On 08/15/14 at 04:09pm, Will Deacon wrote:
> On Thu, Aug 14, 2014 at 10:15:30AM +0100, Dave Young wrote:
> > In case efi runtime disabled via noefi kernel cmdline
> > arm64_enter_virtual_mode
> > should error out.
> >
> > At the same time move early_memunmap(memm
In case efi runtime disabled via noefi kernel cmdline arm64_enter_virtual_mode
should error out.
At the same time move early_memunmap(memmap.map, mapsize) to the beginning of
the function or it will leak early mem.
Signed-off-by: Dave Young
---
arch/arm64/kernel/efi.c | 11 ---
1 file
Hi,
3.16 kernel boot fail with earlyprintk=efi on my laptop.
It keeps scrolling at the bottom line of screen.
Bisected, the first bad commit is below:
commit 86dfc6f339886559d80ee0d4bd20fe5ee90450f0
Author: Lv Zheng
Date: Fri Apr 4 12:38:57 2014 +0800
ACPICA: Tables: Fix table checksums v
On 08/21/14 at 09:52pm, Matt Fleming wrote:
> On Tue, 19 Aug, at 04:16:58PM, Dave Young wrote:
> > Hi,
> >
> > 3.16 kernel boot fail with earlyprintk=efi on my laptop.
> > It keeps scrolling at the bottom line of screen.
> >
> > Bisected, th
On 08/22/14 at 05:55am, Zheng, Lv wrote:
> Hi,
>
> I checked the arch/x86/platform/efi/early_printk.c.
> In early_efi_scroll_up(), 2 mapping entries will be used for the src/dst
> screen buffer.
> In drivers/acpi/acpica/tbutils.c, we've improved the early table loading code
> in acpi_tb_parse_ro
On 08/22/14 at 06:02pm, Dave Young wrote:
> On 08/21/14 at 09:52pm, Matt Fleming wrote:
> > On Tue, 19 Aug, at 04:16:58PM, Dave Young wrote:
> > > Hi,
> > >
> > > 3.16 kernel boot fail with earlyprintk=efi on my laptop.
> > > It keeps scrolling at the
On 08/25/14 at 06:34am, Zheng, Lv wrote:
> Hi,
>
> > From: Dave Young [mailto:dyo...@redhat.com]
> > Sent: Monday, August 25, 2014 2:07 PM
> > To: Matt Fleming
> > Cc: Zheng, Lv; Fleming, Matt; linux-efi@vger.kernel.org;
> > linux-a...@vger.kernel.o
urrent 4 slots setting of early_ioremap() seems to be too small for such a
use case.
"""
Thus increase the slot to 8 in this patch to fix this issue.
boot-time mappings become 512 page with this patch.
Signed-off-by: Dave Young
---
I'm not sure if this is ok in 32bit, review an
On 09/14/14 at 03:14pm, Matt Fleming wrote:
> On Tue, 26 Aug, at 05:06:41PM, Dave Young wrote:
> > 3.16 kernel boot fail with earlyprintk=efi, it keeps scrolling at the
> > bottom line of screen.
> >
> > Bisected, the first bad commit is below:
> > commit 86dfc6f
On 09/14/14 at 07:42pm, Greg KH wrote:
> On Mon, Sep 15, 2014 at 10:38:05AM +0800, Dave Young wrote:
> > On 09/14/14 at 03:14pm, Matt Fleming wrote:
> > > On Tue, 26 Aug, at 05:06:41PM, Dave Young wrote:
> > > > 3.16 kernel boot fail with earlyprintk=efi, it keeps s
Hi, Mark
On 09/22/14 at 12:33pm, Mark Salter wrote:
> On Thu, 2014-08-14 at 17:19 +0800, Dave Young wrote:
> > efi rtc depends on efi runtime services, so if efi runtime services are not
> > usable it should error out.
> >
> > Without this patch rtc-efi will panic wit
Hi, Ard
The approach looks good, thanks for the patchset.
Please see a few code comments inline..
On 10/24/14 at 02:39pm, Ard Biesheuvel wrote:
> In order to support kexec, the kernel needs to be able to deal with the
> state of the UEFI firmware after SetVirtualAddressMap() has been called.
> T
Hi, Ard
[snip]
> >> +static phys_addr_t __init efi_to_phys(unsigned long addr)
> >> +{
> >> + efi_memory_desc_t *md;
> >> +
> >> + for_each_efi_memory_desc(&memmap, md) {
> >> + if (!(md->attribute & EFI_MEMORY_RUNTIME))
> >> + continue;
> >> + i
On 11/18/14 at 01:57pm, Ard Biesheuvel wrote:
> Improve the handling of /dev/mem mappings under CONFIG_STRICT_DEVMEM by:
> - allowing read-only access to parts of System RAM that are not
> considered memory by the kernel, this is mainly intended for exposing
> UEFI Configuration tables to userl
On 11/26/14 at 05:23pm, Ard Biesheuvel wrote:
> On 26 November 2014 at 10:30, Dave Young wrote:
> > On 11/18/14 at 01:57pm, Ard Biesheuvel wrote:
> >> Improve the handling of /dev/mem mappings under CONFIG_STRICT_DEVMEM by:
> >> - allowing read-only access to parts
On 12/09/14 at 10:58am, Borislav Petkov wrote:
> Hi guys,
>
> so this decoded EFI regions output is nice but can we shorten it? It
> sticks too far out in the terminal more than anything else in dmesg and
> staring at it needs me to resize window and such. It probably is an even
> bigger problem i
On 12/22/14 at 07:08pm, Ard Biesheuvel wrote:
> This series was split off from the UEFI virtmap for kexec series that I posted
> earlier today. The main purpose is to deal with the need to classify memory
> ranges as RAM or non-RAM in a consistent and comprehensive manner. This series
> applies on
On 12/29/14 at 09:22am, Ard Biesheuvel wrote:
> On 26 December 2014 at 09:35, Dave Young wrote:
> > On 12/22/14 at 07:08pm, Ard Biesheuvel wrote:
> >> This series was split off from the UEFI virtmap for kexec series that I
> >> posted
> >> earlier today. The m
On 12/30/14 at 01:21pm, Ard Biesheuvel wrote:
> On 30 December 2014 at 09:25, Dave Young wrote:
> > On 12/29/14 at 09:22am, Ard Biesheuvel wrote:
> >> On 26 December 2014 at 09:35, Dave Young wrote:
> >> > On 12/22/14 at 07:08pm, Ard Biesheuvel wrote:
> >>
On 01/05/15 at 09:18am, Ard Biesheuvel wrote:
> On 4 January 2015 at 08:19, Dave Young wrote:
> > On 12/30/14 at 01:21pm, Ard Biesheuvel wrote:
> >> On 30 December 2014 at 09:25, Dave Young wrote:
> >> > On 12/29/14 at 09:22am, Ard Biesheuvel wrote:
> >>
On 01/07/15 at 11:41am, Ard Biesheuvel wrote:
> On 6 January 2015 at 08:16, Dave Young wrote:
> > On 01/05/15 at 09:18am, Ard Biesheuvel wrote:
> >> On 4 January 2015 at 08:19, Dave Young wrote:
> >> > On 12/30/14 at 01:21pm, Ard Biesheuvel wrote:
> >> >
Hi, Dan
On 01/15/15 at 12:21pm, Dan Carpenter wrote:
> The "> 0" here should ">= 0" so we free map_entries[0].
>
> Fixes: 926172d46038 ('efi: Export EFI runtime memory mapping to sysfs')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/firmware/efi/runtime-map.c
> b/drivers/firmware/efi
On 01/15/15 at 01:28pm, Dan Carpenter wrote:
> On Thu, Jan 15, 2015 at 05:54:55PM +0800, Dave Young wrote:
> > > out_add_entry:
> > > - for (j = i - 1; j > 0; j--) {
> > > + for (j = i - 1; j >= 0; j--) {
> > > entry = *(map_entries +
n 0;
> out_add_entry:
> - for (j = i - 1; j > 0; j--) {
> + for (j = i - 1; j >= 0; j--) {
> entry = *(map_entries + j);
> kobject_put(&entry->kobj);
> }
Acked-by: Dave Young
Thanks
Dave
--
To unsubscribe from this list: send
Hi,
Kdump has several limitations currently such as kdump kernel reboot will bypass
device shutdown path so device drivers should reset during initialization.
* One of such problem we encounter now is the iommu
issue, 1st kernel's on fly DMA requests cause 2nd kernel hang. There's some
effort
on
On 01/26/15 at 09:08am, Vivek Goyal wrote:
> On Sat, Jan 24, 2015 at 09:26:37PM +0800, Dave Young wrote:
> > Hi,
> >
> > Kdump has several limitations currently such as kdump kernel reboot will
> > bypass
> > device shutdown path so device drivers s
Hi, Matt
Thanks for the feedback.
On 01/26/15 at 04:39pm, Matt Fleming wrote:
> On Sat, 24 Jan, at 09:26:37PM, Dave Young wrote:
> >
> > There's several things I need to ask for help from EFI gurus to see if it
> > is doable:
> >
> > * Make sure in case
On 01/30/15 at 05:43pm, Borislav Petkov wrote:
> From: Borislav Petkov
> Date: Mon, 26 Jan 2015 19:49:59 +0100
> Subject: [PATCH] efi, x86: Add a "debug" option to the efi= cmdline
>
> ... and hide the memory regions dump behind it. Make it default-off.
>
> Signed-off-by: Borislav Petkov
> Link
Hi,
Thanks, it will be useful for possible efi rebooting to kdump reserved memory.
On 02/03/15 at 06:03pm, Yinghai Lu wrote:
> Now could use kexec to place kernel/boot_params/cmd_line/initrd
> above 4G, but that is with legacy interface with startup_64 directly.
>
> This patch will allow 64bit E
On 02/04/15 at 09:25pm, Yinghai Lu wrote:
> On Wed, Feb 4, 2015 at 7:25 PM, Dave Young wrote:
> >> After this patch, could use patched grub2-x86_64.efi to place
> >> kernel/boot_params/cmd_line/initrd all above 4G and execute the kernel
> >> above 4G.
> >
&
On 02/05/15 at 09:11am, Borislav Petkov wrote:
> On Thu, Feb 05, 2015 at 11:18:46AM +0800, Dave Young wrote:
> > > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > > index 0238d612750e..14cec75d7e74 100644
> > > --- a/include/linux/efi.h
> > > ++
x86/kernel/setup.c
> x86, efi: use early_ioremap in arch/x86/platform/efi/efi-bgrt.c
>
> arch/x86/kernel/devicetree.c | 4 ++--
> arch/x86/kernel/e820.c | 2 +-
> arch/x86/kernel/setup.c | 8
> arch/x86/platform/efi/efi-bgrt.c | 4 ++--
> 4 files
On 02/19/15 at 09:54am, Peter Jones wrote:
> Add sysfs files for the EFI System Resource Table (ESRT) under
> /sys/firmware/efi/esrt and for each EFI System Resource Entry under
> entries/ as a subdir.
>
> The EFI System Resource Table (ESRT) provides a read-only catalog of
> system components for
Matt/Ricardo, thanks for ccing me, and sorry for late response I thought
to reply but I was busy on other things..
On 07/01/15 at 10:37am, Ricardo Neri wrote:
> On Wed, 2015-07-01 at 14:19 +0100, Matt Fleming wrote:
> > Did you hit this by passing "efi=" on the kernel command line?
>
> I hit this
On 07/15/15 at 07:36pm, Ricardo Neri wrote:
> Even though it is documented how to specifiy efi parameters, it is
> possible to cause a kernel panic due to a derreference of a NULL pointer when
> parsing such parameters if "efi" alone is given:
>
> PANIC: early exception 0e rip 10:812fb361
Hi,
On 07/07/15 at 01:20pm, Yinghai Lu wrote:
> The copy will be in __initdata, and it is small.
>
> We can use pointer to access the setup_data instead of using early_memmap
> everywhere.
Looks good to me except one issue about missing checking memremap return value.
see the comment inline
>
[snip]
> > > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > > index cfba30f..d323e3a 100644
> > > --- a/arch/x86/platform/efi/efi.c
> > > +++ b/arch/x86/platform/efi/efi.c
> > > @@ -972,6 +972,10 @@ u64 efi_mem_attributes(unsigned long phys_addr)
> > >
> > > static
Hi,
>
> > As you pointed out above, a wild pointer could cause a
> > WARN from early_ioremap. We need to never follow the pointer in the
> > first place after a kexec, unless we have some way to know that it's
> > actually valid.
>
> So you assume that the information from ACPI is always corre
On 09/09/15 at 10:08am, Ard Biesheuvel wrote:
> Version 2.5 of the UEFI spec introduces a new configuration table
> called the 'EFI Properties table'. Currently, it is only used to
> convey whether the Memory Protection feature is enabled, which splits
> PE/COFF images into separate code and data m
On 09/24/15 at 02:06pm, Ard Biesheuvel wrote:
> On 23 September 2015 at 23:06, Dave Young wrote:
> > On 09/09/15 at 10:08am, Ard Biesheuvel wrote:
> >> Version 2.5 of the UEFI spec introduces a new configuration table
> >> called the 'EFI Properties table
On 09/27/15 at 12:40pm, Borislav Petkov wrote:
> On Sun, Sep 27, 2015 at 09:06:44AM +0200, Ingo Molnar wrote:
> > Could we please re-list all the arguments pro and contra of 1:1 physical
> > mappings,
> > in a post that also explains the background so that more people can chime
> > in, not
> >
On 09/30/15 at 04:43pm, Ard Biesheuvel wrote:
> As pointed out by Dave Young, /sys/firmware/efi/systab violates the
> sysfs one-value-per-file policy already, so adding more data items
> to it should be avoided. So let's remove the PROP= line that lists
> the address of the re
On 02/16/17 at 09:45am, Tom Lendacky wrote:
[snip]
> + * This function determines if an address should be mapped encrypted.
> + * Boot setup data, EFI data and E820 areas are checked in making this
> + * determination.
> + */
> +static bool memremap_should_map_encrypted(resource_size_t phys_addr,
>
On 02/16/17 at 09:47am, Tom Lendacky wrote:
> Use memremap() to map the setup data. This simplifies the code and will
> make the appropriate decision as to whether a RAM remapping can be done
> or if a fallback to ioremap_cache() is needed (which includes checking
> PageHighMem).
>
> Signed-off-b
50,13 +251,13 @@ static int __init get_setup_data_total_num(u64 pa_data,
> int *nr)
> *nr = 0;
> while (pa_data) {
> *nr += 1;
> - data = ioremap_cache(pa_data, sizeof(*data));
> + data = memremap(pa_data, sizeof(*data), MEMREMAP_
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
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 a/arch/x86
> IS_ENABLED(CONFIG_EFI)) &&
>vaddr_end >= __START_KERNEL_map);
> --
> 2.5.5
>
Acked-by: Dave Young
Thanks
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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: swapper
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:
> >
> > [
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, but the r
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, but the r
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
> >
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 ma
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()
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:
> >> >
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
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
> > >
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 problem.
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
turn -EPERM;
> +
> /* 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://lis
>* 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
--
To unsubscribe from this
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
&g
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 m
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
> >
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
> > >
1 - 100 of 432 matches
Mail list logo
