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]
Date:   Wed, 23 Aug 2023 10:38:23 +0800
From:   "Huang, Ying" <ying.huang@...el.com>
To:     Uday Shankar <ushankar@...estorage.com>
Cc:     Jörn Engel <joern@...estorage.com>,
        Kees Cook <keescook@...omium.org>,
        Tony Luck <tony.luck@...el.com>,
        "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>, James Morse <james.morse@....com>,
        Borislav Petkov <bp@...en8.de>,
        Len Brown <len.brown@...el.com>,
        linux-hardening@...r.kernel.org, linux-acpi@...r.kernel.org,
        Qiuxu Zhuo <qiuxu.zhuo@...el.com>
Subject: Re: [PATCH] Revert "ACPI, APEI, use raw spinlock in ERST"

Uday Shankar <ushankar@...estorage.com> writes:

> On Mon, Aug 21, 2023 at 08:16:05PM -0700, Jörn Engel wrote:
>> On Tue, Aug 22, 2023 at 09:56:38AM +0800, Huang, Ying wrote:
>> > 
>> > ERST is mainly used to log the hardware error.  While, hardware error
>> > may be reported via NMI (e.g., ACPI APEI GHES NMI), so we need to call
>> > ERST functions in NMI handlers.  Where normal spinlock cannot be used
>> > because they will be converted to sleepable rt_mutex in RT kernel.
>> 
>> Non-sleeping spinlocks cannot be used in NMI context either.
>> raw_spin_lock_irqsave() will prevent regular interrupts, but not NMI.
>> So taking a spinlock inside an NMI can trigger a deadlock.
>> 
>> Am I missing something here?
>> 
>> Jörn
>> 
>> --
>> All art is but imitation of nature.
>> -- Lucius Annaeus Seneca
>
> Also want to point out that both before and after this commit, we only
> use trylock from erst_write, which looks like the only function touched
> by this patch which can be called from NMI context. Trylock should be
> safe in NMI context regardless of the type of synchronization used
> (raw_spinlock, spinlock, or otherwise).

Thanks for reminding!  That's a good point.

Checked the implementation of rt_mutex version of spin_trylock().  One
possible code path is,

spin_trylock()
  rt_spin_trylock()
    __rt_spin_trylock()
      rt_mutex_slowtrylock()
        raw_spin_lock_irqsave()

IIUC, the deadlock is still possible for rt_mutex.  While it seems that
the deadlock isn't possible for raw_spinlock.  If so, it's still better
to use raw_spinlock.

--
Best Regards,
Huang, Ying

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ