linux-kernel - [PATCH 0/4] x86: clean up orig

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Sep 2009 23:18:34 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	jan.kratochvil@...hat.com, Oleg Nesterov <oleg@...hat.com>,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: [PATCH 0/4] x86: clean up orig_ax handling

Here is the aforementioned other tack on this.  

I said earlier that getreg() (i.e. 64-bit ptrace/core-dump fetches)
should sign-extend the low 32 bits of orig_ax up.  But I've changed my
mind.  It's true that today you can store 0xffffffff via either 64-bit
ptrace or 32-bit ptrace and then read back -1 via 64-bit ptrace.  (This
wasn't always so, and so we can hope that no debugger really depends on
it.)  What seems more important is that tracing and core dumps correctly
show the full orig_ax value incoming in %rax from userland, since
%rax=__NR_foo|(1UL<<32) behaves differently (i.e. -ENOSYS) than
%eax=_NR_foo in actual fact when user-mode does "syscall" with those
values.  In a bogon case like that, you would like to have traces/dumps
tell you why the task is not making a proper syscall rather than lie
about what register bits it entered the kernel with.

Patches 1-3 change no ptrace-tests outcomes, i.e. don't regress on the
test cases that went with the original sign-extension changes.  They
reintroduce e.g. the ability to blindly read and write back the whole
regset when at syscall-entry tracing with %rax=__NR_foo|(1UL<<32) and
have that fail with -ENOSYS as it would without tracing rather than
perturb the tracee to call sys_foo instead.  (Not that this is useful.)

Patch 4 does Linus's fix for the outstanding bug.  I've verified it works.

Thanks,
Roland
---
The following changes since commit 7fa07729e439a6184bd824746d06a49cca553f15:
  Linus Torvalds (1):
        Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-roland.git x86/orig_ax

Roland McGrath (4):
      asm-generic: syscall_get_nr returns int
      x86: syscall_get_nr returns int
      x86: ptrace: do not sign-extend orig_ax on write
      x86: ptrace: set TS_COMPAT when 32-bit ptrace sets orig_eax>=0

 arch/x86/include/asm/syscall.h |   14 +++++++-------
 arch/x86/kernel/ptrace.c       |   21 ++++++++-------------
 include/asm-generic/syscall.h  |    8 ++++++--
 3 files changed, 21 insertions(+), 22 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/