Fix the warning below.
efi/libstub/vsprintf.c:135:2-3: Unneeded semicolon
Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Acked-by: NArvind Sankar <nivedita@alum.mit.edu>
Link: https://lore.kernel.org/r/1599633872-36784-1-git-send-email-tiantao6@hisilicon.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>

Before commit

  d0f9ca9b ("ARM: decompressor: run decompressor in place if loaded via UEFI")

we were rather limited in the choice of base address for the uncompressed
kernel, as we were relying on the logic in the decompressor that blindly
rounds down the decompressor execution address to the next multiple of 128
MiB, and decompresses the kernel there. For this reason, we have a lot of
complicated memory region handling code, to ensure that this memory window
is available, even though it could be occupied by reserved regions or
other allocations that may or may not collide with the uncompressed image.

Today, we simply pass the target address for the decompressed image to the
decompressor directly, and so we can choose a suitable window just by
finding a 16 MiB aligned region, while taking TEXT_OFFSET and the region
for the swapper page tables into account.

So let's get rid of the complicated logic, and instead, use the existing
bottom up allocation routine to allocate a suitable window as low as
possible, and carve out a memory region that has the right properties.

Note that this removes any dependencies on the 'dram_base' argument to
handle_kernel_image(), and so this is removed as well. Given that this
was the only remaining use of dram_base, the code that produces it is
removed entirely as well.
Reviewed-by: NMaxim Uvarov <maxim.uvarov@linaro.org>
Tested-by: NMaxim Uvarov <maxim.uvarov@linaro.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Permit arm32-stub.c to access efi_low_alloc_above() in a subsequent
patch by giving it external linkage and declaring it in efistub.h.
Reviewed-by: NMaxim Uvarov <maxim.uvarov@linaro.org>
Tested-by: NMaxim Uvarov <maxim.uvarov@linaro.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

The way we use the base of DRAM in the EFI stub is problematic as it
is ill defined what the base of DRAM actually means. There are some
restrictions on the placement of FDT and initrd which are defined in
terms of dram_base, but given that the placement of the kernel in
memory is what defines these boundaries (as on ARM, this is where the
linear region starts), it is better to use the image address in these
cases, and disregard dram_base altogether.
Reviewed-by: NMaxim Uvarov <maxim.uvarov@linaro.org>
Tested-by: NMaxim Uvarov <maxim.uvarov@linaro.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

arm-init is responsible for setting up efi runtime and doesn't actually
do any ARM specific stuff. RISC-V can use the same source code as it is.

Rename it to efi-init so that RISC-V can use it.
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Link: https://lore.kernel.org/r/20200819222425.30721-8-atish.patra@wdc.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>

Add helpers to wrap the get_fs/set_fs magic for undoing any damange done
by set_fs(KERNEL_DS).  There is no real functional benefit, but this
documents the intent of these calls better, and will allow stubbing the
functions out easily for kernels builds that do not allow address space
overrides in the future.

[hch@lst.de: drop two incorrect hunks, fix a commit log typo]
  Link: http://lkml.kernel.org/r/20200714105505.935079-6-hch@lst.deSigned-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NGreentime Hu <green.hu@gmail.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Nick Hu <nickhu@andestech.com>
Cc: Vincent Chen <deanbo422@gmail.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Link: http://lkml.kernel.org/r/20200710135706.537715-6-hch@lst.deSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

kobject_init_and_add() takes reference even when it fails.
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Callback function fw_cfg_sysfs_release_entry() in kobject_put()
can handle the pointer "entry" properly.
Signed-off-by: NQiushi Wu <wu000273@umn.edu>
Link: https://lore.kernel.org/r/20200613190533.15712-1-wu000273@umn.eduSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>

This reverts commit 2d38dbf8 as it broke
the build in linux-next
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Fixes: 2d38dbf8 ("test_firmware: Test platform fw loading on non-EFI systems")
Cc: stable@vger.kernel.org
Cc: Scott Branden <scott.branden@broadcom.com>
Cc: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20200727165539.0e8797ab@canb.auug.org.auSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On non-EFI systems, it wasn't possible to test the platform firmware
loader because it will have never set "checked_fw" during __init.
Instead, allow the test code to override this check. Additionally split
the declarations into a private header file so it there is greater
enforcement of the symbol visibility.

Fixes: 548193cb ("test_firmware: add support for firmware_request_platform")
Cc: stable@vger.kernel.org
Acked-by: NScott Branden <scott.branden@broadcom.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20200724213640.389191-2-keescook@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for the Inline Crypto Engine (ICE) key programming interface
that's needed for the ufs-qcom driver to use inline encryption on
Snapdragon SoCs.  This interface consists of two SCM calls: one to program
a key into a keyslot, and one to invalidate a keyslot.

Although the UFS specification defines a standard way to do this, on these
SoCs the Linux kernel isn't permitted to access the needed crypto
configuration registers directly; these SCM calls must be used instead.

Link: https://lore.kernel.org/r/20200710072013.177481-2-ebiggers@kernel.orgAcked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.
Signed-off-by: NAlexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>

The firmware on Turris MOX secure processor offers signing messages
with ECDSA private key stored in protected OTP memory.

The optimal solution would be to register an akcipher provider via
kernel's crypto API, but crypto API does not yet support accessing
akcipher API from userspace (and probably won't for some time, see
https://www.spinics.net/lists/linux-crypto/msg38388.html).

At first I tried to put this via standard sysfs API, but the way I
designed it is not compatible with sysfs's standard "one file per
attribute".

This patch therefore adds support for accessing this signature
generation mechanism via debugfs. Since CZ.NIC's Turris MOX is the only
user of this module, the potential future change to akcipher API should
not cause problems, since we can just change our userspace software then.
Signed-off-by: NMarek Behún <marek.behun@nic.cz>
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>

Kbuild test robot reports the following sparse warning:

drivers/firmware/arm_scmi/clock.c:142:21:
	sparse: Using plain integer as NULL pointer

Use NULL pointer instead of integer 0 for rate pointer and fix the
warning.

Link: https://lore.kernel.org/r/20200717140405.17905-1-sudeep.holla@arm.comReported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Now that there's a function that calculates the SHA-256 digest of a
buffer in one step, use it instead of sha256_init() + sha256_update() +
sha256_final().
Reviewed-by: NArd Biesheuvel <ardb@kernel.org>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Cc: linux-efi@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for retrieving BPMP debug information via in-band messaging
as opposed to using shared-memory which older BPMP firmware used. Note
that it is possible to detect at runtime whether the BPMP firmware being
used supports the in-band messaging for retrieving the debug
informaation. Therefore, if the BPMP firmware supports the in-band
messaging for debug use this and otherwise fall-back to using shared
memory.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Currently, BPMP debug information is accessible via the Linux debugfs
file-system using a shared-memory scheme. More recent BPMP firmware now
supports accessing the debug information by in-band messaging which does
not require shared-memory. To prepare for adding in-band debugfs support
for the BPMP, move the shared-memory specific initialisation from the
tegra_bpmp_init_debugfs() into a sub-function.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Most functions in the BPMP driver use 'err' as the return variable
name but there are a few places that use 'ret'. Let's use 'err' to
be consistent.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add checking of the BPMP-FW return code values for MRQ_DEBUGFS calls.

Also, development versions of the firmware may have debugfs with a
directory structure larger than 256 KiB. Hence increase the size of the
memory buffer to accommodate those firmware revisions.

And finally, ensure that no access outside of allocated memory buffer
happens in case BPMP-FW returns an invalid response size (nbytes) from
mrq_debugfs_dumpdir() call.
Signed-off-by: NTimo Alho <talho@nvidia.com>
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This change adds a compatible for msm8994,
which requires no additional clocks for
scm to probe correctly.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NKonrad Dybcio <konradybcio@gmail.com>
Link: https://lore.kernel.org/r/20200624150107.76234-2-konradybcio@gmail.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The move to a combined driver for the QCOM SCM hardware changed the
io_writel and io_readl helpers to use non-atomic calls, despite the
commit message saying that atomic was a better option. This breaks these
helpers on hardware that uses the old legacy convention (access fails
with a -95 return code). Switch back to using the atomic calls.

Observed as a failure routing GPIO interrupts to the Apps processor on
an IPQ8064; fix is confirmed as correctly allowing the interrupts to be
routed and observed.
Reviewed-by: NElliot Berman <eberman@codeaurora.org>
Fixes: 57d3b816 ("firmware: qcom_scm: Remove thin wrappers")
Cc: stable@vger.kernel.org
Signed-off-by: NJonathan McDowell <noodles@earth.li>
Link: https://lore.kernel.org/r/20200704172334.GA759@earth.liSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Since commit 82046702 ("efi/libstub/arm64: Replace 'preferred' offset
with alignment check"), loading a relocatable arm64 kernel at a physical
address which is not 2MB aligned and subsequently booting with EFI will
leave the Image in-place, relying on the kernel to relocate itself early
during boot. In conjunction with commit dd4bc607 ("arm64: warn on
incorrect placement of the kernel by the bootloader"), which enables
CONFIG_RELOCATABLE by default, this effectively means that entering an
arm64 kernel loaded at an alignment smaller than 2MB with EFI (e.g. using
QEMU) will result in silent relocation at runtime.

Unfortunately, this has a subtle but confusing affect for developers
trying to inspect the PC value during a crash and comparing it to the
symbol addresses in vmlinux using tools such as 'nm' or 'addr2line';
all text addresses will be displaced by a sub-2MB offset, resulting in
the wrong symbol being identified in many cases. Passing "nokaslr" on
the command line or disabling "CONFIG_RANDOMIZE_BASE" does not help,
since the EFI stub only copies the kernel Image to a 2MB boundary if it
is not relocatable.

Adjust the EFI stub for arm64 so that the minimum Image alignment is 2MB
unless KASLR is in use.

Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: David Brazdil <dbrazdil@google.com>
Acked-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NWill Deacon <will@kernel.org>

Event reports are used to convey information describing events to the
registered user-callbacks: they are necessarily derived from the underlying
raw SCMI events' messages but they are not meant to expose or directly
mirror any of those messages data layout, which belong to the protocol
layer.

Using fixed size types for report fields, mirroring messages structure,
is at odd with this: get rid of them using more generic, equivalent,
typing.

Substitute scmi_event_header fixed size fields with generic types too and
shuffle around fields definitions to minimize implicit padding while
adapting involved functions.

Link: https://lore.kernel.org/r/20200710133919.39792-3-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Remove __packed attribute from struct scmi_event_header.

Link: https://lore.kernel.org/r/20200710133919.39792-2-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

gcc as well as clang now produce warnings for missing kerneldoc function
parameter.

Fix the following W=1 kernel build warning:

drivers/firmware/arm_scmi/smc.c:32:
 warning: Function parameter or member 'shmem_lock' not described in 'scmi_smc'

Link: https://lore.kernel.org/r/20200709153155.22573-1-sudeep.holla@arm.comReported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

The i.MX SCU soc driver depends on SCU firmware driver, so it has to
use platform driver model for proper defer probe operation, since
it has no device binding in DT file, a simple platform device is
created together inside the platform driver. To make it more clean,
we can just move the entire SCU soc driver into imx firmware folder
and initialized by i.MX SCU firmware driver.
Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

Instead of relying on the firmware to keep the clock rates sorted, let
us sort the list. This is not essential for clock layer but it helps
to find the min and max rates easily from the list.

Link: https://lore.kernel.org/r/20200709081705.46084-1-sudeep.holla@arm.com
Fixes: 5f6c6430 ("firmware: arm_scmi: add initial support for clock protocol")
Reported-and-tested-by: NDien Pham <dien.pham.ry@renesas.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

This reverts commit 5435f73d, which is no longer needed now
that the minimum GCC version has been bumped to v4.9
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

Commit

  bf67fad1 ("efi: Use more granular check for availability for variable services")

introduced a check into the efivarfs, efi-pstore and other drivers that
aborts loading of the module if not all three variable runtime services
(GetVariable, SetVariable and GetNextVariable) are supported. However, this
results in efivarfs being unavailable entirely if only SetVariable support
is missing, which is only needed if you want to make any modifications.
Also, efi-pstore and the sysfs EFI variable interface could be backed by
another implementation of the 'efivars' abstraction, in which case it is
completely irrelevant which services are supported by the EFI firmware.

So make the generic 'efivars' abstraction dependent on the availibility of
the GetVariable and GetNextVariable EFI runtime services, and add a helper
'efivar_supports_writes()' to find out whether the currently active efivars
abstraction supports writes (and wire it up to the availability of
SetVariable for the generic one).

Then, use the efivar_supports_writes() helper to decide whether to permit
efivarfs to be mounted read-write, and whether to enable efi-pstore or the
sysfs EFI variable interface altogether.

Fixes: bf67fad1 ("efi: Use more granular check for availability for variable services")
Reported-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

The prototype of the functions handle_kernel_image & efi_enter_kernel
are defined in efi-stub.c which may result in a compiler warnings if
-Wmissing-prototypes is set in gcc compiler.

Move the prototype to efistub.h to make the compiler happy.
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Link: https://lore.kernel.org/r/20200706172609.25965-2-atish.patra@wdc.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>

32bit gcc doesn't support modulo operation on 64 bit data. It results in
a __umoddi3 error while building EFI for 32 bit.

Use bitwise operations instead of modulo operations to fix the issue.
Signed-off-by: NAtish Patra <atish.patra@wdc.com>
Link: https://lore.kernel.org/r/20200625234516.31406-2-atish.patra@wdc.comSigned-off-by: NArd Biesheuvel <ardb@kernel.org>

The return value of down_and_up_cpus() can be assigned to @err directly.
With that, the useless assignment to @err with zero can be dropped.
Signed-off-by: NGavin Shan <gshan@redhat.com>
Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20200630075943.203954-1-gshan@redhat.comSigned-off-by: NWill Deacon <will@kernel.org>

The CPU mask (@tmp) should be released on failing to allocate
@cpu_groups or any of its elements. Otherwise, it leads to memory
leakage because the CPU mask variable is dynamically allocated
when CONFIG_CPUMASK_OFFSTACK is enabled.
Signed-off-by: NGavin Shan <gshan@redhat.com>
Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20200630075227.199624-1-gshan@redhat.comSigned-off-by: NWill Deacon <will@kernel.org>

Some Makefiles already pass -ffreestanding unconditionally.
For example, arch/arm64/lib/Makefile, arch/x86/purgatory/Makefile.

No problem report so far about hard-coding this option. So, we can
assume all supported compilers know -ffreestanding.

I confirmed GCC 4.8 and Clang manuals document this option.

Get rid of cc-option from -ffreestanding.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Acked-by: NArd Biesheuvel <ardb@kernel.org>

Some Makefiles already pass -fno-stack-protector unconditionally.
For example, arch/arm64/kernel/vdso/Makefile, arch/x86/xen/Makefile.

No problem report so far about hard-coding this option. So, we can
assume all supported compilers know -fno-stack-protector.

GCC 4.8 and Clang support this option (https://godbolt.org/z/_HDGzN)

Get rid of cc-option from -fno-stack-protector.

Remove CONFIG_CC_HAS_STACKPROTECTOR_NONE, which is always 'y'.

Note:
arch/mips/vdso/Makefile adds -fno-stack-protector twice, first
unconditionally, and second conditionally. I removed the second one.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Acked-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

SMCCC v1.2 adds a new optional function SMCCC_ARCH_SOC_ID to obtain a
SiP defined SoC identification value. Add support for the same.

Also using the SoC bus infrastructure, let us expose the platform
specific SoC atrributes under sysfs.

There are various ways in which it can be represented in shortened form
for efficiency and ease of parsing for userspace. The chosen form is
described in the ABI document.

Link: https://lore.kernel.org/r/20200625095939.50861-1-sudeep.holla@arm.com
Cc: Etienne Carriere <etienne.carriere@st.com>
Reviewed-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Patch fixes sparse warnings: using plain integer as NULL pointer. Replaces
equal to with logical not operator.
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NRichard Gong <richard.gong@intel.com>
Link: https://lore.kernel.org/r/1591193212-15082-1-git-send-email-richard.gong@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Extend Intel Remote System Update (RSU) driver to get decision
configuration management firmware (DCMF) versions and max retry
parameter value.
Signed-off-by: NRichard Gong <richard.gong@intel.com>
Link: https://lore.kernel.org/r/1592231348-31334-4-git-send-email-richard.gong@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Extend Intel Stratix10 service layer driver to support new RSU DCMF
versions and max retry parameter.

DCMF = Decision Configuration Management Firmware. The max retry parameter
is the maximum times the images is allowed to reload itself before giving
up and starting RSU failover flow.
Signed-off-by: NRichard Gong <richard.gong@intel.com>
Link: https://lore.kernel.org/r/1592231348-31334-3-git-send-email-richard.gong@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make SCMI base protocol register with the notification core.

Link: https://lore.kernel.org/r/20200701155348.52864-10-cristian.marussi@arm.comReviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Make SCMI reset protocol register with the notification core.

Link: https://lore.kernel.org/r/20200701155348.52864-9-cristian.marussi@arm.comReviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>