lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2b7e98a3-dc77-4eb3-beba-3bea7febb715@siemens.com>
Date: Tue, 26 Aug 2025 09:23:07 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: Aaron Kling <webgeek1234@...il.com>, Ard Biesheuvel <ardb@...nel.org>
Cc: linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] efistub: Lower default log level

On 26.08.25 00:09, Aaron Kling wrote:
> On Mon, Aug 25, 2025 at 4:28 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>>
>> On Tue, 26 Aug 2025 at 02:34, Aaron Kling <webgeek1234@...il.com> wrote:
>>>
>>> On Mon, Aug 25, 2025 at 5:44 AM Ard Biesheuvel <ardb@...nel.org> wrote:
>>>>
>>>> On Sun, 24 Aug 2025 at 16:47, Jan Kiszka <jan.kiszka@...mens.com> wrote:
>>>>>
>>>>> On 24.08.25 02:31, Ard Biesheuvel wrote:
>>>>>> On Sat, 16 Aug 2025 at 16:52, Jan Kiszka <jan.kiszka@...mens.com> wrote:
>>>>>>>
>>>>>>> On 15.07.25 03:35, Ard Biesheuvel wrote:
>>>>>>>> On Tue, 8 Jul 2025 at 17:31, Aaron Kling <webgeek1234@...il.com> wrote:
>>>>>>>>>
>>>>>>>>> On Tue, Jul 8, 2025 at 2:30 AM Aaron Kling via B4 Relay
>>>>>>>>> <devnull+webgeek1234.gmail.com@...nel.org> wrote:
>>>>>>>>>>
>>>>>>>>>> From: Aaron Kling <webgeek1234@...il.com>
>>>>>>>>>>
>>>>>>>>>> Some uefi implementations will write the efistub logs to the display
>>>>>>>>>> over a splash image. This is not desirable for debug and info logs, so
>>>>>>>>>> lower the default efi log level to exclude them.
>>>>>>>>>>
>>>>>>>>>> Suggested-by: Ard Biesheuvel <ardb@...nel.org>
>>>>>>>>>> Signed-off-by: Aaron Kling <webgeek1234@...il.com>
>>>>>>>>>> ---
>>>>>>>>>>  drivers/firmware/efi/libstub/printk.c | 4 ++--
>>>>>>>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/firmware/efi/libstub/printk.c b/drivers/firmware/efi/libstub/printk.c
>>>>>>>>>> index 3a67a2cea7bdf1aa215d48dbf9ece4ceec6e4c28..bc599212c05dd746a9c54abbbe61a4bf70f1a8c4 100644
>>>>>>>>>> --- a/drivers/firmware/efi/libstub/printk.c
>>>>>>>>>> +++ b/drivers/firmware/efi/libstub/printk.c
>>>>>>>>>> @@ -5,13 +5,13 @@
>>>>>>>>>>  #include <linux/ctype.h>
>>>>>>>>>>  #include <linux/efi.h>
>>>>>>>>>>  #include <linux/kernel.h>
>>>>>>>>>> -#include <linux/printk.h> /* For CONSOLE_LOGLEVEL_* */
>>>>>>>>>> +#include <linux/kern_levels.h>
>>>>>>>>>>  #include <asm/efi.h>
>>>>>>>>>>  #include <asm/setup.h>
>>>>>>>>>>
>>>>>>>>>>  #include "efistub.h"
>>>>>>>>>>
>>>>>>>>>> -int efi_loglevel = CONSOLE_LOGLEVEL_DEFAULT;
>>>>>>>>>> +int efi_loglevel = LOGLEVEL_NOTICE;
>>>>>>>>>>
>>>>>>>>>>  /**
>>>>>>>>>>   * efi_char16_puts() - Write a UCS-2 encoded string to the console
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> base-commit: d7b8f8e20813f0179d8ef519541a3527e7661d3a
>>>>>>>>>> change-id: 20250708-efi-default-loglevel-4da5a36cac87
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> --
>>>>>>>>>> Aaron Kling <webgeek1234@...il.com>
>>>>>>>>>
>>>>>>>>> This patch was originally suggested a few months ago [0], but as far
>>>>>>>>> as I can tell was never queued for merge. Since I'm also hitting a
>>>>>>>>> case where this is relevant, I'm sending this in to bring attention
>>>>>>>>> back to it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I've queued this up now - thanks.
>>>>>>>>
>>>>>>>
>>>>>>> And how can I get back the loglevel info? It seems I can only choose
>>>>>>> between notice, silent and debug now. And the latter two only by also
>>>>>>> touching the kernel's loglevel.
>>>>>>>
>>>>>>> I'm particularly missing [1] in my UART logs now which is helpful in
>>>>>>> understanding this essential system state.
>>>>>>>
>>>>>>
>>>>>> Hi Jan,
>>>>>>
>>>>>> Is efi=debug too noisy for you?
>>>>>
>>>>> Yes, also because it affects the kernel even more. I'm looking for
>>>>> "efi=info".
>>>>>
>>>>> I don't get the reason behind this change anymore as well. If you have a
>>>>> splash screen shown, weren't you booting with "quiet" before already,
>>>>> thus also without any stub messages?
>>>>>
>>>>
>>>> Yeah, good point. IIRC that came up in the discussion but I can't
>>>> remember the motivation so it can't have been very convincing.
>>>>
>>>> So should we just revert this change?
>>>
>>> I'd prefer not to have to set quiet to get a clean splash screen. That
>>> doesn't seem like an unreasonable expectation, getting default
>>> non-debug logs and not having stuff written on top of the splash
>>> image.
>>
>> Perhaps you could remind us why this only applies to the efistub
>> output, and having the output of the kernel itself corrupting the
>> splash screen is fine?
> 
> I'm not greatly knowledgeable about the efi standard and what's
> happening under the hood, so I will just speak to what I saw in my use
> case. I'm working on Nvidia Tegra devices, newer generations of which
> use EDK2 as the last stage bootloader. The target os is Android, which
> has a pretty strictly controlled defconfig. Prior to this change, the
> kernel efistub logs were getting passed to the efi impl, which was
> then printing those lines to the display. The kernel logs were not
> being printed to the screen, as none of the console drivers were
> enabled to do so. So after this change, regardless of the kernel log
> level, the boot splash will remain untouched until the kernel display
> driver takes over the display and the os renders to it. Because no
> efistub log lines are being printed.
> 

That makes sense now, and surely don't mind having some build-time or
runtime configuration switch that allow to tune the system into such
settings. It's just not so nice to take away the freedom of full-scale
loglevel control from the efistub.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ