mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	hjl.tools@gmail.com
Subject: Re: [patch v2 4/4] ptrace: Add support for generic PTRACE_GETREGSET/PTRACE_SETREGSET
Date: Tue,  9 Feb 2010 17:52:57 -0800 (PST)	[thread overview]
Message-ID: <20100210015257.942463E8@magilla.sf.frob.com> (raw)
In-Reply-To: Suresh Siddha's message of  Tuesday, 9 February 2010 12:13:13 -0800 <20100209202502.406177090@sbs-t61.sc.intel.com>

> 'addr' parameter for the ptrace system call encode the REGSET type and
> the buffer length. 'data' parameter points to the user buffer.
> 
> 	ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid,
> 	       (NT_TYPE << 20) | buf_length, buf);

IMHO this bit swizzling is a non-starter.  The NT_* codes can use a full 32
bits.  NT_PRXFPREG uses 31 bits.  The comments about ignoring the high bits
for this as a special case just seem insane to me.  Pass a full 32 bit word
for NT_* and a full word for the buffer size.  What's so terrible about
just having an obvious and comprehensible API?

IMHO if you insist on an insane bit swizzling approach, you should mix the
buffer size bits into the request code, leaving the "addr" argument free
for the unmolested NT_* code.  There is just no earthly reason that we
should suddenly impose a new and arcane constraint on what NT_* values can
be, even if there is no particular reason for future values not to be small.

> +int generic_ptrace_regset(struct task_struct *child, long request, long addr,
> +			  long data);

There is no need for a global function for this.  It should all be static
in kernel/ptrace.c, called only by ptrace_request()/compat_ptrace_request().

> +#ifdef PTRACE_EXPORT_REGSET
> +	case PTRACE_GETREGSET:
> +	case PTRACE_SETREGSET:
> +		return generic_ptrace_regset(child, request, addr, data);
> +#endif

Just use CONFIG_HAVE_ARCH_TRACEHOOK.  That means the arch supplies
task_user_regset_view().  Any additional per-arch conditionalization
defeats the essential purpose of having fully generic ptrace requests.

> +		if (NOTE_TO_REGSET_TYPE(regset->core_note_type) !=
> +		    PTRACE_REGSET_TYPE(addr))
> +			continue;

Here is where you should validate the buf_size value.  You must not pass a
size that is > regset.size * regset.n or has % regset.size != 0.  The arch
user_regset.get and .set functions are not required to check for bogus
offsets or sizes.

You could either just use:

	buf_size = MIN(buf_size, regset->n * regset->size);

or you could diagnose it with:

	if (buf_size > regset->n * regset->size)
		return -EINVAL;

Possibly we might want to allow a PTRACE_GETREGSET with a buffer that is
larger than necessary.  Then it would probably make sense to zero-fill the
rest of the buffer.  Or else, use an API that can pass back to userland how
much we're actually filling in.

> --- tip.orig/include/linux/elf.h
> +++ tip/include/linux/elf.h
> @@ -349,7 +349,29 @@ typedef struct elf64_shdr {
>  #define ELF_OSABI ELFOSABI_NONE
>  #endif
>  
> -/* Notes used in ET_CORE */
> +/*
> + * Notes used in ET_CORE. Architectures export some of the arch register sets
[...]

These comments don't really belong in linux/elf.h IMHO.  They don't add
anything, except documenting the insanity about truncating NT_* values.  I
don't think that nutty idea should survive.  But regardless, everything
about it belongs alongside the macros used to construct and deconstruct the
argument word.  No example should recommend using the bit-twiddling rather
than using some such macros that are made public in linux/ptrace.h.


Thanks,
Roland

  parent reply	other threads:[~2010-02-10  1:53 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-09 20:13 [patch v2 0/4] updated ptrace/core-dump patches for supporting xstate - V2 Suresh Siddha
2010-02-09 20:13 ` [patch v2 1/4] revert "x86: ptrace and core-dump extensions for xstate" Suresh Siddha
2010-02-09 22:54   ` [tip:x86/ptrace] Revert " tip-bot for Suresh Siddha
2010-02-09 20:13 ` [patch v2 2/4] x86, ptrace: regset extensions to support xstate Suresh Siddha
2010-02-09 22:54   ` [tip:x86/ptrace] x86, ptrace: Regset " tip-bot for Suresh Siddha
2010-02-10  1:30   ` [patch v2 2/4] x86, ptrace: regset " Roland McGrath
2010-02-10 10:44     ` Oleg Nesterov
2010-02-10 11:28   ` Oleg Nesterov
2010-02-10 15:43     ` Oleg Nesterov
2010-02-10 18:26       ` Roland McGrath
2010-02-10 14:18   ` Oleg Nesterov
2010-02-10 15:34     ` Oleg Nesterov
2010-02-09 20:13 ` [patch v2 3/4] x86, ptrace: prepare regset get/set routines for user specified lengths Suresh Siddha
2010-02-09 22:55   ` [tip:x86/ptrace] x86, ptrace: Prepare " tip-bot for Suresh Siddha
2010-02-10  1:32   ` [patch v2 3/4] x86, ptrace: prepare " Roland McGrath
2010-02-09 20:13 ` [patch v2 4/4] ptrace: Add support for generic PTRACE_GETREGSET/PTRACE_SETREGSET Suresh Siddha
2010-02-09 22:55   ` [tip:x86/ptrace] " tip-bot for Suresh Siddha
2010-02-10  1:52   ` Roland McGrath [this message]
2010-02-10  2:03     ` [patch v2 4/4] " H.J. Lu
2010-02-10  3:07       ` Roland McGrath
2010-02-10  4:24         ` H.J. Lu
2010-02-10 13:18   ` Oleg Nesterov
2010-02-10 19:12     ` Roland McGrath
2010-02-11  2:17       ` H. Peter Anvin
2010-02-11  3:30         ` Roland McGrath
2010-02-10  1:12 ` [patch v2 0/4] updated ptrace/core-dump patches for supporting xstate - V2 Roland McGrath
2010-02-10  1:22   ` Suresh Siddha
2010-02-10  7:27   ` Ingo Molnar
2010-02-10 18:58     ` Roland McGrath
2010-02-11  2:18       ` H. Peter Anvin
2010-02-11  3:45         ` Roland McGrath
2010-02-11  4:16           ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100210015257.942463E8@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®