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: <FFF73D592F13FD46B8700F0A279B802F3B818BE7@ORSMSX114.amr.corp.intel.com>
Date:   Tue, 5 Jun 2018 20:15:20 +0000
From:   "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@...el.com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
CC:     linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Lee Chun-Yi <jlee@...e.com>, Borislav Petkov <bp@...en8.de>,
        "Luck, Tony" <tony.luck@...el.com>,
        Will Deacon <will.deacon@....com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Mark Rutland <mark.rutland@....com>,
        Bhupesh Sharma <bhsharma@...hat.com>,
        Naresh Bhat <naresh.bhat@...aro.org>,
        "Neri, Ricardo" <ricardo.neri@...el.com>,
        "Peter Zijlstra" <peterz@...radead.org>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Subject: RE: [PATCH V5 3/3] efi: Use efi_rts_wq to invoke EFI Runtime
 Services

> >> I noticed that -unsurprisingly- reboot no longer works with these changes.
> >>
> >> I will fix up the patch, and revert the efi_reset_system() change,
> >> both here and below.
> >
> > Could you please let me know what the bug is here? I am unable to see
> > it right away :( I have tested reboot on qemu x86_64 by passing
> > "reboot=efi" as command line arg and saw that reboot is working fine.
> >
> 
> My arm64 hangs at reboot or power off, unless i revert the ResetSystem() part.
>

That's interesting. Not sure how the behavior could be different between x86 and arm64.
Maybe worth debugging further?
As you said, reverting ResetSystem() part makes things work, we cannot suspect a 
buggy efi_reset_system() (I came across buggy efi_reset_system() implementations 
on some x86 systems).

> But given that it is both risky (relying on a kthread running a workqueue in the
> shutdown path) and unnecessary (ResetSystem() is not supposed to return, and is
> only called by the kernel when the whole system has already been torn down), I
> think the main reason is simply that there is no reason to add it.

Makes sense.
I think, before calling firmware ResetSystem() kernel has already shut down all other parts 
and hence as the control will not transfer back to kernel (other than ResetSystem() failure), 
we could safely assume that no kernel code would access user space while in 
efi_reset_system() and hence we don't need to take the work queue path.

Regards,
Sai

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ