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: <CAKv+Gu84h2+zofb4v-QrVE7rqCrGC7MaHEw7tB+z2J8DczjoKw@mail.gmail.com>
Date:   Sat, 24 Mar 2018 22:35:54 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Paul Menzel <pmenzel+linux-efi@...gen.mpg.de>
Cc:     linux-efi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: efisubsys_init takes more than a few milliseconds

Hello Paul,

On 24 March 2018 at 22:10, Paul Menzel <pmenzel+linux-efi@...gen.mpg.de> wrote:
> Dear Ard,
>
>
> According to `initcall_debug`, `efisubsys_init` takes more than a few
> milliseconds to execute on a Dell XPS 13 9370 (Intel(R) Core(TM) i7-8550U
> CPU @ 1.80GHz).
>
>> ```
>> […]
>> [ 0.144474] calling  efisubsys_init+0x0/0x2cf @ 1
>> [ 0.144474] Registered efivars operations
>> [ 0.173690] initcall efisubsys_init+0x0/0x2cf returned 0 after 27343 usecs
>> […]
>> ```
>
>
> To get a vanilla Linux kernel to boot in well under one second, it’d be nice
> if the time could be improved. Do you know, why it takes so long?
>
> According to `bootgraph.py` from pm-graph [1][2] it takes even a little
> longer.
>
>> efisubsys_init: start=690.841, end=720.493, length(w/o overhead)=31.250
>> ms, return=0
>
>
> There are several dozen calls to `virt_efi_get_next_variable()` all but one
> taking around 0.335 ms. This path needs to be optimized. Is that possible?
>

That depends. These are firmware calls, so to make these calls faster,
you need to modify the firmware, not the kernel.

We may be able to make more intrusive changes to get rid of this
delay, e.g., spin up a special kernel thread, but I'd have to check in
more detail. In the mean time, you can try passing 'efi=noruntime' to
the kernel.


> To reproduce this, clone the pm-graph repository [2], use `sudo
> ./bootgraph.py -f -fstat -maxdepth 10 -manual` to see what to add to
> `/boot/grub/grub.cfg`. Then reboot, and execute `sudo ./bootgraph.py -f
> -fstat -maxdepth 10`.
>
> If your system is powerful enough, you can use a higher maximum depth. I
> didn’t get around how `-cgfilter` works to get smaller HTML files.
>
>
> Kind regards,
>
> Paul
>
>
> [1] https://01.org/suspendresume
> [2] https://github.com/01org/pm-graph

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ