Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 3月, 2016 1 次提交
  3. 14 3月, 2016 1 次提交
  5. 16 2月, 2016 1 次提交
    • M
      efi: Add pstore variables to the deletion whitelist · e246eb56
      由 Matt Fleming 提交于 
      Laszlo explains why this is a good idea,

 'This is because the pstore filesystem can be backed by UEFI variables,
  and (for example) a crash might dump the last kilobytes of the dmesg
  into a number of pstore entries, each entry backed by a separate UEFI
  variable in the above GUID namespace, and with a variable name
  according to the above pattern.

  Please see "drivers/firmware/efi/efi-pstore.c".

  While this patch series will not prevent the user from deleting those
  UEFI variables via the pstore filesystem (i.e., deleting a pstore fs
  entry will continue to delete the backing UEFI variable), I think it
  would be nice to preserve the possibility for the sysadmin to delete
  Linux-created UEFI variables that carry portions of the crash log,
  *without* having to mount the pstore filesystem.'

There's also no chance of causing machines to become bricked by
deleting these variables, which is the whole purpose of excluding
things from the whitelist.

Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so
that we don't have to update the string in the future if new variable
name formats are created for crash dump variables.
Reported-by: NLaszlo Ersek <lersek@redhat.com>
Acked-by: NPeter Jones <pjones@redhat.com>
Tested-by: NPeter Jones <pjones@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      e246eb56
  7. 11 2月, 2016 2 次提交
  9. 10 2月, 2016 2 次提交
  11. 21 1月, 2016 2 次提交
  13. 16 1月, 2016 4 次提交
  15. 14 1月, 2016 1 次提交
  17. 08 1月, 2016 1 次提交
  19. 06 1月, 2016 1 次提交
  21. 05 1月, 2016 2 次提交
  23. 14 12月, 2015 2 次提交
  25. 10 12月, 2015 2 次提交
  27. 08 12月, 2015 1 次提交
  29. 03 11月, 2015 1 次提交
  31. 02 11月, 2015 1 次提交
  33. 31 10月, 2015 1 次提交
  35. 28 10月, 2015 2 次提交
  37. 24 10月, 2015 1 次提交
    • L
      drivers: psci: make PSCI 1.0 functions initialization version dependent · 79b04beb
      由 Lorenzo Pieralisi 提交于 
      The PSCI specifications [1] and the SMC calling convention mandate
that unimplemented functions ids must return NOT_SUPPORTED (0xffffffff)
if a function id is called but it is not implemented.

Consequently, PSCI 1.0 function ids that require the 1.0 PSCI_FEATURES
call to be initialized:

CPU_SUSPEND (psci_init_cpu_suspend())
SYSTEM_SUSPEND (psci_init_system_suspend())

call the PSCI_FEATURES function id independently of the detected
PSCI firmware version, since, if the PSCI_FEATURES function id is not
implemented, it must return NOT_SUPPORTED according to the PSCI
specifications, causing the initialization functions to fail as expected.

Some existing PSCI implementations (ie Qemu PSCI emulation), do not
comply with the SMC calling convention and fail if function ids that are
not implemented are called from the OS, causing boot failures.

To solve this issue, this patch adds code that checks the PSCI firmware
version before calling PSCI 1.0 initialization functions so that the
OS makes sure that it is calling 1.0 functions only if the firmware
version detected is 1.0 or greater, therefore avoiding PSCI calls
that are bound to fail and might cause system boot failures owing
to non-compliant PSCI firmware implementations.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdfSigned-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Tested-by: NKevin Hilman <khilman@kernel.org>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      79b04beb
  39. 15 10月, 2015 3 次提交
  41. 13 10月, 2015 1 次提交
    • A
      arm64: add KASAN support · 39d114dd
      由 Andrey Ryabinin 提交于 
      This patch adds arch specific code for kernel address sanitizer
(see Documentation/kasan.txt).

1/8 of kernel addresses reserved for shadow memory. There was no
big enough hole for this, so virtual addresses for shadow were
stolen from vmalloc area.

At early boot stage the whole shadow region populated with just
one physical page (kasan_zero_page). Later, this page reused
as readonly zero shadow for some memory that KASan currently
don't track (vmalloc).
After mapping the physical memory, pages for shadow memory are
allocated and mapped.

Functions like memset/memmove/memcpy do a lot of memory accesses.
If bad pointer passed to one of these function it is important
to catch this. Compiler's instrumentation cannot do this since
these functions are written in assembly.
KASan replaces memory functions with manually instrumented variants.
Original functions declared as weak symbols so strong definitions
in mm/kasan/kasan.c could replace them. Original functions have aliases
with '__' prefix in name, so we could call non-instrumented variant
if needed.
Some files built without kasan instrumentation (e.g. mm/slub.c).
Original mem* function replaced (via #define) with prefixed variants
to disable memory access checks for such files.
Signed-off-by: NAndrey Ryabinin <ryabinin.a.a@gmail.com>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      39d114dd
  43. 12 10月, 2015 7 次提交