linux-kernel - Re: [PATCH AUTOSEL 4.14 02/15] s390/hibernate: fix error handling when suspend cpu != resume cpu

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:   Fri, 26 Oct 2018 10:22:14 +0100
From:   Greg KH <greg@...ah.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Sasha Levin <sashal@...nel.org>, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Gerald Schaefer <gerald.schaefer@...ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [PATCH AUTOSEL 4.14 02/15] s390/hibernate: fix error handling
 when suspend cpu != resume cpu

On Fri, Oct 26, 2018 at 11:05:43AM +0200, Pavel Machek wrote:
> On Mon 2018-10-22 06:20:13, Sasha Levin wrote:
> > From: Gerald Schaefer <gerald.schaefer@...ibm.com>
> > 
> > [ Upstream commit 55a5542a546238354d1f209f794414168cf8c71d ]
> > 
> > The resume code checks if the resume cpu is the same as the suspend cpu.
> > If not, and if it is also not possible to switch to the suspend cpu, an
> > error message should be printed and the resume process should be stopped
> > by loading a disabled wait psw.
> > 
> > The current logic is broken in multiple ways, the message is never printed,
> > and the disabled wait psw never loaded because the kernel panics before that:
> > - sam31 and SIGP_SET_ARCHITECTURE to ESA mode is wrong, this will break
> >   on the first 64bit instruction in sclp_early_printk().
> > - The init stack should be used, but the stack pointer is not set up correctly
> >   (missing aghi %r15,-STACK_FRAME_OVERHEAD).
> > - __sclp_early_printk() checks the sclp_init_state. If it is not
> >   sclp_init_state_uninitialized, it simply returns w/o printing anything.
> >   In the resumed kernel however, sclp_init_state will never be uninitialized.
> 
> Stable patches should fix one bug, and one bug only.

So should upstream patches, but the rule of "stable patches match
upstream identically" overrules this :)