Skip to content

GitLab

Switch branch/tag
  1. 19 Apr, 2022 1 commit
  3. 15 Mar, 2022 7 commits
  5. 13 Dec, 2021 1 commit
    • Eric W. Biederman's avatar
      exit: Add and use make_task_dead. · 0e25498f
      Eric W. Biederman authored 
      
There are two big uses of do_exit.  The first is it's design use to be
the guts of the exit(2) system call.  The second use is to terminate
a task after something catastrophic has happened like a NULL pointer
in kernel code.

Add a function make_task_dead that is initialy exactly the same as
do_exit to cover the cases where do_exit is called to handle
catastrophic failure.  In time this can probably be reduced to just a
light wrapper around do_task_dead. For now keep it exactly the same so
that there will be no behavioral differences introducing this new
concept.

Replace all of the uses of do_exit that use it for catastraphic
task cleanup with make_task_dead to make it clear what the code
is doing.

As part of this rename rewind_stack_do_exit
rewind_stack_and_make_dead.
Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      0e25498f
  7. 11 Dec, 2021 1 commit
  9. 08 Dec, 2021 1 commit
  11. 03 Dec, 2021 3 commits
  13. 21 Jun, 2021 1 commit
  15. 20 May, 2021 1 commit
    • H. Peter Anvin (Intel)'s avatar
      x86/entry/64: Sign-extend system calls on entry to int · 05954948
      H. Peter Anvin (Intel) authored 
      
Right now, *some* code will treat e.g. 0x0000000100000001 as a system
call and some will not. Some of the code, notably in ptrace, will
treat 0x000000018000000 as a system call and some will not. Finally,
right now, e.g. 335 for x86-64 will force the exit code to be set to
-ENOSYS even if poked by ptrace, but 548 will not, because there is an
observable difference between an out of range system call and a system
call number that falls outside the range of the table.

This is visible to the user: for example, the syscall_numbering_64
test fails if run under strace, because as strace uses ptrace, it ends
up clobbering the upper half of the 64-bit system call number.

The architecture independent code all assumes that a system call is "int"
that the value -1 specifically and not just any negative value is used for
a non-system call. This is the case on x86 as well when arch-independent
code is involved. The arch-independent API is defined/documented (but not
*implemented*!) in <asm-generic/syscall.h>.

This is an ABI change, but is in fact a revert to the original x86-64
ABI. The original assembly entry code would zero-extend the system call
number;

Use sign extend to be explicit that this is treated as a signed number
(although in practice it makes no difference, of course) and to avoid
people getting the idea of "optimizing" it, as has happened on at least
two(!) separate occasions.

Do not store the extended value into regs->orig_ax, however: on x86-64, the
ABI is that the callee is responsible for extending parameters, so only
examining the lower 32 bits is fully consistent with any "int" argument to
any system call, e.g. regs->di for write(2). The full value of %rax on
entry to the kernel is thus still available.

[ tglx: Add a comment to the ASM code ]
Signed-off-by: default avatarH. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210518191303.4135296-5-hpa@zytor.com
      05954948
  17. 12 May, 2021 1 commit
  19. 21 Mar, 2021 1 commit
    • Ingo Molnar's avatar
      x86: Fix various typos in comments, take #2 · 163b0991
      Ingo Molnar authored 
      
Fix another ~42 single-word typos in arch/x86/ code comments,
missed a few in the first pass, in particular in .S files.
Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-kernel@vger.kernel.org
      163b0991
  21. 11 Mar, 2021 1 commit
  23. 10 Feb, 2021 5 commits
  25. 22 Sep, 2020 1 commit
  27. 09 Sep, 2020 1 commit
    • Joerg Roedel's avatar
      x86/entry/64: Add entry code for #VC handler · a13644f3
      Joerg Roedel authored 
      
The #VC handler needs special entry code because:

	1. It runs on an IST stack

	2. It needs to be able to handle nested #VC exceptions

To make this work, the entry code is implemented to pretend it doesn't
use an IST stack. When entered from user-mode or early SYSCALL entry
path it switches to the task stack. If entered from kernel-mode it tries
to switch back to the previous stack in the IRET frame.

The stack found in the IRET frame is validated first, and if it is not
safe to use it for the #VC handler, the code will switch to a
fall-back stack (the #VC2 IST stack). From there, it can cause nested
exceptions again.
Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200907131613.12703-46-joro@8bytes.org
      a13644f3
  29. 24 Aug, 2020 1 commit
  31. 15 Aug, 2020 1 commit
  33. 24 Jul, 2020 1 commit
  35. 21 Jul, 2020 1 commit
  37. 18 Jun, 2020 2 commits
  39. 15 Jun, 2020 1 commit
  41. 11 Jun, 2020 7 commits