> >> 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
On 2018-07-26 18:01:47 [+0200], Ard Biesheuvel wrote:
> Yes, that's what I was thinking. This way, you can still reboot into
> the same kernel occasionally with EFI runtime services enabled to,
> e.g., use efibootmgr.
>
> Acked-by: Ard Biesheuvel
>
> for both patches if you queue them in the
On 26 July 2018 at 15:14, Sebastian Andrzej Siewior
wrote:
> On 2018-07-26 15:13:23 [+0200], To Ard Biesheuvel wrote:
>> On 2018-07-26 14:52:21 [+0200], Ard Biesheuvel wrote:
>> > We could also make it the default on -rt, but not disable it entirely, so
>> > that efi=runtime can be used to
> > 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 2018-07-26 15:13:23 [+0200], To Ard Biesheuvel wrote:
> On 2018-07-26 14:52:21 [+0200], Ard Biesheuvel wrote:
> > We could also make it the default on -rt, but not disable it entirely, so
> > that efi=runtime can be used to re-enable it.
>
> Oh. I like that. We have something similar for RCU.
On 2018-07-26 14:52:21 [+0200], Ard Biesheuvel wrote:
> We could also make it the default on -rt, but not disable it entirely, so
> that efi=runtime can be used to re-enable it.
Oh. I like that. We have something similar for RCU. So I would need
that:
--- >8
Subject: [PATCH] efi: Allow
> On 26 Jul 2018, at 14:46, Sebastian Andrzej Siewior
> wrote:
>
>> On 2018-07-26 14:26:25 [+0200], Ard Biesheuvel wrote:
>> What i mean is whatever you end up with if you pass efi=noruntime to the
>> kernel.
> ah. So I wouldn't have to patch this, just document it. That might work.
>
We
> On 26 Jul 2018, at 14:15, Sebastian Andrzej Siewior
> wrote:
>
>> On 2018-07-26 11:15:52 [+0200], Ard Biesheuvel wrote:
>> On 26 July 2018 at 11:04, Sebastian Andrzej Siewior
>> wrote:
>>> Based on measurements the EFI functions get_variable /
>>> get_next_variable take up to 2us. The
On 2018-07-26 11:15:52 [+0200], Ard Biesheuvel wrote:
> On 26 July 2018 at 11:04, Sebastian Andrzej Siewior
> wrote:
> > Based on measurements the EFI functions get_variable /
> > get_next_variable take up to 2us. The functions get_time, set_time take
> > around 10ms. Those 10ms are too much.
On 26 July 2018 at 11:04, Sebastian Andrzej Siewior
wrote:
> Based on measurements the EFI functions get_variable /
> get_next_variable take up to 2us. The functions get_time, set_time take
> around 10ms. Those 10ms are too much. Even one ms would be too much.
You cannot extrapolate from these
Based on measurements the EFI functions get_variable /
get_next_variable take up to 2us. The functions get_time, set_time take
around 10ms. Those 10ms are too much. Even one ms would be too much.
The funny part is that EFI is invoked with enabled interrupts.
According to my tracing I see the
Dmitry Safonov wrote:
> So, here I add a compatible layer to xfrm.
> As xfrm uses netlink notifications, kernel should send them in ABI
> format that an application will parse. The proposed solution is
> to save the ABI of bind() syscall. The realization detail is
> to create kernel-hidden, non
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
19 matches
Mail list logo
