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: <YGbvXFrMg6X7q3qL@gerhold.net>
Date:   Fri, 2 Apr 2021 12:18:04 +0200
From:   Stephan Gerhold <stephan@...hold.net>
To:     Stephen Boyd <swboyd@...omium.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Elliot Berman <eberman@...eaurora.org>,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        Brian Masney <masneyb@...tation.org>,
        Jeffrey Hugo <jhugo@...eaurora.org>,
        Douglas Anderson <dianders@...omium.org>
Subject: Re: [PATCH v2] firmware: qcom_scm: Only compile legacy calls on ARM

On Thu, Apr 01, 2021 at 11:58:48PM -0700, Stephen Boyd wrote:
> Quoting Elliot Berman (2021-04-01 18:12:14)
> > 
> > It might be a good idea to wrap these lines from qcom_scm_call with #if 
> > IS_ENABLED(CONFIG_ARM), and the corresponding ones in qcom_scm_call_atomic:
> > 
> >    case SMC_CONVENTION_LEGACY:
> >        return scm_legacy_call(dev, desc, res);
> > 
> > If something is wrong with loaded firmware and LEGACY convention is 
> > incorrectly selected, you would get a better hint about the problem: 
> > "Unknown current SCM calling convention." You would still get the hint 
> > earlier from __get_convention, but that may not be obvious to someone 
> > unfamiliar with the SCM driver.
> > 
> > I'll defer to your/Bjorn's preference:
> > 
> > Acked-by: Elliot Berman <eberman@...eaurora.org>
> > 
> > with or without modifying qcom_scm_call{_atomic}.
> > 
> 
> Maybe it would be better to catch that problem at the source and force
> arm64 calling convention to be safe? I'm thinking of this patch, but it
> could be even more fine tuned and probably the sc7180 check could be
> removed in the process if the rest of this email makes sense.
> 
> If I understand correctly CONFIG_ARM64=y should never use legacy
> convention (and never the 32-bit one either?), so we can figure that out
> pretty easily and just force it to use 64-bit if the architecture is
> arm64. If only the 64-bit convention is supported on arm64 then we
> really don't even need to call into the firmware to figure it out on
> arm64. We can do this convention detection stuff on arm32 (CONFIG_ARM)
> and always assume 64-bit convention on CONFIG_ARM64. Is that right?
> 

No, the detection is also needed on ARM64. On ARM32 there can be either
legacy or SMC32, but on ARM64 there can be either SMC32 or SMC64.
You cannot use SMC64 on 32-bit, but you can use SMC32 on ARM64 just
fine. SMC32 is used on MSM8916 for example.

Stephan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ