linux-toradex.git/arch/x86/kernel/acpi/wakeup_64.S, branch v5.16-rc5

kasan: remove redundant config option

2021-04-16T23:10:36+00:00

CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
instrumentation, but we should only need one config, so that we remove
CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable.  see [1].

When enable KASAN stack instrumentation, then for gcc we could do no
prompt and default value y, and for clang prompt and default value n.

This patch fixes the following compilation warning:

  include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not defined, evaluates to 0 [-Wundef]

[akpm@linux-foundation.org: fix merge snafu]

Link: https://bugzilla.kernel.org/show_bug.cgi?id=210221 [1]
Link: https://lkml.kernel.org/r/20210226012531.29231-1-walter-zh.wu@mediatek.com
Fixes: d9b571c885a8 ("kasan: fix KASAN_STACK dependency for HW_TAGS")
Signed-off-by: Walter Wu 
Suggested-by: Dmitry Vyukov 
Reviewed-by: Nathan Chancellor 
Acked-by: Arnd Bergmann 
Reviewed-by: Andrey Konovalov 
Cc: Andrey Ryabinin 
Cc: Dmitry Vyukov 
Cc: Alexander Potapenko 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86/acpi: Support objtool validation in wakeup_64.S

2021-01-26T17:33:03+00:00

The OBJECT_FILES_NON_STANDARD annotation is used to tell objtool to
ignore a file.  File-level ignores won't work when validating vmlinux.o.

Instead, tell objtool to ignore do_suspend_lowlevel() directly with the
STACK_FRAME_NON_STANDARD annotation.

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Pavel Machek 
Signed-off-by: Josh Poimboeuf 
Link: https://lore.kernel.org/r/269eda576c53bc9ecc8167c211989111013a67aa.1611263462.git.jpoimboe@redhat.com

x86/acpi: Annotate indirect branch as safe

2021-01-26T17:33:03+00:00

This indirect jump is harmless; annotate it to keep objtool's retpoline
validation happy.

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Pavel Machek 
Signed-off-by: Josh Poimboeuf 
Link: https://lore.kernel.org/r/a7288e7043265d95c1a5d64f9fd751ead4854bdc.1611263462.git.jpoimboe@redhat.com

kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK

2020-12-22T20:55:08+00:00

There's a config option CONFIG_KASAN_STACK that has to be enabled for
KASAN to use stack instrumentation and perform validity checks for
stack variables.

There's no need to unpoison stack when CONFIG_KASAN_STACK is not enabled.
Only call kasan_unpoison_task_stack[_below]() when CONFIG_KASAN_STACK is
enabled.

Note, that CONFIG_KASAN_STACK is an option that is currently always
defined when CONFIG_KASAN is enabled, and therefore has to be tested
with #if instead of #ifdef.

Link: https://lkml.kernel.org/r/d09dd3f8abb388da397fd11598c5edeaa83fe559.1606162397.git.andreyknvl@google.com
Link: https://linux-review.googlesource.com/id/If8a891e9fe01ea543e00b576852685afec0887e3
Signed-off-by: Andrey Konovalov 
Reviewed-by: Marco Elver 
Acked-by: Catalin Marinas 
Reviewed-by: Dmitry Vyukov 
Tested-by: Vincenzo Frascino 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Branislav Rankov 
Cc: Evgenii Stepanov 
Cc: Kevin Brodsky 
Cc: Vasily Gorbik 
Cc: Will Deacon 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86/asm: Change all ENTRY+ENDPROC to SYM_FUNC_*

2019-10-18T09:58:33+00:00

These are all functions which are invoked from elsewhere, so annotate
them as global using the new SYM_FUNC_START and their ENDPROC's by
SYM_FUNC_END.

Make sure ENTRY/ENDPROC is not defined on X86_64, given these were the
last users.

Signed-off-by: Jiri Slaby 
Signed-off-by: Borislav Petkov 
Reviewed-by: Rafael J. Wysocki  [hibernate]
Reviewed-by: Boris Ostrovsky  [xen bits]
Acked-by: Herbert Xu  [crypto]
Cc: Allison Randal 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Andy Shevchenko 
Cc: Ard Biesheuvel 
Cc: Armijn Hemel 
Cc: Cao jin 
Cc: Darren Hart 
Cc: Dave Hansen 
Cc: "David S. Miller" 
Cc: Enrico Weigelt 
Cc: Greg Kroah-Hartman 
Cc: Herbert Xu 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jim Mattson 
Cc: Joerg Roedel 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: Kate Stewart 
Cc: "Kirill A. Shutemov" 
Cc: kvm ML 
Cc: Len Brown 
Cc: linux-arch@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-efi 
Cc: linux-efi@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: Mark Rutland 
Cc: Matt Fleming 
Cc: Paolo Bonzini 
Cc: Pavel Machek 
Cc: Peter Zijlstra 
Cc: platform-driver-x86@vger.kernel.org
Cc: "Radim Krčmář" 
Cc: Sean Christopherson 
Cc: Stefano Stabellini 
Cc: "Steven Rostedt (VMware)" 
Cc: Thomas Gleixner 
Cc: Vitaly Kuznetsov 
Cc: Wanpeng Li 
Cc: Wei Huang 
Cc: x86-ml 
Cc: xen-devel@lists.xenproject.org
Cc: Xiaoyao Li 
Link: https://lkml.kernel.org/r/20191011115108.12392-25-jslaby@suse.cz

x86/asm/suspend: Use SYM_DATA for data

2019-10-18T07:50:25+00:00

Some global data in the suspend code were marked as `ENTRY'. ENTRY was
intended for functions and shall be paired with ENDPROC. ENTRY also
aligns symbols to 16 bytes which creates unnecessary holes.

Note that:

* saved_magic (long) in wakeup_32 is still prepended by section's ALIGN
* saved_magic (quad) in wakeup_64 follows a bunch of quads which are
  aligned (but need not be aligned to 16)

Since historical markings are being dropped, make proper use of newly
added SYM_DATA in this code.

Signed-off-by: Jiri Slaby 
Signed-off-by: Borislav Petkov 
Acked-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Len Brown 
Cc: linux-arch@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20191011115108.12392-3-jslaby@suse.cz

x86/asm/suspend: Get rid of bogus_64_magic

2019-09-06T08:34:15+00:00

bogus_64_magic is only a dead-end loop. There is no need for an
out-of-order function (and unannotated local label), so just handle it
in-place and also store 0xbad-m-a-g-i-c to %rcx beforehand, in case
someone is inspecting registers.

Here a qemu+gdb example:

  Remote debugging using localhost:1235
  wakeup_long64 () at arch/x86/kernel/acpi/wakeup_64.S:26
  26              jmp 1b
  (gdb) info registers
  rax            0x123456789abcdef0       1311768467463790320
  rbx            0x0      0
  rcx            0xbad6d61676963  3286910041024867
  		 ^^^^^^^^^^^^^^^

 [ bp: Add the gdb example. ]

Signed-off-by: Jiri Slaby 
Signed-off-by: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Len Brown 
Cc: linux-pm@vger.kernel.org
Cc: Pavel Machek 
Cc: "Rafael J. Wysocki" 
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190906075550.23435-1-jslaby@suse.cz

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 430

2019-06-05T15:37:16+00:00

Based on 1 normalized pattern(s):

  distribute under gplv2

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 8 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Armijn Hemel 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190531190114.475576622@linutronix.de
Signed-off-by: Greg Kroah-Hartman

x86/asm/suspend: Drop ENTRY from local data

2019-01-30T15:07:10+00:00

ENTRY is intended for functions and shall be paired with ENDPROC. ENTRY
also aligns symbols which creates unnecessary holes between data.

So drop ENTRY from saved_eip in wakeup_32 and many saved_* in wakeup_64,
as these symbols are local only.

One could've used SYM_DATA_LOCAL for these symbols, but it was
discouraged earlier:

  https://lkml.kernel.org/r/20170427124310.GC23352@amd

Signed-off-by: Jiri Slaby 
Signed-off-by: Borislav Petkov 
Acked-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Len Brown 
Cc: linux-arch@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: Thomas Gleixner 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/20190130124711.12463-3-jslaby@suse.cz

x86/suspend: fix false positive KASAN warning on suspend/resume

2016-12-06T01:22:44+00:00

Resuming from a suspend operation is showing a KASAN false positive
warning:

  BUG: KASAN: stack-out-of-bounds in unwind_get_return_address+0x11d/0x130 at addr ffff8803867d7878
  Read of size 8 by task pm-suspend/7774
  page:ffffea000e19f5c0 count:0 mapcount:0 mapping:          (null) index:0x0
  flags: 0x2ffff0000000000()
  page dumped because: kasan: bad access detected
  CPU: 0 PID: 7774 Comm: pm-suspend Tainted: G    B           4.9.0-rc7+ #8
  Hardware name: Gigabyte Technology Co., Ltd. Z170X-UD5/Z170X-UD5-CF, BIOS F5 03/07/2016
  Call Trace:
    dump_stack+0x63/0x82
    kasan_report_error+0x4b4/0x4e0
    ? acpi_hw_read_port+0xd0/0x1ea
    ? kfree_const+0x22/0x30
    ? acpi_hw_validate_io_request+0x1a6/0x1a6
    __asan_report_load8_noabort+0x61/0x70
    ? unwind_get_return_address+0x11d/0x130
    unwind_get_return_address+0x11d/0x130
    ? unwind_next_frame+0x97/0xf0
    __save_stack_trace+0x92/0x100
    save_stack_trace+0x1b/0x20
    save_stack+0x46/0xd0
    ? save_stack_trace+0x1b/0x20
    ? save_stack+0x46/0xd0
    ? kasan_kmalloc+0xad/0xe0
    ? kasan_slab_alloc+0x12/0x20
    ? acpi_hw_read+0x2b6/0x3aa
    ? acpi_hw_validate_register+0x20b/0x20b
    ? acpi_hw_write_port+0x72/0xc7
    ? acpi_hw_write+0x11f/0x15f
    ? acpi_hw_read_multiple+0x19f/0x19f
    ? memcpy+0x45/0x50
    ? acpi_hw_write_port+0x72/0xc7
    ? acpi_hw_write+0x11f/0x15f
    ? acpi_hw_read_multiple+0x19f/0x19f
    ? kasan_unpoison_shadow+0x36/0x50
    kasan_kmalloc+0xad/0xe0
    kasan_slab_alloc+0x12/0x20
    kmem_cache_alloc_trace+0xbc/0x1e0
    ? acpi_get_sleep_type_data+0x9a/0x578
    acpi_get_sleep_type_data+0x9a/0x578
    acpi_hw_legacy_wake_prep+0x88/0x22c
    ? acpi_hw_legacy_sleep+0x3c7/0x3c7
    ? acpi_write_bit_register+0x28d/0x2d3
    ? acpi_read_bit_register+0x19b/0x19b
    acpi_hw_sleep_dispatch+0xb5/0xba
    acpi_leave_sleep_state_prep+0x17/0x19
    acpi_suspend_enter+0x154/0x1e0
    ? trace_suspend_resume+0xe8/0xe8
    suspend_devices_and_enter+0xb09/0xdb0
    ? printk+0xa8/0xd8
    ? arch_suspend_enable_irqs+0x20/0x20
    ? try_to_freeze_tasks+0x295/0x600
    pm_suspend+0x6c9/0x780
    ? finish_wait+0x1f0/0x1f0
    ? suspend_devices_and_enter+0xdb0/0xdb0
    state_store+0xa2/0x120
    ? kobj_attr_show+0x60/0x60
    kobj_attr_store+0x36/0x70
    sysfs_kf_write+0x131/0x200
    kernfs_fop_write+0x295/0x3f0
    __vfs_write+0xef/0x760
    ? handle_mm_fault+0x1346/0x35e0
    ? do_iter_readv_writev+0x660/0x660
    ? __pmd_alloc+0x310/0x310
    ? do_lock_file_wait+0x1e0/0x1e0
    ? apparmor_file_permission+0x18/0x20
    ? security_file_permission+0x73/0x1c0
    ? rw_verify_area+0xbd/0x2b0
    vfs_write+0x149/0x4a0
    SyS_write+0xd9/0x1c0
    ? SyS_read+0x1c0/0x1c0
    entry_SYSCALL_64_fastpath+0x1e/0xad
  Memory state around the buggy address:
   ffff8803867d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   ffff8803867d7780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  >ffff8803867d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4
                                                                  ^
   ffff8803867d7880: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
   ffff8803867d7900: 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00

KASAN instrumentation poisons the stack when entering a function and
unpoisons it when exiting the function.  However, in the suspend path,
some functions never return, so their stack never gets unpoisoned,
resulting in stale KASAN shadow data which can cause later false
positive warnings like the one above.

Reported-by: Scott Bauer 
Signed-off-by: Josh Poimboeuf 
Acked-by: Andrey Ryabinin 
Acked-by: Pavel Machek 
Signed-off-by: Rafael J. Wysocki