<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/firmware, branch v5.6.8</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>efi/x86: Ignore the memory attributes table on i386</title>
<updated>2020-04-17T14:13:21+00:00</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2020-03-08T08:08:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4eff1e8913867cd4d5f34357d97697d6db4a6f8a'/>
<id>4eff1e8913867cd4d5f34357d97697d6db4a6f8a</id>
<content type='text'>
[ Upstream commit dd09fad9d2caad2325a39b766ce9e79cfc690184 ]

Commit:

  3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures")

moved the call to efi_memattr_init() from ARM specific to the generic
EFI init code, in order to be able to apply the restricted permissions
described in that table on x86 as well.

We never enabled this feature fully on i386, and so mapping and
reserving this table is pointless. However, due to the early call to
memblock_reserve(), the memory bookkeeping gets confused to the point
where it produces the splat below when we try to map the memory later
on:

  ------------[ cut here ]------------
  ioremap on RAM at 0x3f251000 - 0x3fa1afff
  WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:166 __ioremap_caller ...
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0 #48
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
  EIP: __ioremap_caller.constprop.0+0x249/0x260
  Code: 90 0f b7 05 4e 38 40 de 09 45 e0 e9 09 ff ff ff 90 8d 45 ec c6 05 ...
  EAX: 00000029 EBX: 00000000 ECX: de59c228 EDX: 00000001
  ESI: 3f250fff EDI: 00000000 EBP: de3edf20 ESP: de3edee0
  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200296
  CR0: 80050033 CR2: ffd17000 CR3: 1e58c000 CR4: 00040690
  Call Trace:
   ioremap_cache+0xd/0x10
   ? old_map_region+0x72/0x9d
   old_map_region+0x72/0x9d
   efi_map_region+0x8/0xa
   efi_enter_virtual_mode+0x260/0x43b
   start_kernel+0x329/0x3aa
   i386_start_kernel+0xa7/0xab
   startup_32_smp+0x164/0x168
  ---[ end trace e15ccf6b9f356833 ]---

Let's work around this by disregarding the memory attributes table
altogether on i386, which does not result in a loss of functionality
or protection, given that we never consumed the contents.

Fixes: 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE ... ")
Tested-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20200304165917.5893-1-ardb@kernel.org
Link: https://lore.kernel.org/r/20200308080859.21568-21-ardb@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit dd09fad9d2caad2325a39b766ce9e79cfc690184 ]

Commit:

  3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures")

moved the call to efi_memattr_init() from ARM specific to the generic
EFI init code, in order to be able to apply the restricted permissions
described in that table on x86 as well.

We never enabled this feature fully on i386, and so mapping and
reserving this table is pointless. However, due to the early call to
memblock_reserve(), the memory bookkeeping gets confused to the point
where it produces the splat below when we try to map the memory later
on:

  ------------[ cut here ]------------
  ioremap on RAM at 0x3f251000 - 0x3fa1afff
  WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:166 __ioremap_caller ...
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0 #48
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
  EIP: __ioremap_caller.constprop.0+0x249/0x260
  Code: 90 0f b7 05 4e 38 40 de 09 45 e0 e9 09 ff ff ff 90 8d 45 ec c6 05 ...
  EAX: 00000029 EBX: 00000000 ECX: de59c228 EDX: 00000001
  ESI: 3f250fff EDI: 00000000 EBP: de3edf20 ESP: de3edee0
  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200296
  CR0: 80050033 CR2: ffd17000 CR3: 1e58c000 CR4: 00040690
  Call Trace:
   ioremap_cache+0xd/0x10
   ? old_map_region+0x72/0x9d
   old_map_region+0x72/0x9d
   efi_map_region+0x8/0xa
   efi_enter_virtual_mode+0x260/0x43b
   start_kernel+0x329/0x3aa
   i386_start_kernel+0xa7/0xab
   startup_32_smp+0x164/0x168
  ---[ end trace e15ccf6b9f356833 ]---

Let's work around this by disregarding the memory attributes table
altogether on i386, which does not result in a loss of functionality
or protection, given that we never consumed the contents.

Fixes: 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE ... ")
Tested-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Link: https://lore.kernel.org/r/20200304165917.5893-1-ardb@kernel.org
Link: https://lore.kernel.org/r/20200308080859.21568-21-ardb@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: arm_sdei: fix double-lock on hibernate with shared events</title>
<updated>2020-04-17T14:13:17+00:00</updated>
<author>
<name>James Morse</name>
<email>james.morse@arm.com</email>
</author>
<published>2020-02-21T16:35:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6c8075cd066e47bd7b19166ddd07186abebbd482'/>
<id>6c8075cd066e47bd7b19166ddd07186abebbd482</id>
<content type='text'>
[ Upstream commit 6ded0b61cf638bf9f8efe60ab8ba23db60ea9763 ]

SDEI has private events that must be registered on each CPU. When
CPUs come and go they must re-register and re-enable their private
events. Each event has flags to indicate whether this should happen
to protect against an event being registered on a CPU coming online,
while all the others are unregistering the event.

These flags are protected by the sdei_list_lock spinlock, because
the cpuhp callbacks can't take the mutex.

Hibernate needs to unregister all events, but keep the in-memory
re-register and re-enable as they are. sdei_unregister_shared()
takes the spinlock to walk the list, then calls _sdei_event_unregister()
on each shared event. _sdei_event_unregister() tries to take the
same spinlock to update re-register and re-enable. This doesn't go
so well.

Push the re-register and re-enable updates out to their callers.
sdei_unregister_shared() doesn't want these values updated, so
doesn't need to do anything.

This also fixes shared events getting lost over hibernate as this
path made them look unregistered.

Fixes: da351827240e ("firmware: arm_sdei: Add support for CPU and system power states")
Reported-by: Liguang Zhang &lt;zhangliguang@linux.alibaba.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 6ded0b61cf638bf9f8efe60ab8ba23db60ea9763 ]

SDEI has private events that must be registered on each CPU. When
CPUs come and go they must re-register and re-enable their private
events. Each event has flags to indicate whether this should happen
to protect against an event being registered on a CPU coming online,
while all the others are unregistering the event.

These flags are protected by the sdei_list_lock spinlock, because
the cpuhp callbacks can't take the mutex.

Hibernate needs to unregister all events, but keep the in-memory
re-register and re-enable as they are. sdei_unregister_shared()
takes the spinlock to walk the list, then calls _sdei_event_unregister()
on each shared event. _sdei_event_unregister() tries to take the
same spinlock to update re-register and re-enable. This doesn't go
so well.

Push the re-register and re-enable updates out to their callers.
sdei_unregister_shared() doesn't want these values updated, so
doesn't need to do anything.

This also fixes shared events getting lost over hibernate as this
path made them look unregistered.

Fixes: da351827240e ("firmware: arm_sdei: Add support for CPU and system power states")
Reported-by: Liguang Zhang &lt;zhangliguang@linux.alibaba.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'efi-urgent-2020-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2020-03-15T19:42:03+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2020-03-15T19:42:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b67775e124572a7028e930c306ed68cc2f90b29b'/>
<id>b67775e124572a7028e930c306ed68cc2f90b29b</id>
<content type='text'>
Pull EFI fixes from Thomas Gleixner:
 "Two EFI fixes:

   - Prevent a race and buffer overflow in the sysfs efivars interface
     which causes kernel memory corruption.

   - Add the missing NULL pointer checks in efivar_store_raw()"

* tag 'efi-urgent-2020-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi: Add a sanity check to efivar_store_raw()
  efi: Fix a race and a buffer overflow while reading efivars via sysfs
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull EFI fixes from Thomas Gleixner:
 "Two EFI fixes:

   - Prevent a race and buffer overflow in the sysfs efivars interface
     which causes kernel memory corruption.

   - Add the missing NULL pointer checks in efivar_store_raw()"

* tag 'efi-urgent-2020-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi: Add a sanity check to efivar_store_raw()
  efi: Fix a race and a buffer overflow while reading efivars via sysfs
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc</title>
<updated>2020-03-09T00:36:22+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2020-03-09T00:36:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=62790268e4eda1deaac93264af69ac95b4afdf96'/>
<id>62790268e4eda1deaac93264af69ac95b4afdf96</id>
<content type='text'>
Pull ARM SoC fixes from Olof Johansson:
 "We've been accruing these for a couple of weeks, so the batch is a bit
  bigger than usual.

  Largest delta is due to a led-bl driver that is added -- there was a
  miscommunication before the merge window and the driver didn't make it
  in. Due to this, the platforms needing it regressed. At this point, it
  seemed easier to add the new driver than unwind the changes.

  Besides that, there are a handful of various fixes:

   - AMD tee memory leak fix

   - A handful of fixlets for i.MX SCU communication

   - A few maintainers woke up and realized DEBUG_FS had been missing
     for a while, so a few updates of that.

  ... and the usual collection of smaller fixes to various platforms"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (37 commits)
  ARM: socfpga_defconfig: Add back DEBUG_FS
  arm64: dts: socfpga: agilex: Fix gmac compatible
  ARM: bcm2835_defconfig: Explicitly restore CONFIG_DEBUG_FS
  arm64: dts: meson: fix gxm-khadas-vim2 wifi
  arm64: dts: meson-sm1-sei610: add missing interrupt-names
  ARM: meson: Drop unneeded select of COMMON_CLK
  ARM: dts: bcm2711: Add pcie0 alias
  ARM: dts: bcm283x: Add missing properties to the PWR LED
  tee: amdtee: fix memory leak in amdtee_open_session()
  ARM: OMAP2+: Fix compile if CONFIG_HAVE_ARM_SMCCC is not set
  arm: dts: dra76x: Fix mmc3 max-frequency
  ARM: dts: dra7: Add "dma-ranges" property to PCIe RC DT nodes
  bus: ti-sysc: Fix 1-wire reset quirk
  ARM: dts: r8a7779: Remove deprecated "renesas, rcar-sata" compatible value
  soc: imx-scu: Align imx sc msg structs to 4
  firmware: imx: Align imx_sc_msg_req_cpu_start to 4
  firmware: imx: scu-pd: Align imx sc msg structs to 4
  firmware: imx: misc: Align imx sc msg structs to 4
  firmware: imx: scu: Ensure sequential TX
  ARM: dts: imx7-colibri: Fix frequency for sd/mmc
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ARM SoC fixes from Olof Johansson:
 "We've been accruing these for a couple of weeks, so the batch is a bit
  bigger than usual.

  Largest delta is due to a led-bl driver that is added -- there was a
  miscommunication before the merge window and the driver didn't make it
  in. Due to this, the platforms needing it regressed. At this point, it
  seemed easier to add the new driver than unwind the changes.

  Besides that, there are a handful of various fixes:

   - AMD tee memory leak fix

   - A handful of fixlets for i.MX SCU communication

   - A few maintainers woke up and realized DEBUG_FS had been missing
     for a while, so a few updates of that.

  ... and the usual collection of smaller fixes to various platforms"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (37 commits)
  ARM: socfpga_defconfig: Add back DEBUG_FS
  arm64: dts: socfpga: agilex: Fix gmac compatible
  ARM: bcm2835_defconfig: Explicitly restore CONFIG_DEBUG_FS
  arm64: dts: meson: fix gxm-khadas-vim2 wifi
  arm64: dts: meson-sm1-sei610: add missing interrupt-names
  ARM: meson: Drop unneeded select of COMMON_CLK
  ARM: dts: bcm2711: Add pcie0 alias
  ARM: dts: bcm283x: Add missing properties to the PWR LED
  tee: amdtee: fix memory leak in amdtee_open_session()
  ARM: OMAP2+: Fix compile if CONFIG_HAVE_ARM_SMCCC is not set
  arm: dts: dra76x: Fix mmc3 max-frequency
  ARM: dts: dra7: Add "dma-ranges" property to PCIe RC DT nodes
  bus: ti-sysc: Fix 1-wire reset quirk
  ARM: dts: r8a7779: Remove deprecated "renesas, rcar-sata" compatible value
  soc: imx-scu: Align imx sc msg structs to 4
  firmware: imx: Align imx_sc_msg_req_cpu_start to 4
  firmware: imx: scu-pd: Align imx sc msg structs to 4
  firmware: imx: misc: Align imx sc msg structs to 4
  firmware: imx: scu: Ensure sequential TX
  ARM: dts: imx7-colibri: Fix frequency for sd/mmc
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Add a sanity check to efivar_store_raw()</title>
<updated>2020-03-08T08:56:48+00:00</updated>
<author>
<name>Vladis Dronov</name>
<email>vdronov@redhat.com</email>
</author>
<published>2020-03-08T08:08:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d6c066fda90d578aacdf19771a027ed484a79825'/>
<id>d6c066fda90d578aacdf19771a027ed484a79825</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Fix a race and a buffer overflow while reading efivars via sysfs</title>
<updated>2020-03-08T08:56:34+00:00</updated>
<author>
<name>Vladis Dronov</name>
<email>vdronov@redhat.com</email>
</author>
<published>2020-03-08T08:08:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=286d3250c9d6437340203fb64938bea344729a0e'/>
<id>286d3250c9d6437340203fb64938bea344729a0e</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: READ_ONCE rng seed size before munmap</title>
<updated>2020-02-26T14:31:43+00:00</updated>
<author>
<name>Jason A. Donenfeld</name>
<email>Jason@zx2c4.com</email>
</author>
<published>2020-02-21T08:48:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=be36f9e7517e17810ec369626a128d7948942259'/>
<id>be36f9e7517e17810ec369626a128d7948942259</id>
<content type='text'>
This function is consistent with using size instead of seed-&gt;size
(except for one place that this patch fixes), but it reads seed-&gt;size
without using READ_ONCE, which means the compiler might still do
something unwanted. So, this commit simply adds the READ_ONCE
wrapper.

Fixes: 636259880a7e ("efi: Add support for seeding the RNG from a UEFI ...")
Signed-off-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: linux-efi@vger.kernel.org
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/r/20200217123354.21140-1-Jason@zx2c4.com
Link: https://lore.kernel.org/r/20200221084849.26878-5-ardb@kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This function is consistent with using size instead of seed-&gt;size
(except for one place that this patch fixes), but it reads seed-&gt;size
without using READ_ONCE, which means the compiler might still do
something unwanted. So, this commit simply adds the READ_ONCE
wrapper.

Fixes: 636259880a7e ("efi: Add support for seeding the RNG from a UEFI ...")
Signed-off-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: linux-efi@vger.kernel.org
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/r/20200217123354.21140-1-Jason@zx2c4.com
Link: https://lore.kernel.org/r/20200221084849.26878-5-ardb@kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: imx: Align imx_sc_msg_req_cpu_start to 4</title>
<updated>2020-02-24T07:27:48+00:00</updated>
<author>
<name>Leonard Crestez</name>
<email>leonard.crestez@nxp.com</email>
</author>
<published>2020-02-20T16:29:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f5bfeff44612d304deb100065a9f712309dc2783'/>
<id>f5bfeff44612d304deb100065a9f712309dc2783</id>
<content type='text'>
The imx SC api strongly assumes that messages are composed out of
4-bytes words but some of our message structs have odd sizeofs.

This produces many oopses with CONFIG_KASAN=y.

Fix by marking with __aligned(4).

Fixes: d90bf296ae18 ("firmware: imx: Add support to start/stop a CPU")
Signed-off-by: Leonard Crestez &lt;leonard.crestez@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The imx SC api strongly assumes that messages are composed out of
4-bytes words but some of our message structs have odd sizeofs.

This produces many oopses with CONFIG_KASAN=y.

Fix by marking with __aligned(4).

Fixes: d90bf296ae18 ("firmware: imx: Add support to start/stop a CPU")
Signed-off-by: Leonard Crestez &lt;leonard.crestez@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: imx: scu-pd: Align imx sc msg structs to 4</title>
<updated>2020-02-24T07:26:55+00:00</updated>
<author>
<name>Leonard Crestez</name>
<email>leonard.crestez@nxp.com</email>
</author>
<published>2020-02-20T16:29:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7c1a1c814ccc858633c761951c2546041202b24e'/>
<id>7c1a1c814ccc858633c761951c2546041202b24e</id>
<content type='text'>
The imx SC api strongly assumes that messages are composed out of
4-bytes words but some of our message structs have odd sizeofs.

This produces many oopses with CONFIG_KASAN=y.

Fix by marking with __aligned(4).

Fixes: c800cd7824bd ("firmware: imx: add SCU power domain driver")
Signed-off-by: Leonard Crestez &lt;leonard.crestez@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The imx SC api strongly assumes that messages are composed out of
4-bytes words but some of our message structs have odd sizeofs.

This produces many oopses with CONFIG_KASAN=y.

Fix by marking with __aligned(4).

Fixes: c800cd7824bd ("firmware: imx: add SCU power domain driver")
Signed-off-by: Leonard Crestez &lt;leonard.crestez@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: imx: misc: Align imx sc msg structs to 4</title>
<updated>2020-02-24T07:26:44+00:00</updated>
<author>
<name>Leonard Crestez</name>
<email>leonard.crestez@nxp.com</email>
</author>
<published>2020-02-20T16:29:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1e6a4eba693ac72e6f91b4252458c933110e5f4c'/>
<id>1e6a4eba693ac72e6f91b4252458c933110e5f4c</id>
<content type='text'>
The imx SC api strongly assumes that messages are composed out of
4-bytes words but some of our message structs have odd sizeofs.

This produces many oopses with CONFIG_KASAN=y:

    BUG: KASAN: stack-out-of-bounds in imx_mu_send_data+0x108/0x1f0

It shouldn't cause an issues in normal use because these structs are
always allocated on the stack.

Fixes: 15e1f2bc8b3b ("firmware: imx: add misc svc support")
Signed-off-by: Leonard Crestez &lt;leonard.crestez@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The imx SC api strongly assumes that messages are composed out of
4-bytes words but some of our message structs have odd sizeofs.

This produces many oopses with CONFIG_KASAN=y:

    BUG: KASAN: stack-out-of-bounds in imx_mu_send_data+0x108/0x1f0

It shouldn't cause an issues in normal use because these structs are
always allocated on the stack.

Fixes: 15e1f2bc8b3b ("firmware: imx: add misc svc support")
Signed-off-by: Leonard Crestez &lt;leonard.crestez@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
