<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/firmware, branch v4.4.265</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.265</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.265'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-06-30T00:08:01Z</updated>
<entry>
<title>efi/esrt: Fix reference count leak in esre_create_sysfs_entry.</title>
<updated>2020-06-30T00:08:01Z</updated>
<author>
<name>Qiushi Wu</name>
<email>wu000273@umn.edu</email>
</author>
<published>2020-05-28T18:38:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8da5b2305f6244184f0debde4ff3029788f27228'/>
<id>urn:sha1:8da5b2305f6244184f0debde4ff3029788f27228</id>
<content type='text'>
[ Upstream commit 4ddf4739be6e375116c375f0a68bf3893ffcee21 ]

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. Previous
commit "b8eb718348b8" fixed a similar problem.

Fixes: 0bb549052d33 ("efi: Add esrt support")
Signed-off-by: Qiushi Wu &lt;wu000273@umn.edu&gt;
Link: https://lore.kernel.org/r/20200528183804.4497-1-wu000273@umn.edu
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/efivars: Add missing kobject_put() in sysfs entry creation error path</title>
<updated>2020-06-20T08:23:16Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2020-05-22T16:15:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0071e8e4fb6c7da62b716f61e6264b3a294e8d30'/>
<id>urn:sha1:0071e8e4fb6c7da62b716f61e6264b3a294e8d30</id>
<content type='text'>
commit d8bd8c6e2cfab8b78b537715255be8d7557791c0 upstream.

The documentation provided by kobject_init_and_add() clearly spells out
the need to call kobject_put() on the kobject if an error is returned.
Add this missing call to the error path.

Cc: &lt;stable@vger.kernel.org&gt;
Reported-by: 亿一 &lt;teroincn@gmail.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>efi: Add a sanity check to efivar_store_raw()</title>
<updated>2020-03-20T08:06:24Z</updated>
<author>
<name>Vladis Dronov</name>
<email>vdronov@redhat.com</email>
</author>
<published>2020-03-08T08:08:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a9cd480120fd019b96b20d1018055c5ae152d893'/>
<id>urn:sha1:a9cd480120fd019b96b20d1018055c5ae152d893</id>
<content type='text'>
commit d6c066fda90d578aacdf19771a027ed484a79825 upstream.

Add a sanity check to efivar_store_raw() the same way
efivar_{attr,size,data}_read() and efivar_show_raw() have it.

Signed-off-by: Vladis Dronov &lt;vdronov@redhat.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20200305084041.24053-3-vdronov@redhat.com
Link: https://lore.kernel.org/r/20200308080859.21568-25-ardb@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>efi: Fix a race and a buffer overflow while reading efivars via sysfs</title>
<updated>2020-03-20T08:06:22Z</updated>
<author>
<name>Vladis Dronov</name>
<email>vdronov@redhat.com</email>
</author>
<published>2020-03-08T08:08:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=34f7a385e26d58d0ea7bf9e83728ec6a7274fc74'/>
<id>urn:sha1:34f7a385e26d58d0ea7bf9e83728ec6a7274fc74</id>
<content type='text'>
commit 286d3250c9d6437340203fb64938bea344729a0e upstream.

There is a race and a buffer overflow corrupting a kernel memory while
reading an EFI variable with a size more than 1024 bytes via the older
sysfs method. This happens because accessing struct efi_variable in
efivar_{attr,size,data}_read() and friends is not protected from
a concurrent access leading to a kernel memory corruption and, at best,
to a crash. The race scenario is the following:

CPU0:                                CPU1:
efivar_attr_read()
  var-&gt;DataSize = 1024;
  efivar_entry_get(... &amp;var-&gt;DataSize)
    down_interruptible(&amp;efivars_lock)
                                     efivar_attr_read() // same EFI var
                                       var-&gt;DataSize = 1024;
                                       efivar_entry_get(... &amp;var-&gt;DataSize)
                                         down_interruptible(&amp;efivars_lock)
    virt_efi_get_variable()
    // returns EFI_BUFFER_TOO_SMALL but
    // var-&gt;DataSize is set to a real
    // var size more than 1024 bytes
    up(&amp;efivars_lock)
                                         virt_efi_get_variable()
                                         // called with var-&gt;DataSize set
                                         // to a real var size, returns
                                         // successfully and overwrites
                                         // a 1024-bytes kernel buffer
                                         up(&amp;efivars_lock)

This can be reproduced by concurrent reading of an EFI variable which size
is more than 1024 bytes:

  ts# for cpu in $(seq 0 $(nproc --ignore=1)); do ( taskset -c $cpu \
  cat /sys/firmware/efi/vars/KEKDefault*/size &amp; ) ; done

Fix this by using a local variable for a var's data buffer size so it
does not get overwritten.

Fixes: e14ab23dde12b80d ("efivars: efivar_entry API")
Reported-by: Bob Sanders &lt;bob.sanders@hpe.com&gt; and the LTP testsuite
Signed-off-by: Vladis Dronov &lt;vdronov@redhat.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20200305084041.24053-2-vdronov@redhat.com
Link: https://lore.kernel.org/r/20200308080859.21568-24-ardb@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>gsmi: Fix bug in append_to_eventlog sysfs handler</title>
<updated>2019-11-28T17:25:38Z</updated>
<author>
<name>Duncan Laurie</name>
<email>dlaurie@chromium.org</email>
</author>
<published>2018-10-12T16:04:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0097c8510dec0b78c279013fba78660b90697c30'/>
<id>urn:sha1:0097c8510dec0b78c279013fba78660b90697c30</id>
<content type='text'>
[ 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"

&gt; xxd -g 1 event.kernel_software_watchdog
0000000: 01 00 00 00 ad de 06 00 00 00

&gt; cat event.kernel_software_watchdog &gt; /sys/firmware/gsmi/append_to_eventlog

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

Signed-off-by: Duncan Laurie &lt;dlaurie@chromium.org&gt;
Reviewed-by: Vadim Bendebury &lt;vbendeb@chromium.org&gt;
Reviewed-by: Stefan Reinauer &lt;reinauer@chromium.org&gt;
Signed-off-by: Furquan Shaikh &lt;furquan@google.com&gt;
Tested-by: Furquan Shaikh &lt;furquan@chromium.org&gt;
Reviewed-by: Aaron Durbin &lt;adurbin@chromium.org&gt;
Reviewed-by: Justin TerAvest &lt;teravest@chromium.org&gt;
[zwisler: updated changelog for 2nd bug fix and upstream]
Signed-off-by: Ross Zwisler &lt;zwisler@google.com&gt;
Reviewed-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware/psci: Expose SMCCC version through psci_ops</title>
<updated>2019-11-10T10:21:19Z</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2019-11-08T12:35:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2217fa9f88753f455f948e89a21f7b5e882809e1'/>
<id>urn:sha1:2217fa9f88753f455f948e89a21f7b5e882809e1</id>
<content type='text'>
commit e78eef554a912ef6c1e0bbf97619dafbeae3339f upstream.

Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed,
let's do that at boot time, and expose the version of the calling
convention as part of the psci_ops structure.

Acked-by: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&gt;
Reviewed-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Tested-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt; [v4.9 backport]
Tested-by: Greg Hackmann &lt;ghackmann@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware/psci: Expose PSCI conduit</title>
<updated>2019-11-10T10:21:19Z</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2019-11-08T12:35:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0a65b836f2bf5bcd46afd62a9b322065a68afdf7'/>
<id>urn:sha1:0a65b836f2bf5bcd46afd62a9b322065a68afdf7</id>
<content type='text'>
commit 09a8d6d48499f93e2abde691f5800081cd858726 upstream.

In order to call into the firmware to apply workarounds, it is
useful to find out whether we're using HVC or SMC. Let's expose
this through the psci_ops.

Acked-by: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&gt;
Reviewed-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Tested-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt; [v4.9 backport]
Tested-by: Greg Hackmann &lt;ghackmann@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ARM: 8481/2: drivers: psci: replace psci firmware calls</title>
<updated>2019-11-10T10:21:16Z</updated>
<author>
<name>Jens Wiklander</name>
<email>jens.wiklander@linaro.org</email>
</author>
<published>2019-11-08T12:35:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8e0a4c1012500d837e8f611fd2c0465ac671c913'/>
<id>urn:sha1:8e0a4c1012500d837e8f611fd2c0465ac671c913</id>
<content type='text'>
Commit e679660dbb8347f275fe5d83a5dd59c1fb6c8e63 upstream.

Switch to use a generic interface for issuing SMC/HVC based on ARM SMC
Calling Convention. Removes now the now unused psci-call.S.

Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Reviewed-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Tested-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Acked-by: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&gt;
Tested-by: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&gt;
Signed-off-by: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ARM: 8478/2: arm/arm64: add arm-smccc</title>
<updated>2019-11-10T10:21:15Z</updated>
<author>
<name>Jens Wiklander</name>
<email>jens.wiklander@linaro.org</email>
</author>
<published>2019-11-08T12:35:06Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=36e7c2e687603c81dc47152537bd91cce681f0dc'/>
<id>urn:sha1:36e7c2e687603c81dc47152537bd91cce681f0dc</id>
<content type='text'>
Commit 98dd64f34f47ce19b388d9015f767f48393a81eb upstream.

Adds helpers to do SMC and HVC based on ARM SMC Calling Convention.
CONFIG_HAVE_ARM_SMCCC is enabled for architectures that may support the
SMC or HVC instruction. It's the responsibility of the caller to know if
the SMC instruction is supported by the platform.

This patch doesn't provide an implementation of the declared functions.
Later patches will bring in implementations and set
CONFIG_HAVE_ARM_SMCCC for ARM and ARM64 respectively.

Reviewed-by: Lorenzo Pieralisi &lt;lorenzo.pieralisi@arm.com&gt;
Signed-off-by: Jens Wiklander &lt;jens.wiklander@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>efi/cper: Fix endianness of PCIe class code</title>
<updated>2019-11-06T11:09:14Z</updated>
<author>
<name>Lukas Wunner</name>
<email>lukas@wunner.de</email>
</author>
<published>2019-10-02T16:58:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=492fbc76b94e55fb4d2fa40a756e4c20218f9b32'/>
<id>urn:sha1:492fbc76b94e55fb4d2fa40a756e4c20218f9b32</id>
<content type='text'>
[ Upstream commit 6fb9367a15d1a126d222d738b2702c7958594a5f ]

The CPER parser assumes that the class code is big endian, but at least
on this edk2-derived Intel Purley platform it's little endian:

    efi: EFI v2.50 by EDK II BIOS ID:PLYDCRB1.86B.0119.R05.1701181843
    DMI: Intel Corporation PURLEY/PURLEY, BIOS PLYDCRB1.86B.0119.R05.1701181843 01/18/2017

    {1}[Hardware Error]:   device_id: 0000:5d:00.0
    {1}[Hardware Error]:   slot: 0
    {1}[Hardware Error]:   secondary_bus: 0x5e
    {1}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x2030
    {1}[Hardware Error]:   class_code: 000406
                                       ^^^^^^ (should be 060400)

Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Cc: Ben Dooks &lt;ben.dooks@codethink.co.uk&gt;
Cc: Dave Young &lt;dyoung@redhat.com&gt;
Cc: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Cc: Jerry Snitselaar &lt;jsnitsel@redhat.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Lyude Paul &lt;lyude@redhat.com&gt;
Cc: Matthew Garrett &lt;mjg59@google.com&gt;
Cc: Octavian Purdila &lt;octavian.purdila@intel.com&gt;
Cc: Peter Jones &lt;pjones@redhat.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Scott Talbert &lt;swt@techie.net&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: linux-efi@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Link: https://lkml.kernel.org/r/20191002165904.8819-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
