linux-stable.git/drivers/firmware/google, branch v4.14.331

gsmi: fix null-deref in gsmi_get_variable

2023-01-24T06:05:19+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

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

2022-10-26T11:17:06+00:00

[ Upstream commit 3e081438b8e639cc76ef1a5ce0c1bd8a154082c7 ]

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 
Signed-off-by: Sasha Levin

firmware: Update Kconfig help text for Google firmware

2022-01-27T08:00:59+00:00

commit d185a3466f0cd5af8f1c5c782c53bc0e6f2e7136 upstream.

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

gsmi: Fix bug in append_to_eventlog sysfs handler

2019-12-01T08:13:23+00:00

[ Upstream commit 655603de68469adaff16842ac17a5aec9c9ce89b ]

The sysfs handler should return the number of bytes consumed, which in the
case of a successful write is the entire buffer.  Also fix a bug where
param.data_len was being set to (count - (2 * sizeof(u32))) instead of just
(count - sizeof(u32)).  The latter is correct because we skip over the
leading u32 which is our param.type, but we were also incorrectly
subtracting sizeof(u32) on the line where we were actually setting
param.data_len:

	param.data_len = count - sizeof(u32);

This meant that for our example event.kernel_software_watchdog with total
length 10 bytes, param.data_len was just 2 prior to this change.

To test, successfully append an event to the log with gsmi sysfs.
This sample event is for a "Kernel Software Watchdog"

> xxd -g 1 event.kernel_software_watchdog
0000000: 01 00 00 00 ad de 06 00 00 00

> cat event.kernel_software_watchdog > /sys/firmware/gsmi/append_to_eventlog

> mosys eventlog list | tail -1
14 | 2012-06-25 10:14:14 | Kernl Event | Software Watchdog

Signed-off-by: Duncan Laurie 
Reviewed-by: Vadim Bendebury 
Reviewed-by: Stefan Reinauer 
Signed-off-by: Furquan Shaikh 
Tested-by: Furquan Shaikh 
Reviewed-by: Aaron Durbin 
Reviewed-by: Justin TerAvest 
[zwisler: updated changelog for 2nd bug fix and upstream]
Signed-off-by: Ross Zwisler 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

firmware: google: increment VPD key_len properly

2019-10-17T20:43:45+00:00

[ Upstream commit 442f1e746e8187b9deb1590176f6b0ff19686b11 ]

Commit 4b708b7b1a2c ("firmware: google: check if size is valid when
decoding VPD data") adds length checks, but the new vpd_decode_entry()
function botched the logic -- it adds the key length twice, instead of
adding the key and value lengths separately.

On my local system, this means vpd.c's vpd_section_create_attribs() hits
an error case after the first attribute it parses, since it's no longer
looking at the correct offset. With this patch, I'm back to seeing all
the correct attributes in /sys/firmware/vpd/...

Fixes: 4b708b7b1a2c ("firmware: google: check if size is valid when decoding VPD data")
Cc: 
Cc: Hung-Te Lin 
Signed-off-by: Brian Norris 
Reviewed-by: Stephen Boyd 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20190930214522.240680-1-briannorris@chromium.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

firmware: google: check if size is valid when decoding VPD data

2019-09-21T05:15:29+00:00

commit 4b708b7b1a2c09fbdfff6b942ebe3a160213aacd upstream.

The VPD implementation from Chromium Vital Product Data project used to
parse data from untrusted input without checking if the meta data is
invalid or corrupted. For example, the size from decoded content may
be negative value, or larger than whole input buffer. Such invalid data
may cause buffer overflow.

To fix that, the size parameters passed to vpd_decode functions should
be changed to unsigned integer (u32) type, and the parsing of entry
header should be refactored so every size field is correctly verified
before starting to decode.

Fixes: ad2ac9d5c5e0 ("firmware: Google VPD: import lib_vpd source files")
Signed-off-by: Hung-Te Lin 
Cc: stable 
Reviewed-by: Guenter Roeck 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20190830022402.214442-1-hungte@chromium.org
Signed-off-by: Greg Kroah-Hartman

firmware: vpd: Fix section enabled flag on vpd_section_destroy

2018-09-19T20:43:40+00:00

[ Upstream commit 45ca3f76de0507ecf143f770570af2942f263812 ]

static struct ro_vpd and rw_vpd are initialized by vpd_sections_init()
in vpd_probe() based on header's ro and rw sizes.
In vpd_remove() vpd_section_destroy() performs deinitialization based
on enabled flag, which is set to true by vpd_sections_init().
This leads to call of vpd_section_destroy() on already destroyed section
for probe-release-probe-release sequence if first probe performs
ro_vpd initialization and second probe does not initialize it.

The patch adds changing enabled flag on vpd_section_destroy and adds
cleanup on the error path of vpd_sections_init.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

firmware: vpd: Fix platform driver and device registration/unregistration

2017-12-14T08:52:50+00:00

commit 0631fb8b027f5968c2f5031f0b3ff7be3e4bebcc upstream.

The driver exit function needs to unregister both platform device and
driver. Also, during registration, register driver first and perform
error checks.

Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver")
Signed-off-by: Guenter Roeck 
Tested-by: Randy Dunlap 
Reviewed-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

firmware: vpd: Tie firmware kobject to device lifetime

2017-12-14T08:52:50+00:00

commit e4b28b3c3a405b251fa25db58abe1512814a680a upstream.

It doesn't make sense to have /sys/firmware/vpd if the device is not
instantiated, so tie its lifetime to the device.

Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver")
Signed-off-by: Guenter Roeck 
Reviewed-by: Dmitry Torokhov 
Tested-by: Randy Dunlap 
Signed-off-by: Greg Kroah-Hartman

firmware: vpd: Destroy vpd sections in remove function

2017-12-14T08:52:50+00:00

commit 811d7e0215fb738fb9a9f0bcb1276516ad161ed1 upstream.

vpd sections are initialized during probe and thus should be destroyed
in the remove function.

Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver")
Signed-off-by: Guenter Roeck 
Reviewed-by: Dmitry Torokhov 
Tested-by: Randy Dunlap 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman