linux-stable.git/drivers/firmware, branch v5.10.7

mm/gup: prevent gup_fast from racing with COW during fork

2020-12-30T10:53:54+00:00

[ Upstream commit 57efa1fe5957694fa541c9062de0a127f0b9acb0 ]

Since commit 70e806e4e645 ("mm: Do early cow for pinned pages during
fork() for ptes") pages under a FOLL_PIN will not be write protected
during COW for fork.  This means that pages returned from
pin_user_pages(FOLL_WRITE) should not become write protected while the pin
is active.

However, there is a small race where get_user_pages_fast(FOLL_PIN) can
establish a FOLL_PIN at the same time copy_present_page() is write
protecting it:

        CPU 0                             CPU 1
   get_user_pages_fast()
    internal_get_user_pages_fast()
                                       copy_page_range()
                                         pte_alloc_map_lock()
                                           copy_present_page()
                                             atomic_read(has_pinned) == 0
					     page_maybe_dma_pinned() == false
     atomic_set(has_pinned, 1);
     gup_pgd_range()
      gup_pte_range()
       pte_t pte = gup_get_pte(ptep)
       pte_access_permitted(pte)
       try_grab_compound_head()
                                             pte = pte_wrprotect(pte)
	                                     set_pte_at();
                                         pte_unmap_unlock()
      // GUP now returns with a write protected page

The first attempt to resolve this by using the write protect caused
problems (and was missing a barrrier), see commit f3c64eda3e50 ("mm: avoid
early COW write protect games during fork()")

Instead wrap copy_p4d_range() with the write side of a seqcount and check
the read side around gup_pgd_range().  If there is a collision then
get_user_pages_fast() fails and falls back to slow GUP.

Slow GUP is safe against this race because copy_page_range() is only
called while holding the exclusive side of the mmap_lock on the src
mm_struct.

[akpm@linux-foundation.org: coding style fixes]
  Link: https://lore.kernel.org/r/CAHk-=wi=iCnYCARbPGjkVJu9eyYeZ13N64tZYLdOB8CP5Q_PLw@mail.gmail.com

Link: https://lkml.kernel.org/r/2-v4-908497cf359a+4782-gup_fork_jgg@nvidia.com
Fixes: f3c64eda3e50 ("mm: avoid early COW write protect games during fork()")
Signed-off-by: Jason Gunthorpe 
Suggested-by: Linus Torvalds 
Reviewed-by: John Hubbard 
Reviewed-by: Jan Kara 
Reviewed-by: Peter Xu 
Acked-by: "Ahmed S. Darwish" 	[seqcount_t parts]
Cc: Andrea Arcangeli 
Cc: "Aneesh Kumar K.V" 
Cc: Christoph Hellwig 
Cc: Hugh Dickins 
Cc: Jann Horn 
Cc: Kirill Shutemov 
Cc: Kirill Tkhai 
Cc: Leon Romanovsky 
Cc: Michal Hocko 
Cc: Oleg Nesterov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

firmware: arm_scmi: Fix missing destroy_workqueue()

2020-12-30T10:53:09+00:00

[ Upstream commit 6bbdb46c4b1bd57839c9c0a110bd81b0be0a4046 ]

destroy_workqueue is required before the return from scmi_notification_init
in case devm_kcalloc fails to allocate registered_protocols. Fix this by
simply moving registered_protocols allocation before alloc_workqueue.

Link: https://lore.kernel.org/r/20201110074221.41235-1-miaoqinglang@huawei.com
Fixes: bd31b249692e ("firmware: arm_scmi: Add notification dispatch and delivery")
Suggested-by: Cristian Marussi 
Reviewed-by: Cristian Marussi 
Signed-off-by: Qinglang Miao 
Signed-off-by: Sudeep Holla 
Signed-off-by: Sasha Levin

firmware: tegra: fix strncpy()/strncat() confusion

2020-12-30T10:53:07+00:00

[ Upstream commit 9294996f0be40e9da818ed891c82397ab63c00d0 ]

The way that bpmp_populate_debugfs_inband() uses strncpy()
and strncat() makes no sense since the size argument for
the first is insufficient to contain the trailing '/'
and the second passes the length of the input rather than
the output, which triggers a warning:

In function 'strncat',
    inlined from 'bpmp_populate_debugfs_inband' at ../drivers/firmware/tegra/bpmp-debugfs.c:422:4:
include/linux/string.h:289:30: warning: '__builtin_strncat' specified bound depends on the length of the source argument [-Wstringop-overflow=]
  289 | #define __underlying_strncat __builtin_strncat
      |                              ^
include/linux/string.h:367:10: note: in expansion of macro '__underlying_strncat'
  367 |   return __underlying_strncat(p, q, count);
      |          ^~~~~~~~~~~~~~~~~~~~
drivers/firmware/tegra/bpmp-debugfs.c: In function 'bpmp_populate_debugfs_inband':
include/linux/string.h:288:29: note: length computed here
  288 | #define __underlying_strlen __builtin_strlen
      |                             ^
include/linux/string.h:321:10: note: in expansion of macro '__underlying_strlen'
  321 |   return __underlying_strlen(p);

Simplify this to use an snprintf() instead.

Fixes: 5e37b9c137ee ("firmware: tegra: Add support for in-band debug")
Signed-off-by: Arnd Bergmann 
Acked-by: Jon Hunter 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

firmware: xilinx: Mark pm_api_features_map with static keyword

2020-12-09T22:00:22+00:00

Fix the following sparse warning:

drivers/firmware/xilinx/zynqmp.c:32:1: warning: symbol 'pm_api_features_map' was not declared. Should it be static?

Signed-off-by: Zou Wei 
Link: https://lore.kernel.org/r/1606823513-121578-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Michal Simek 
Signed-off-by: Arnd Bergmann

Merge tag 'efi-urgent-for-v5.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2020-11-29T18:18:53+00:00

Pull EFI fixes from Borislav Petkov:
 "More EFI fixes forwarded from Ard Biesheuvel:

   - revert efivarfs kmemleak fix again - it was a false positive

   - make CONFIG_EFI_EARLYCON depend on CONFIG_EFI explicitly so it does
     not pull in other dependencies unnecessarily if CONFIG_EFI is not
     set

   - defer attempts to load SSDT overrides from EFI vars until after the
     efivar layer is up"

* tag 'efi-urgent-for-v5.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi: EFI_EARLYCON should depend on EFI
  efivarfs: revert "fix memory leak in efivarfs_create()"
  efi/efivars: Set generic ops before loading SSDT

efi: EFI_EARLYCON should depend on EFI

2020-11-25T15:55:02+00:00

CONFIG_EFI_EARLYCON defaults to yes, and thus is enabled on systems that
do not support EFI, or do not have EFI support enabled, but do satisfy
the symbol's other dependencies.

While drivers/firmware/efi/ won't be entered during the build phase if
CONFIG_EFI=n, and drivers/firmware/efi/earlycon.c itself thus won't be
built, enabling EFI_EARLYCON does force-enable CONFIG_FONT_SUPPORT and
CONFIG_ARCH_USE_MEMREMAP_PROT, and CONFIG_FONT_8x16, which is
undesirable.

Fix this by making CONFIG_EFI_EARLYCON depend on CONFIG_EFI.

This reduces kernel size on headless systems by more than 4 KiB.

Fixes: 69c1f396f25b805a ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation")
Signed-off-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/20201124191646.3559757-1-geert@linux-m68k.org
Reviewed-by: Damien Le Moal 
Signed-off-by: Ard Biesheuvel

efi/efivars: Set generic ops before loading SSDT

2020-11-25T15:55:02+00:00

Efivars allows for overriding of SSDT tables, however starting with
commit

  bf67fad19e493b ("efi: Use more granular check for availability for variable services")

this use case is broken. When loading SSDT generic ops should be set
first, however mentioned commit reversed order of operations. Fix this
by restoring original order of operations.

Fixes: bf67fad19e493b ("efi: Use more granular check for availability for variable services")
Signed-off-by: Amadeusz Sławiński 
Link: https://lore.kernel.org/r/20201123172817.124146-1-amadeuszx.slawinski@linux.intel.com
Tested-by: Cezary Rojewski 
Signed-off-by: Ard Biesheuvel

firmware: xilinx: Use hash-table for api feature check

2020-11-24T14:13:54+00:00

Currently array of fix length PM_API_MAX is used to cache
the pm_api version (valid or invalid). However ATF based
PM APIs values are much higher then PM_API_MAX.
So to include ATF based PM APIs also, use hash-table to
store the pm_api version status.

Signed-off-by: Amit Sunil Dhamne 
Reported-by: Arnd Bergmann 
Signed-off-by: Ravi Patel 
Signed-off-by: Rajan Vaja 
Reviewed-by: Arnd Bergmann 
Tested-by: Michal Simek 
Fixes: f3217d6f2f7a ("firmware: xilinx: fix out-of-bounds access")
Cc: stable 
Link: https://lore.kernel.org/r/1606197161-25976-1-git-send-email-rajan.vaja@xilinx.com
Signed-off-by: Michal Simek

firmware: xilinx: Fix SD DLL node reset issue

2020-11-24T14:09:08+00:00

Fix the SD DLL node reset issue where incorrect node is being referenced
instead of SD DLL node.

Fixes: 426c8d85df7a ("firmware: xilinx: Use APIs instead of IOCTLs")

Signed-off-by: Manish Narani 
Link: https://lore.kernel.org/r/1605534744-15649-1-git-send-email-manish.narani@xilinx.com
Signed-off-by: Michal Simek

firmware: xilinx: fix out-of-bounds access

2020-11-09T17:35:35+00:00

The zynqmp_pm_set_suspend_mode() and zynqmp_pm_get_trustzone_version()
functions pass values as api_id into zynqmp_pm_invoke_fn
that are beyond PM_API_MAX, resulting in an out-of-bounds access:

drivers/firmware/xilinx/zynqmp.c: In function 'zynqmp_pm_set_suspend_mode':
drivers/firmware/xilinx/zynqmp.c:150:24: warning: array subscript 2562 is above array bounds of 'u32[64]' {aka 'unsigned int[64]'} [-Warray-bounds]
  150 |  if (zynqmp_pm_features[api_id] != PM_FEATURE_UNCHECKED)
      |      ~~~~~~~~~~~~~~~~~~^~~~~~~~
drivers/firmware/xilinx/zynqmp.c:28:12: note: while referencing 'zynqmp_pm_features'
   28 | static u32 zynqmp_pm_features[PM_API_MAX];
      |            ^~~~~~~~~~~~~~~~~~

Replace the resulting undefined behavior with an error return.
This may break some things that happen to work at the moment
but seems better than randomly overwriting kernel data.

I assume we need additional fixes for the two functions that now
return an error.

Fixes: 76582671eb5d ("firmware: xilinx: Add Zynqmp firmware driver")
Fixes: e178df31cf41 ("firmware: xilinx: Implement ZynqMP power management APIs")
Signed-off-by: Arnd Bergmann 
Link: https://lore.kernel.org/r/20201026155449.3703142-1-arnd@kernel.org
Cc: stable 
Signed-off-by: Greg Kroah-Hartman