linux-kernel - Re: [BUG]: KVM: arm64: Fix symbol dependency in __hyp_call_panic

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: <87pn1ska6c.wl-maz@kernel.org>
Date:   Mon, 25 Jan 2021 20:56:27 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Oliver Upton <oupton@...gle.com>, Sasha Levin <sashal@...nel.org>
Cc:     dbrazdil@...gle.com, hns@...delico.com,
        linux-kernel@...r.kernel.org
Subject: Re: [BUG]: KVM: arm64: Fix symbol dependency in __hyp_call_panic_nvhe

Hi all,

On Mon, 25 Jan 2021 20:07:56 +0000,
Oliver Upton <oupton@...gle.com> wrote:
> 
> > That means we have two options:
> > (a) define __hyp_panic_string in a different .c file in all pre-5.9 branches, or
> > (b) revert the backported patch.
> > 
> > The patch was needed in 5.9 and should stay there. It wasn't needed in earlier
> > versions because the symbol was being kept alive by another user. It did "fix"
> > the inline asm semantics, but the problem was never triggered in pre-5.9.
> > 
> > Sasha, with this and the GCC bug in mind, would you agree that (b) is the
> > better course of action?
> 
> Sasha,
> 
> Any chance we can get this patch reverted as David has suggested? It
> was backported to 5.4 LTS in commit 653ae33b030b ("KVM: arm64: Fix
> symbol dependency in __hyp_call_panic_nvhe") and is causing build
> issues with a 4.9.4 vintage of GCC.

Absolutely. This issue has been lingering for some time now, and needs
addressing.

I'm definitely in favour of reverting this patch, although there are
two possible alternatives:

- Cherry-pick 9fd339a45be5 ("arm64: Work around broken GCC 4.9
  handling of "S" constraint"), which works around this particular GCC
  bug

- Cherry-pick dca5244d2f5b ("compiler.h: Raise minimum version of GCC
  to 5.1 for arm64"), which forbids GCC 4.9 as it has been
  demonstrated to mis-compile the kernel (and this patch is targeting
  stable anyway)

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.