linux-stable.git/drivers/firmware/google, branch v6.2

gsmi: fix null-deref in gsmi_get_variable

2023-01-20T12:23:42+00:00

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

firmware: coreboot: Check size of table entry and use flex-array

2023-01-13T23:22:03+00:00

The memcpy() of the data following a coreboot_table_entry couldn't
be evaluated by the compiler under CONFIG_FORTIFY_SOURCE. To make it
easier to reason about, add an explicit flexible array member to struct
coreboot_device so the entire entry can be copied at once. Additionally,
validate the sizes before copying. Avoids this run-time false positive
warning:

  memcpy: detected field-spanning write (size 168) of single field "&device->entry" at drivers/firmware/google/coreboot_table.c:103 (size 8)

Reported-by: Paul Menzel 
Link: https://lore.kernel.org/all/03ae2704-8c30-f9f0-215b-7cdf4ad35a9a@molgen.mpg.de/
Cc: Jack Rosenthal 
Cc: Guenter Roeck 
Cc: Julius Werner 
Cc: Brian Norris 
Cc: Stephen Boyd 
Cc: Greg Kroah-Hartman 
Signed-off-by: Kees Cook 
Reviewed-by: Julius Werner 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20230107031406.gonna.761-kees@kernel.org
Reviewed-by: Stephen Boyd 
Reviewed-by: Jack Rosenthal 
Link: https://lore.kernel.org/r/20230112230312.give.446-kees@kernel.org

firmware: google: fix a NULL vs IS_ERR() check in cbmem_entry_probe()

2022-11-23T19:03:14+00:00

The devm_memremap() function returns error pointers on error,
it doesn't return NULL.

Fixes: 19d54020883c ("firmware: google: Implement cbmem in sysfs driver")
Signed-off-by: Peng Wu 
Reviewed-by: Guenter Roeck 
Reviewed-by: Jack Rosenthal 
Link: https://lore.kernel.org/r/20221115091138.51614-1-wupeng58@huawei.com
Signed-off-by: Greg Kroah-Hartman

Merge 6.1-rc6 into char-misc-next

2022-11-21T09:05:34+00:00

We need the char/misc fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

firmware: google: Implement cbmem in sysfs driver

2022-11-10T17:51:56+00:00

The CBMEM area is a downward-growing memory region used by coreboot to
dynamically allocate tagged data structures ("CBMEM entries") that
remain resident during boot.

This implements a driver which exports access to the CBMEM entries
via sysfs under /sys/bus/coreboot/devices/cbmem-.

This implementation is quite versatile.  Examples of how it could be
used are given below:

* Tools like util/cbmem from the coreboot tree could use this driver
  instead of finding CBMEM in /dev/mem directly.  Alternatively,
  firmware developers debugging an issue may find the sysfs interface
  more ergonomic than the cbmem tool and choose to use it directly.

* The crossystem tool, which exposes verified boot variables, can use
  this driver to read the vboot work buffer.

* Tools which read the BIOS SPI flash (e.g., flashrom) can find the
  flash layout in CBMEM directly, which is significantly faster than
  searching the flash directly.

Write access is provided to all CBMEM regions via
/sys/bus/coreboot/devices/cbmem-/mem, as the existing cbmem
tooling updates this memory region, and envisioned use cases with
crossystem can benefit from updating memory regions.

Link: https://issuetracker.google.com/239604743
Cc: Stephen Boyd 
Cc: Tzung-Bi Shih 
Reviewed-by: Guenter Roeck 
Reviewed-by: Julius Werner 
Tested-by: Jack Rosenthal 
Signed-off-by: Jack Rosenthal 
Link: https://lore.kernel.org/r/20221104161528.531248-1-jrosenth@chromium.org
Signed-off-by: Greg Kroah-Hartman

firmware: coreboot: Register bus in module init

2022-11-10T17:47:53+00:00

The coreboot_table driver registers a coreboot bus while probing a
"coreboot_table" device representing the coreboot table memory region.
Probing this device (i.e., registering the bus) is a dependency for the
module_init() functions of any driver for this bus (e.g.,
memconsole-coreboot.c / memconsole_driver_init()).

With synchronous probe, this dependency works OK, as the link order in
the Makefile ensures coreboot_table_driver_init() (and thus,
coreboot_table_probe()) completes before a coreboot device driver tries
to add itself to the bus.

With asynchronous probe, however, coreboot_table_probe() may race with
memconsole_driver_init(), and so we're liable to hit one of these two:

1. coreboot_driver_register() eventually hits "[...] the bus was not
   initialized.", and the memconsole driver fails to register; or
2. coreboot_driver_register() gets past #1, but still races with
   bus_register() and hits some other undefined/crashing behavior (e.g.,
   in driver_find() [1])

We can resolve this by registering the bus in our initcall, and only
deferring "device" work (scanning the coreboot memory region and
creating sub-devices) to probe().

[1] Example failure, using 'driver_async_probe=*' kernel command line:

[    0.114217] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
...
[    0.114307] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc1 #63
[    0.114316] Hardware name: Google Scarlet (DT)
...
[    0.114488] Call trace:
[    0.114494]  _raw_spin_lock+0x34/0x60
[    0.114502]  kset_find_obj+0x28/0x84
[    0.114511]  driver_find+0x30/0x50
[    0.114520]  driver_register+0x64/0x10c
[    0.114528]  coreboot_driver_register+0x30/0x3c
[    0.114540]  memconsole_driver_init+0x24/0x30
[    0.114550]  do_one_initcall+0x154/0x2e0
[    0.114560]  do_initcall_level+0x134/0x160
[    0.114571]  do_initcalls+0x60/0xa0
[    0.114579]  do_basic_setup+0x28/0x34
[    0.114588]  kernel_init_freeable+0xf8/0x150
[    0.114596]  kernel_init+0x2c/0x12c
[    0.114607]  ret_from_fork+0x10/0x20
[    0.114624] Code: 5280002b 1100054a b900092a f9800011 (885ffc01)
[    0.114631] ---[ end trace 0000000000000000 ]---

Fixes: b81e3140e412 ("firmware: coreboot: Make bus registration symmetric")
Cc: 
Signed-off-by: Brian Norris 
Reviewed-by: Guenter Roeck 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20221019180934.1.If29e167d8a4771b0bf4a39c89c6946ed764817b9@changeid
Signed-off-by: Greg Kroah-Hartman

firmware: google: Test spinlock on panic path to avoid lockups

2022-09-24T12:59:44+00:00

Currently the gsmi driver registers a panic notifier as well as
reboot and die notifiers. The callbacks registered are called in
atomic and very limited context - for instance, panic disables
preemption and local IRQs, also all secondary CPUs (not executing
the panic path) are shutdown.

With that said, taking a spinlock in this scenario is a dangerous
invitation for lockup scenarios. So, fix that by checking if the
spinlock is free to acquire in the panic notifier callback - if not,
bail-out and avoid a potential hang.

Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
Cc: Andrew Morton 
Cc: Ard Biesheuvel 
Cc: David Gow 
Cc: Greg Kroah-Hartman 
Cc: Julius Werner 
Cc: Petr Mladek 
Reviewed-by: Evan Green 
Signed-off-by: Guilherme G. Piccoli 
Link: https://lore.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com
Signed-off-by: Greg Kroah-Hartman

firmware: google: Properly state IOMEM dependency

2022-03-18T13:18:15+00:00

The Google Coreboot implementation requires IOMEM functions
(memmremap, memunmap, devm_memremap), but does not specify this is its
Kconfig. This results in build errors when HAS_IOMEM is not set, such as
on some UML configurations:

/usr/bin/ld: drivers/firmware/google/coreboot_table.o: in function `coreboot_table_probe':
coreboot_table.c:(.text+0x311): undefined reference to `memremap'
/usr/bin/ld: coreboot_table.c:(.text+0x34e): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/memconsole-coreboot.o: in function `memconsole_probe':
memconsole-coreboot.c:(.text+0x12d): undefined reference to `memremap'
/usr/bin/ld: memconsole-coreboot.c:(.text+0x17e): undefined reference to `devm_memremap'
/usr/bin/ld: memconsole-coreboot.c:(.text+0x191): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_section_destroy.isra.0':
vpd.c:(.text+0x300): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_section_init':
vpd.c:(.text+0x382): undefined reference to `memremap'
/usr/bin/ld: vpd.c:(.text+0x459): undefined reference to `memunmap'
/usr/bin/ld: drivers/firmware/google/vpd.o: in function `vpd_probe':
vpd.c:(.text+0x59d): undefined reference to `memremap'
/usr/bin/ld: vpd.c:(.text+0x5d3): undefined reference to `memunmap'
collect2: error: ld returned 1 exit status

Fixes: a28aad66da8b ("firmware: coreboot: Collapse platform drivers into bus core")
Acked-By: anton ivanov 
Acked-By: Julius Werner 
Signed-off-by: David Gow 
Link: https://lore.kernel.org/r/20220225041502.1901806-1-davidgow@google.com
Signed-off-by: Greg Kroah-Hartman

firmware: Update Kconfig help text for Google firmware

2021-12-21T09:12:31+00:00

The help text for GOOGLE_FIRMWARE states that it should only be
enabled when building a kernel for Google's own servers.  However,
many of the drivers dependent on it are also useful on Chromebooks or
on any platform using coreboot.

Update the help text to reflect this double duty.

Fixes: d384d6f43d1e ("firmware: google memconsole: Add coreboot support")
Reviewed-by: Julius Werner 
Signed-off-by: Ben Hutchings 
Link: https://lore.kernel.org/r/20180618225540.GD14131@decadent.org.uk
Signed-off-by: Greg Kroah-Hartman

bus: Make remove callback return void

2021-07-21T09:53:42+00:00

The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.

This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were fixed that were caused by drivers
returning an error code in the expectation that the driver won't go
away.

With struct bus_type::remove returning void it's prevented that newly
implemented buses return an ignored error code and so don't anticipate
wrong expectations for driver authors.

Reviewed-by: Tom Rix  (For fpga)
Reviewed-by: Mathieu Poirier 
Reviewed-by: Cornelia Huck  (For drivers/s390 and drivers/vfio)
Acked-by: Russell King (Oracle)  (For ARM, Amba and related parts)
Acked-by: Mark Brown 
Acked-by: Chen-Yu Tsai  (for sunxi-rsb)
Acked-by: Pali Rohár 
Acked-by: Mauro Carvalho Chehab  (for media)
Acked-by: Hans de Goede  (For drivers/platform)
Acked-by: Alexandre Belloni 
Acked-By: Vinod Koul 
Acked-by: Juergen Gross  (For xen)
Acked-by: Lee Jones  (For mfd)
Acked-by: Johannes Thumshirn  (For mcb)
Acked-by: Johan Hovold 
Acked-by: Srinivas Kandagatla  (For slimbus)
Acked-by: Kirti Wankhede  (For vfio)
Acked-by: Maximilian Luz 
Acked-by: Heikki Krogerus  (For ulpi and typec)
Acked-by: Samuel Iglesias Gonsálvez  (For ipack)
Acked-by: Geoff Levand  (For ps3)
Acked-by: Yehezkel Bernat  (For thunderbolt)
Acked-by: Alexander Shishkin  (For intel_th)
Acked-by: Dominik Brodowski  (For pcmcia)
Acked-by: Rafael J. Wysocki  (For ACPI)
Acked-by: Bjorn Andersson  (rpmsg and apr)
Acked-by: Srinivas Pandruvada  (For intel-ish-hid)
Acked-by: Dan Williams  (For CXL, DAX, and NVDIMM)
Acked-by: William Breathitt Gray  (For isa)
Acked-by: Stefan Richter  (For firewire)
Acked-by: Benjamin Tissoires  (For hid)
Acked-by: Thorsten Scherer  (For siox)
Acked-by: Sven Van Asbroeck  (For anybuss)
Acked-by: Ulf Hansson  (For MMC)
Acked-by: Wolfram Sang  # for I2C
Acked-by: Sudeep Holla 
Acked-by: Geert Uytterhoeven 
Acked-by: Dmitry Torokhov 
Acked-by: Finn Thain 
Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20210713193522.1770306-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman