On 5 September 2018 at 19:53, Prakhya, Sai Praneeth
wrote:
>> On Wed, 5 Sep 2018, Ard Biesheuvel wrote:
>> > On 5 September 2018 at 14:56, Peter Zijlstra wrote:
>> > > On Wed, Sep 05, 2018 at 02:27:49PM +0200, Ard Biesheuvel wrote:
>> > >> Would we still need to preserve the old memory map in
On Wed, 5 Sep 2018 20:07:50 +0100
Grant Likely wrote:
> The dtb= parameter is no longer the primary mechanism for providing a
> devicetree to the kernel. Now either firmware or the boot selector (ex.
> Grub) should provide the devicetree and dtb= should only be used for
> debug or when using
> >> I agree. Keep it simple. If the EFI crap fails, then assist with the
> >> reboot and otherwise just kill it.
> >
> > The reasons for saving old memory map are (in my view, these are the
> > less important ones because they are very unlikely to happen)
> >
> > 1. Make sure that a memory
> On 6 Sep 2018, at 16:51, Jonathan Corbet wrote:
>
> On Wed, 5 Sep 2018 20:07:50 +0100
> Grant Likely wrote:
>
>> The dtb= parameter is no longer the primary mechanism for providing a
>> devicetree to the kernel. Now either firmware or the boot selector (ex.
>> Grub) should provide the
The dtb= parameter is no longer the primary mechanism for providing a
devicetree to the kernel. Now either firmware or the boot selector (ex.
Grub) should provide the devicetree and dtb= should only be used for
debug or when using firmware that doesn't understand DT.
Update the EFI stub
From: Sai Praneeth
There may exist some buggy UEFI firmware implementations that might
access efi regions other than EFI_RUNTIME_SERVICES_ even
after the kernel has assumed control of the platform. This violates UEFI
specification.
If selected, this debug option will print a warning message if
From: Sai Praneeth
As per the UEFI specification, after the call to ExitBootServices(),
accesses by the firmware to any memory regions except
EFI_RUNTIME_SERVICES_ regions is considered illegal. A buggy
firmware could trigger these illegal accesses when an efi runtime
service is invoked and if
From: Sai Praneeth
There may exist some buggy UEFI firmware implementations that access efi
memory regions other than EFI_RUNTIME_SERVICES_ even after
the kernel has assumed control of the platform. This violates UEFI
specification. Hence, provide a debug config option which when enabled
From: Sai Praneeth
After the kernel has booted, if any accesses by firmware causes a page
fault, the efi page fault handler would freeze efi_rts_wq and schedules
a new process. To do this, the efi page fault handler needs
efi_rts_work. Hence, make it accessible.
There will be no race conditions
