Hi,
since we have CONFIG_PREEMPT_RT these two patches allow to auto-disable
EFI runtime services on RT while it is still possible to override it and
use it if needed.
Sebastian
In case the option "efi=noruntime" is default at built-time, the user
could overwrite its state by `efi=runtime' and allow it again.
Acked-by: Ard Biesheuvel
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/firmware/efi/efi.c |3 +++
1 file changed, 3 insertions(+)
---
by PSCI.
Disable EFI's runtime wrappers.
This was observed on "EFI v2.60 by SoftIron Overdrive 1000".
Acked-by: Ard Biesheuvel
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/firmware/efi/efi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/firmware/efi/e
On 2018-12-04 09:23:13 [-0800], Kees Cook wrote:
> Okay, so, if kmsg_dump() uses rcu_read_lock(), that means efi-pstore
> can _never_ sleep, and it's nothing to do with pstore internals. :( I
> guess we just hard-code it, then? And efi-pstore should probably only
> attach to pstore if it has a
On 2018-11-30 14:47:36 [-0800], Kees Cook wrote:
> diff --git a/drivers/firmware/efi/efi-pstore.c
> b/drivers/firmware/efi/efi-pstore.c
> index cfe87b465819..0f7d97917197 100644
> --- a/drivers/firmware/efi/efi-pstore.c
> +++ b/drivers/firmware/efi/efi-pstore.c
> @@ -259,8 +259,7 @@ static int
On 2018-12-03 23:08:41 [+0100], Borislav Petkov wrote:
> On Mon, Dec 03, 2018 at 10:12:19PM +0100, Ard Biesheuvel wrote:
> > > + * Using the FPU in hardirq is not allowed.
> >
> > According to the documentation in x86/kernel/fpu/core.c, this is not
> > true. So which one is accurate?
>
> I think
Commit-ID: 12209993e98c5fa1855c467f22a24e3d5b8be205
Gitweb: https://git.kernel.org/tip/12209993e98c5fa1855c467f22a24e3d5b8be205
Author: Sebastian Andrzej Siewior
AuthorDate: Thu, 29 Nov 2018 16:02:10 +0100
Committer: Borislav Petkov
CommitDate: Tue, 4 Dec 2018 12:37:28 +0100
x86/fpu
Commit-ID: 7d79adb87fa79e4a4c59424fd5b5a922861fc5f6
Gitweb: https://git.kernel.org/tip/7d79adb87fa79e4a4c59424fd5b5a922861fc5f6
Author: Sebastian Andrzej Siewior
AuthorDate: Thu, 29 Nov 2018 16:02:10 +0100
Committer: Borislav Petkov
CommitDate: Mon, 3 Dec 2018 19:37:27 +0100
x86/fpu
On 2018-12-01 09:42:38 [+0100], Arnd Bergmann wrote:
> You are right that you can't take (or release) a mutex from interrupt
> context. However, I don't think converting a spinlock to a semaphore
> is going to help here either.
you can acquire a semaphore with a try_lock from interrupts context
On 2018-11-29 13:43:58 [-0800], Kees Cook wrote:
> On Mon, Nov 26, 2018 at 9:04 AM Sebastian Andrzej Siewior
> wrote:
> This bug got handled by Jann Horn, yes? (I remember seeing a related
> thread go by...)
Correct, fix sits in the tip tree. Nevertheless it was useful to spot
the
So I triggered a bug in x86 code. First the "okay" backtrace:
|BUG: GPF in non-whitelisted uaccess (non-canonical address?)
|general protection fault: [#1] PREEMPT SMP NOPTI
|CPU: 26 PID: 2236 Comm: sig-xstate-bum Not tainted 4.20.0-rc3 #45
|RIP: 0010:__fpu__restore_sig+0x1c1/0x540
|Call
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
sync).
The variable write could be used by pstore.
These functions can be disabled without much of a loss. The poweroff /
reboot hooks may be provided by PSCI.
Disable EFI's runtime wrappers.
This was observed on "EFI v2.60 by SoftIron Overdrive 1000".
Signed-off-by: Sebastian Andrz
Allow efi=runtime
In case the option "efi=noruntime" is default at built-time, the user
could overwrite its sate by `efi=runtime' and allow it again.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/firmware/efi/efi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/f
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.
EFI's RTC driver on RT.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/rtc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a2ba5db36145..248d72711650 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
information.
Remove task_lock() and also update the comment to reflect it.
Signed-off-by: Sebastian Andrzej Siewior
---
v1…v2:
- drop RFC
- don't remove assignment of ->active_mm (PeterZ)
- don't worry about concurrent invocations of the function, Ard
said that
On 2018-07-24 18:19:15 [+0200], Ard Biesheuvel wrote:
> > Regarding the workqueue in commit 3eb420e70d87 ("efi: Use a work queue
> > to invoke EFI Runtime Services"). The efi_call_virt_pointer() function
> > uses local_save_flags() while invoking the EFI function. Why does commit
> > message say
On 2018-07-24 17:32:14 [+0200], Ard Biesheuvel wrote:
> Please refer to what has been queued up in tip:efi/core. Sai has
> implemented a work queue for EFI calls so they occur from a kernel
> thread, and the mixed mode locking has been fixed as well.
I see commit 83a0a2ea0b99 ("efi/x86: Prevent
;
(efi_thunk_get_next_variable()) which does not take any locks (or I
missed them). Maybe it would be better to let the caller save
->active_mm while the MM is borrowed.
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/platform/efi/efi_64.c | 10 --
1 file changed, 4 insertions(+),
On 07/29/2015 06:41 PM, Josh Triplett wrote:
This is correct. However I miss the point of saving the image in the
first place. From what I see is that I have now 272 KiB in memory which
are never used again. Is there a usecase why we have it? From the code
it looks like we save it during boot
On 07/29/2015 02:10 AM, j...@joshtriplett.org wrote:
On Wed, 22 Jul, at 05:32:44PM, Sebastian Andrzej Siewior wrote:
now and then. The data behind that pointer changes on each boot because
nobody preserves the content across kexec.
Right. The kernel copies this image precisely because
22 matches
Mail list logo