> > 1. Since we don't use "efi_rts_wq" for efi_reset_system(), the above
> > solution doesn't work if efi_reset_system() is buggy. We cannot
> > neglect it either because that's the issue faced by Al Stone and hence
> > I started the patch set. So, I am thinking to use long jump technique
> >
On Tue, Aug 7, 2018 at 11:01 AM, Prakhya, Sai Praneeth
wrote:
> Hi All,
>
>> > >> The main problem is that we have just merged Sai's code to use a
>> > >> work queue for invoking EFI services, and killing kworker threads
>> > >> is obviously not going to make EFI any new friends.
>> > >>
>> > >>
> > As discussed in previous mails, I have implemented the below:
> >
> > If kernel detects an illegal access by firmware to any efi region
> > other than efi boot time code/data, a. It freezes "efi_rts_wq" (efi
> > runtime services work queue).
> > b. Signals the requested process that an error
On 7 August 2018 at 20:01, Prakhya, Sai Praneeth
wrote:
> Hi All,
>
>> > >> The main problem is that we have just merged Sai's code to use a
>> > >> work queue for invoking EFI services, and killing kworker threads
>> > >> is obviously not going to make EFI any new friends.
>> > >>
>> > >> So I
Hi All,
> > >> The main problem is that we have just merged Sai's code to use a
> > >> work queue for invoking EFI services, and killing kworker threads
> > >> is obviously not going to make EFI any new friends.
> > >>
> > >> So I guess we should probably rework that code to use a dedicated
> >
> >> The main problem is that we have just merged Sai's code to use a work
> >> queue for invoking EFI services, and killing kworker threads is
> >> obviously not going to make EFI any new friends.
> >>
> >> So I guess we should probably rework that code to use a dedicated
> >> kthread, and just
On 26 July 2018 at 20:51, Prakhya, Sai Praneeth
wrote:
>> > The basic idea is that, when you get an exception from a context that
>> > is busted (i.e. it wasn't user code with a signal handler or kernel
>> > code with a fixup), you can't return from the exception handler. That
>> > leaves two
> > The basic idea is that, when you get an exception from a context that
> > is busted (i.e. it wasn't user code with a signal handler or kernel
> > code with a fixup), you can't return from the exception handler. That
> > leaves two choices:
> >
> > 1. Kill the task without returning. You
On 26 July 2018 at 20:09, Andy Lutomirski wrote:
> [sorry for totally busted formatting -- your email client and Gmail
> don't get along]
>
> On Jul 26, 2018, at 10:23 AM, Prakhya, Sai Praneeth
> wrote:
>
>> I have added some x86/intel folks to cc.
>>
>> I am fine with these patches, and I think
[sorry for totally busted formatting -- your email client and Gmail
don't get along]
On Jul 26, 2018, at 10:23 AM, Prakhya, Sai Praneeth
wrote:
> I have added some x86/intel folks to cc.
>
> I am fine with these patches, and I think it is useful to be able to
> detect and recover from buggy
I have added some x86/intel folks to cc.
I am fine with these patches, and I think it is useful to be able to
detect and recover from buggy UEFI implementations that use boot time
regions at runtime.
However, I need help from the x86 maintainers/developers to review
this so please cc them on
On Wed, Jul 25, 2018 at 2:39 AM, Ard Biesheuvel
wrote:
> (+ Ingo, Andy, Peter)
>
> Hello Sai,
>
> I have added some x86/intel folks to cc.
>
> I am fine with these patches, and I think it is useful to be able to
> detect and recover from buggy UEFI implementations that use boot time
> regions at
> > AFAIK, efi runtime services are not reentrant. With this in mind, if
> > something
> like above happens, I have completely turned off EFI runtime services in
> kernel.
> Is that OK? Or should we keep them enabled hoping to catch further illegal
> accesses (assuming that this feature is not
On 25 July 2018 at 19:32, Prakhya, Sai Praneeth
wrote:
>> I have added some x86/intel folks to cc.
>>
>> I am fine with these patches, and I think it is useful to be able to detect
>> and
>> recover from buggy UEFI implementations that use boot time regions at
>> runtime.
>>
>> However, I need
> I have added some x86/intel folks to cc.
>
> I am fine with these patches, and I think it is useful to be able to detect
> and
> recover from buggy UEFI implementations that use boot time regions at
> runtime.
>
> However, I need help from the x86 maintainers/developers to review this so
>
(+ Ingo, Andy, Peter)
Hello Sai,
I have added some x86/intel folks to cc.
I am fine with these patches, and I think it is useful to be able to
detect and recover from buggy UEFI implementations that use boot time
regions at runtime.
However, I need help from the x86 maintainers/developers to
From: Sai Praneeth
There may exist some buggy UEFI firmware implementations that access efi
memory regions other than EFI_RUNTIME_SERVICES_ even after
kernel has assumed control of the platform. This violates UEFI
specification. Here, we provide a debug config option which when enabled
detects
17 matches
Mail list logo
