linux-kernel - Re: [PATCH 2/4] serial: core: fix broken sysrq port unlock

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] [day] [month] [year] [list]

Message-ID: <20200603091338.GK19480@localhost>
Date:   Wed, 3 Jun 2020 11:13:38 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Dmitry Safonov <0x7f454c46@...il.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>
Subject: Re: [PATCH 2/4] serial: core: fix broken sysrq port unlock

On Wed, Jun 03, 2020 at 10:40:51AM +0200, Johan Hovold wrote:
> On Tue, Jun 02, 2020 at 04:34:16PM +0100, Dmitry Safonov wrote:
> > On 6/2/20 3:48 PM, Andy Shevchenko wrote:
> > > On Tue, Jun 2, 2020 at 5:03 PM Johan Hovold <johan@...nel.org> wrote:
> > >>
> > >> Commit d6e1935819db ("serial: core: Allow processing sysrq at port
> > >> unlock time") worked around a circular locking dependency by adding
> > >> helpers used to defer sysrq processing to when the port lock was
> > >> released.
> > >>
> > >> A later commit unfortunately converted these inline helpers to exported
> > >> functions despite the fact that the unlock helper was restoring irq
> > >> flags, something which needs to be done in the same function that saved
> > >> them (e.g. on SPARC).
> > > 
> > > I'm not familiar with sparc, can you elaborate a bit what is ABI /
> > > architecture lock implementation background?
> > 
> > I remember that was a limitation a while ago to save/restore flags from
> > the same function. Though, I vaguely remember the reason.
> > I don't see this limitation in Documentation/*
> 
> It's described in both LDD3 and LKD, which is possibly where I first
> picked it up too (admittedly a long time ago).
> 
> > Google suggests that it's related to storage location:
> > https://stackoverflow.com/a/34279032
> 
> No, that was never the issue.
> 
> SPARC includes the current register window in those flags, which at
> least had to be restored in the same stack frame.
> 
> > Looking into arch/sparc I also can't catch if it's still a limitation.
> 
> Yeah, looking closer at the current implementation it seems this is no
> longer an issue on SPARC.
> 
> > Also, looking around, xa_unlock_irqrestore() is called not from the same
> > function. Maybe this issue is in history?
> 
> xa_unlock_irqrestore() is just a macro for spin_unlock_irqsave() it
> seems, so not a counter example.
>
> > Also, some comments would be nice near functions in the header.
> 
> Agreed. Let me respin this and either merge this with the next patch or
> at least amend the commit message.

I stand corrected; this appears to longer be an issue (on any arch)
as we these days have other common code passing the flags argument
around like this.

I'll respin.

Johan