Efiruntime strsize function patch
by Gaddam, Pradeep R
Hi,
Currently strsize function in efiruntime driver only deals with kernel space pointers.
The same function when invoked in the driver with a userland pointer is causing issues.
This patch fixes that by changing the function to deal with user space and kernel space pointers selectively .
Thanks
Pradeep
8 years, 1 month
[PATCH v3 0/6] Warn about illegal accesses to BOOT_SERVICES_* memory
by Ricardo Neri
Hi,
This is the version 3 of this series. This comprises only the kernel changes.
Changes to the LuvOS test manager will be sent shortly after this submission.
This is the rationale behind these patches: The UEFI firmware passes a map of
the system memory to the OS. Some of that memory, in the BOOT_SERVICES_CODE/DATA
regions is used by the firmware during boot but should be able for the OS to use
once the bootup is complete and the OS calls ExitBootServices on the firmware.
However, some buggy implementations of UEFI firmware still want to access those
regions of memory. This will corrupt the kernel memory. Currently, the kernel
works around the issue by reserving and mapping such memory so that the firmware
can access it without issue.
This patch series will no longer map the BOOT_SERVICES_CODE/DATA memory regions
and, instead, will fixup any page fault that happens by not mapping such memory
if/when the firmware tries to access it. We are guaranteed to not have false
positives (i.e., page faults caused by bad kernel code) as these memory regions
are still reserved.
Besides fixing up the illegal accesses, no further action is required to update
the memory map the firmware sees. This is true because after boot, the firmware
would require access to the runtime services memory only, which should be mapped
before calling SetVirtualAddressMap. Furthermore, a second attempt to update the
virtual address map will result in a EFI_UNSUPPORTED from the firmware, as per
the UEFI specification.
Also, there is no need to update the system table as it should have been when
mapping the rest of the memory regions.
Finally, kexec is concerned only about the runtime services memory sections. Thus
we don't need any special arrangements for kexec.
I have tested these patches by introducing an illegal access to a
BOOT_SERVICES_CODE memory region in OVMF running on qemu. The fault was detected
and fixed up correctly.
The first two patches of the series rework convenience functions that look for
the descriptor of a physical memory address. Rather than having the scan code in
the three functions, only one scan is done for the other functions to operate on
the memory descriptor. This is subsequently used when fixing up illegal memory
accesses.
These patches are based on Matt's
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git stable
I decided to send these patches to the LuvOS mailing list as I thought they
would have a wider audience as compared to Github.
Changes since v2:
1) Added more details describing the feature of issue warnings when access
to the BOOT_SERVICES_* memory regions are accessed.
2) Print only one warning when the illegal accesses are issued and make the
implementation more cosmetic.
Changes since v1:
1) Rework convenience function to reuse code to scan the memory map
2) Declaration of efi_boot_services_fixup is qualified as extern to match the
rest of the functions
3) Make the fixup code depend on CONFIG_EFI
4) Add inline stub for efi_boot_services_fixup when CONFIG_EFI is not selected
Ricardo Neri (6):
x86/efi: Add function to obtain mem descriptor from phys address
x86/efi: Use efi_memory_descriptor in mem convenience functions
x86/efi: Add fuction to fixup page faults in BOOT_SERVICES_* regions
x86/efi: remove __init attribute from memory mapping functions
x86, efi: fixup faults from UEFI firmware
x86/efi: Introduce EFI_BOOT_SERVICES_WARN
arch/x86/Kconfig | 12 ++++++++
arch/x86/include/asm/efi.h | 4 +--
arch/x86/mm/fault.c | 8 ++++++
arch/x86/platform/efi/efi.c | 65 +++++++++++++++++++++++++++++++++---------
arch/x86/platform/efi/efi_32.c | 2 +-
arch/x86/platform/efi/efi_64.c | 8 +++---
drivers/firmware/efi/efi.c | 36 ++++++++++-------------
include/linux/efi.h | 9 ++++++
8 files changed, 102 insertions(+), 42 deletions(-)
--
1.9.1
8 years, 1 month
luv v1.0-rc4 release
by Matt Fleming
It's that time again, another release candidate is out. You can find it
in the usual place,
https://01.org/linux-uefi-validation/downloads
The following changes were merged this cycle.
1. OVMF recipe changes from Max Eliaser
https://github.com/01org/luv-yocto/pull/15
- Blank screen when using runqemu with the OVMF firmware (albiet in a
somewhat hacky way)
- OVMF recipe not warning the user if compiled for unsupported
architectures like MIPS
- OVMF recipe never creating 32-bit firmware, even when it should
- Also upgrade OVMF to a newer upstream version, which fixes an
upstream bug that caused build failures with GCC 4.9,
2. fwts kernel driver fixes from Pradeep Gaddam
https://lists.01.org/pipermail/luv/2014-August/000078.html
The efi_runtime kernel module makes illegal accesses to userland
addresses because it jumps through multiple levels of pointer
indirection, resulting in failed test cases.
With this patch the uefirttime tests now pass on Qemu.
3. Kernel EFI boot services warning patches from Ricardo Neri
https://lists.01.org/pipermail/luv/2014-August/000084.html
This release is special because it's the first time that we're carrying
kernel patches that are not upstream. The following commits from Ricardo
were merged for v1.0-rc4,
aa1a04b3f488 x86/efi: Add function to obtain mem descriptor from phys address
2c8afd15d444 x86/efi: Use efi_memory_descriptor in mem convenience functions
36b64c716f13 x86/efi: Add function to fixup page faults in BOOT_SERVICES_* regions
6cb0c8ed6905 x86/efi: Remove __init attribute from memory mapping functions
a988a7a5abd1 x86/efi: Fixup faults from UEFI firmware
2bdf42e7ee58 x86/efi: Introduce EFI_BOOT_SERVICES_WARN
and can be found in the 'stable' branch at,
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
This set of patches put infrastructure in place to warn when EFI
firmware makes illegal accesses to EFI boot services regions, which
happens with some buggy implementations when calling
SetVirtualAddressMap().
The git shortlog looks like this,
Matt Fleming (2):
linux-yocto-efi-test: Update defconfig for v3.15
linux-yocto-efi-test: Enable CONFIG_EFI_BOOT_SERVICES_WARN
Max Eliaser (4):
runqemu: don't use qemu -vga vmware when using OVMF BIOS
meta-luv: ovmf: only permit x86 and x86_64 target architectures for OVMF
meta-luv: ovmf: generate 32-bit firmware images when appropriate
meta-luv: ovmf: bump SVN revision for OVMF to 15699
Pradeep Gaddam (1):
fwts: Copied the structure from userland locally in kernel space
--
Matt Fleming, Intel Open Source Technology Center
8 years, 1 month
Efi Runtime Patch
by Gaddam, Pradeep R
Hello,
Please find the attached patch that has the fix for PageFaults coming out of uefirttime tests.
Thanks
Pradeep
8 years, 1 month
[PATCH v2 0/6] Warn about illegal accesses to BOOT_SERVICES_* memory
by Ricardo Neri
Hi,
Finally, after months of reading code I could finally put together a set of
patches to fixup page faults caused by access to (unmapped) BOOT_SERVICES_*.
I went ahead and submitted the kernel patches only as they are the more crucial.
The LuvOS parser test reporter is more trivial.
This is the rationale behind these patches: The UEFI firmware passes a map of
the system memory to the OS. Some of that memory, in the BOOT_SERVICES_CODE/DATA
regions is used by the firmware during boot but should be able for the OS to use
once the bootup is complete and the OS calls ExitBootServices on the firmware.
However, some buggy implementations of UEFI firmware still want to access those
regions of memory. This will corrupt the kernel memory. Currently, the kernel
works around the issue by reserving and mapping such memory so that the firmware
can access it without issue.
This patch series will no longer map the BOOT_SERVICES_CODE/DATA memory regions
and, instead, will fixup any page fault that happens by not mapping such memory
if/when the firmware tries to access it. We are guaranteed to not have false
positives (i.e., page faults caused by bad kernel code) as these memory regions
are still reserved.
Besides fixing up the illegal accesses, no further action is required to update
the memory map the firmware sees. This is true because after boot, the firmware
would require access to the runtime services memory only, which should be mapped
before calling SetVirtualAddressMap. Furthermore, a second attempt to update the
virtual address map will result in a EFI_UNSUPPORTED from the firmware, as per
the UEFI specification.
Also, there is no need to update the system table as it should have been when
mapping the rest of the memory regions.
Finally, kexec is concerned only about the runtime services memory sections. Thus
we don't need any special arrangements for kexec.
I have tested these patches by introducing an illegal access to a
BOOT_SERVICES_CODE memory region in OVMF running on qemu. The fault was detected
and fixed up correctly.
The first two patches of the series rework convenience functions that look for
the descriptor of a physical memory address. Rather than having the scan code in
the three functions, only one scan is done for the other functions to operate on
the memory descriptor. This is subsequently used when fixing up illegal memory
accesses.
These patches are based on Matt's
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git stable
I decided to send these patches to the LuvOS mailing list as I thought they
would have a wider audience as compared to Github.
Changes since v1:
1) Rework convenience function to reuse code to scan the memory map
2) Declaration of efi_boot_services_fixup is qualified as extern to match the
rest of the functions
3) Make the fixup code depend on CONFIG_EFI
4) Add inline stub for efi_boot_services_fixup when CONFIG_EFI is not selected
Thanks and BR,
Ricardo
Ricardo Neri (6):
x86/efi: Add function to obtain mem descriptor from phys address
x86/efi: Use efi_memory_descriptor in mem convenience functions
x86/efi: Add fuction to fixup page faults in BOOT_SERVICES_* regions
x86/efi: remove __init attribute from memory mapping functions
x86, efi: fixup faults from UEFI firmware
x86/efi: Introduce EFI_BOOT_SERVICES_WARN
arch/x86/Kconfig | 12 ++++++++
arch/x86/include/asm/efi.h | 4 +--
arch/x86/mm/fault.c | 8 ++++++
arch/x86/platform/efi/efi.c | 63 ++++++++++++++++++++++++++++++++----------
arch/x86/platform/efi/efi_32.c | 2 +-
arch/x86/platform/efi/efi_64.c | 8 +++---
drivers/firmware/efi/efi.c | 36 ++++++++++--------------
include/linux/efi.h | 9 ++++++
8 files changed, 100 insertions(+), 42 deletions(-)
--
1.9.1
8 years, 1 month
[PATCH 0/4] Warn about illegal accesses to BOOT_SERVICES_* memory
by Ricardo Neri
Hi,
Finally, after months of reading code I could finally put together a set of
patches to fixup page faults caused by access to (unmapped) BOOT_SERVICES_*.
I went ahead and submitted the kernel patches only as they are the more crucial.
The LuvOS parser test reporter is more trivial.
This is the rationale behind these patches: The UEFI firmware passes a map of
the system memory to the OS. Some of that memory, in the BOOT_SERVICES_CODE/DATA
regions is used by the firmware during boot but should be able for the OS to use
once the bootup is complete and the OS calls ExitBootServices on the firmware.
However, some buggy implementations of UEFI firmware still want to access those
regions of memory. This will corrupt the kernel memory. Currently, the kernel
works around the issue by reserving and mapping such memory so that the firmware
can access it without issue.
This patch series will no longer map the BOOT_SERVICES_CODE/DATA memory regions
and, instead, will fixup any page fault that happens by not mapping such memory
if/when the firmware tries to access it. We are guaranteed to not have false
positives (i.e., page faults caused by bad kernel code) as these memory regions
are still reserved.
Besides fixing up the illegal accesses, no further action is required to update
the memory map the firmware sees. This is true because after boot, the firmware
would require access to the runtime services memory only, which should be mapped
before calling SetVirtualAddressMap. Furthermore, a second attempt to update the
virtual address map will result in a EFI_UNSUPPORTED from the firmware, as per
the UEFI specification.
Also, there is no need to update the system table as it should have been when
mapping the rest of the memory regions.
Finally, kexec is concerned only about the runtime services memory sections. Thus
we don't need any special arrangements for kexec.
I have tested these patches by introducing an illegal access to a
BOOT_SERVICES_CODE memory region in OVMF running on qemu. The fault was detected
and fixed up correctly.
These patches are based on Matt's
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git stable
I decided to send these patches to the LuvOS mailing list as I thought they
would have a wider audience as compared to Github.
Thanks and BR,
Ricardo
Ricardo Neri (4):
x86/efi: Add fuction to fixup page faults in BOOT_SERVICES_* regions
x86/efi: remove __init attribute from memory mapping functions
x86, efi: fixup faults from UEFI firmware
x86/efi: Introduce EFI_BOOT_SERVICES_WARN
arch/x86/Kconfig | 12 +++++++++++
arch/x86/include/asm/efi.h | 4 ++--
arch/x86/mm/fault.c | 8 +++++++
arch/x86/platform/efi/efi.c | 48 ++++++++++++++++++++++++++++++++++++++++--
arch/x86/platform/efi/efi_32.c | 2 +-
arch/x86/platform/efi/efi_64.c | 8 +++----
include/linux/efi.h | 1 +
7 files changed, 74 insertions(+), 9 deletions(-)
--
1.9.1
8 years, 1 month
