linux-stable.git/drivers/firmware, branch v6.1.8

gsmi: fix null-deref in gsmi_get_variable

2023-01-24T06:24:39+00:00

commit a769b05eeed7accc4019a1ed9799dd72067f1ce8 upstream.

We can get EFI variables without fetching the attribute, so we must
allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
access layer") added a new get_variable call with attr=NULL, which
triggers panic in gsmi.

Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
Cc: stable 
Signed-off-by: Khazhismel Kumykov 
Link: https://lore.kernel.org/r/20230118010212.1268474-1-khazhy@google.com
Signed-off-by: Greg Kroah-Hartman

efi: fix NULL-deref in init error path

2023-01-18T10:58:32+00:00

[ Upstream commit 703c13fe3c9af557d312f5895ed6a5fda2711104 ]

In cases where runtime services are not supported or have been disabled,
the runtime services workqueue will never have been allocated.

Do not try to destroy the workqueue unconditionally in the unlikely
event that EFI initialisation fails to avoid dereferencing a NULL
pointer.

Fixes: 98086df8b70c ("efi: add missed destroy_workqueue when efisubsys_init fails")
Cc: stable@vger.kernel.org
Cc: Li Heng 
Signed-off-by: Johan Hovold 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

firmware/psci: Don't register with debugfs if PSCI isn't available

2023-01-18T10:58:16+00:00

commit cef139299fd86098c6e3dbd389d1d0b2462d7710 upstream.

Contrary to popular belief, PSCI is not a universal property of an
ARM/arm64 system. There is a garden variety of systems out there
that don't (or even cannot) implement it.

I'm the first one deplore such a situation, but hey...

On such systems, a "cat /sys/kernel/debug/psci" results in
fireworks, as no invocation callback is registered.

Check for the invoke_psci_fn and psci_ops.get_version pointers
before registering with the debugfs subsystem, avoiding the
issue altogether.

Fixes: 3137f2e60098 ("firmware/psci: Add debugfs support to ease debugging")
Reported-by: Hector Martin 
Signed-off-by: Marc Zyngier 
Cc: Dmitry Baryshkov 
Cc: Mark Brown 
Cc: Ulf Hansson 
Cc: Arnd Bergmann 
Cc: Mark Rutland 
Cc: Lorenzo Pieralisi 
Reviewed-by: Hector Martin 
Acked-by: Dmitry Baryshkov 
Acked-by: Mark Rutland 
Link: https://lore.kernel.org/r/20230105090834.630238-1-maz@kernel.org
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

efi: fix userspace infinite retry read efivars after EFI runtime services page fault

2023-01-18T10:58:10+00:00

commit e006ac3003080177cf0b673441a4241f77aaecce upstream.

After [1][2], if we catch exceptions due to EFI runtime service, we will
clear EFI_RUNTIME_SERVICES bit to disable EFI runtime service, then the
subsequent routine which invoke the EFI runtime service should fail.

But the userspace cat efivars through /sys/firmware/efi/efivars/ will stuck
and infinite loop calling read() due to efivarfs_file_read() return -EINTR.

The -EINTR is converted from EFI_ABORTED by efi_status_to_err(), and is
an improper return value in this situation, so let virt_efi_xxx() return
EFI_DEVICE_ERROR and converted to -EIO to invoker.

Cc: 
Fixes: 3425d934fc03 ("efi/x86: Handle page faults occurring while running EFI runtime services")
Fixes: 23715a26c8d8 ("arm64: efi: Recover from synchronous exceptions occurring in firmware")
Signed-off-by: Ding Hui 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

efi: random: combine bootloader provided RNG seed with RNG protocol output

2023-01-12T11:02:58+00:00

commit 196dff2712ca5a2e651977bb2fe6b05474111a83 upstream.

Instead of blindly creating the EFI random seed configuration table if
the RNG protocol is implemented and works, check whether such a EFI
configuration table was provided by an earlier boot stage and if so,
concatenate the existing and the new seeds, leaving it up to the core
code to mix it in and credit it the way it sees fit.

This can be used for, e.g., systemd-boot, to pass an additional seed to
Linux in a way that can be consumed by the kernel very early. In that
case, the following definitions should be used to pass the seed to the
EFI stub:

struct linux_efi_random_seed {
      u32     size; // of the 'seed' array in bytes
      u8      seed[];
};

The memory for the struct must be allocated as EFI_ACPI_RECLAIM_MEMORY
pool memory, and the address of the struct in memory should be installed
as a EFI configuration table using the following GUID:

LINUX_EFI_RANDOM_SEED_TABLE_GUID        1ce1e5bc-7ceb-42f2-81e5-8aadf180f57b

Note that doing so is safe even on kernels that were built without this
patch applied, but the seed will simply be overwritten with a seed
derived from the EFI RNG protocol, if available. The recommended seed
size is 32 bytes, and seeds larger than 512 bytes are considered
corrupted and ignored entirely.

In order to preserve forward secrecy, seeds from previous bootloaders
are memzero'd out, and in order to preserve memory, those older seeds
are also freed from memory. Freeing from memory without first memzeroing
is not safe to do, as it's possible that nothing else will ever
overwrite those pages used by EFI.

Reviewed-by: Jason A. Donenfeld 
[ardb: incorporate Jason's followup changes to extend the maximum seed
       size on the consumer end, memzero() it and drop a needless printk]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Greg Kroah-Hartman

firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe()

2022-12-31T12:32:40+00:00

[ Upstream commit 7b51161696e803fd5f9ad55b20a64c2df313f95c ]

In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will
not be freed through rpi_firmware_delete(), fix this leak by calling
kfree() in the error path.

Fixes: 1e7c57355a3b ("firmware: raspberrypi: Keep count of all consumers")
Signed-off-by: Yang Yingliang 
Link: https://lore.kernel.org/r/20221117070636.3849773-1-yangyingliang@huawei.com
Acked-by: Joel Savitz 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

firmware: ti_sci: Fix polled mode during system suspend

2022-12-31T12:31:48+00:00

[ Upstream commit b13b2c3e0e4d0854228b5217fa34e145f3ace8ac ]

Commit b9e8a7d950ff ("firmware: ti_sci: Switch transport to polled
mode during system suspend") uses read_poll_timeout_atomic() macro
in ti_sci_do_xfer() to wait for completion when the system is
suspending. The break condition of the macro is set to "true" which
will cause it break immediately when evaluated, likely before the
TISCI xfer is completed, and always return 0. We want to poll here
until "done_state == true".

1) Change the break condition of read_poll_timeout_atomic() to
the bool variable "done_state".

2) The read_poll_timeout_atomic() returns 0 if the break condition
is met or -ETIMEDOUT if not. Since our break condition has changed
to "done_state", we also don't have to check for "!done_state" when
evaluating the return value.

Fixes: b9e8a7d950ff ("firmware: ti_sci: Switch transport to polled mode during system suspend")

Signed-off-by: Georgi Vlaev 
Signed-off-by: Nishanth Menon 
Link: https://lore.kernel.org/r/20221021185704.181316-1-g-vlaev@ti.com
Signed-off-by: Sasha Levin

Merge tag 'char-misc-6.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2022-11-18T18:29:25+00:00

Pull char/misc driver fixes from Greg KH:
 "Here are some small char/misc and other driver fixes for 6.1-rc6 to
  resolve some reported problems. Included in here are:

   - iio driver fixes

   - binder driver fix

   - nvmem driver fix

   - vme_vmci information leak fix

   - parport fix

   - slimbus configuration fix

   - coreboot firmware bugfix

   - speakup build fix and crash fix

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'char-misc-6.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (22 commits)
  firmware: coreboot: Register bus in module init
  nvmem: u-boot-env: fix crc32_data_offset on redundant u-boot-env
  slimbus: qcom-ngd: Fix build error when CONFIG_SLIM_QCOM_NGD_CTRL=y && CONFIG_QCOM_RPROC_COMMON=m
  docs: update mediator contact information in CoC doc
  slimbus: stream: correct presence rate frequencies
  nvmem: lan9662-otp: Fix compatible string
  binder: validate alloc->mm in ->mmap() handler
  parport_pc: Avoid FIFO port location truncation
  siox: fix possible memory leak in siox_device_add()
  misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()
  speakup: replace utils' u_char with unsigned char
  speakup: fix a segfault caused by switching consoles
  tools: iio: iio_generic_buffer: Fix read size
  iio: imu: bno055: uninitialized variable bug in bno055_trigger_handler()
  iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger()
  iio: adc: mp2629: fix potential array out of bound access
  iio: adc: mp2629: fix wrong comparison of channel
  iio: pressure: ms5611: changed hardcoded SPI speed to value limited
  iio: pressure: ms5611: fixed value compensation bug
  iio: accel: bma400: Ensure VDDIO is enable defore reading the chip ID.
  ...

Merge tag 'efi-fixes-for-v6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2022-11-13T15:52:22+00:00

Pull EFI fixes from Ard Biesheuvel:

 - Force the use of SetVirtualAddressMap() on Ampera Altra arm64
   machines, which crash in SetTime() if no virtual remapping is used

   This is the first time we've added an SMBIOS based quirk on arm64,
   but fortunately, we can just call a EFI protocol to grab the type #1
   SMBIOS record when running in the stub, so we don't need all the
   machinery we have in the kernel proper to parse SMBIOS data.

 - Drop a spurious warning on misaligned runtime regions when using 16k
   or 64k pages on arm64

* tag 'efi-fixes-for-v6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  arm64: efi: Fix handling of misaligned runtime regions and drop warning
  arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines

arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines

2022-11-10T22:14:14+00:00

Ampere Altra machines are reported to misbehave when the SetTime() EFI
runtime service is called after ExitBootServices() but before calling
SetVirtualAddressMap(). Given that the latter is horrid, pointless and
explicitly documented as optional by the EFI spec, we no longer invoke
it at boot if the configured size of the VA space guarantees that the
EFI runtime memory regions can remain mapped 1:1 like they are at boot
time.

On Ampere Altra machines, this results in SetTime() calls issued by the
rtc-efi driver triggering synchronous exceptions during boot.  We can
now recover from those without bringing down the system entirely, due to
commit 23715a26c8d81291 ("arm64: efi: Recover from synchronous
exceptions occurring in firmware"). However, it would be better to avoid
the issue entirely, given that the firmware appears to remain in a funny
state after this.

So attempt to identify these machines based on the 'family' field in the
type #1 SMBIOS record, and call SetVirtualAddressMap() unconditionally
in that case.

Tested-by: Alexandru Elisei 
Signed-off-by: Ard Biesheuvel