The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ulrich Drepper <drepper@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Richard Guenther <rguenther@suse.de>
Subject: Re: [PATCH] information leak in sigaltstack
Date: Sat, 1 Aug 2009 09:22:38 +0200	[thread overview]
Message-ID: <20090801072238.GV4462@tyan-ft48-01.lab.bos.redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.01.0907311716220.3304@localhost.localdomain>

On Fri, Jul 31, 2009 at 05:28:40PM -0700, Linus Torvalds wrote:
> 
> [ Cc'ing jakub, since that code generation looks crappy, and I think he 
>   has worked on gcc memset(). I wonder if it's because we use -Os, and gcc 
>   tries to avoid one REX prefix on the 'stosq'.

Assuming we are talking about:
typedef __SIZE_TYPE__ size_t;
typedef struct sigaltstack { void *ss_sp; int ss_flags; size_t ss_size; }
stack_t;
void foo (stack_t *oss, void *sp)
{
  __builtin_memset (oss, 0, sizeof (*oss));
  oss->ss_sp = sp;
  oss->ss_flags = 6;
  oss->ss_size = 2; 
}

yes, it is because of -Os, rep stosq is longer than rep stosl.  For -O2 it
generates:
        movq    $0, 8(%rdi)
        movq    %rsi, (%rdi)
        movl    $6, 8(%rdi)
        movq    $2, 16(%rdi)
which still isn't perfect, but is much better.  GCC 4.4 newly has RTL DCE
improvements, so that at least the memcpy is optimized away if the structure
is filled completely after the memset, or is able to optimize away NULL/0
assignments after a memset to 0.  At -O2 when GCC decides to do the memset
piecewise it is easier to kill dead stores from the memset (the -O2 code
perhaps could be improved by the http://gcc.gnu.org/PR22141 patch which
hasn't been committed because it didn't show visible improvements and on
power6 even degraded performance).  At -Os when GCC decides during the
expand to use arch specific pattern for the memset it would be much harder
to handle it at the RTL level.  So the above should be ideally optimized
already at the tree level.

> diff --git a/kernel/signal.c b/kernel/signal.c
> index ccf1cee..b990dc8 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2455,6 +2455,9 @@ do_sigaltstack (const stack_t __user *uss, stack_t __user *uoss, unsigned long s
>  	int error;
>  
>  	if (uoss) {
> +		/* Fill cracks around 'ss_flags' */
> +		if (__alignof__(oss.ss_flags) != __alignof__(oss))
> +			memset(&oss, 0, sizeof(oss));
>  		oss.ss_sp = (void __user *) current->sas_ss_sp;
>  		oss.ss_size = current->sas_ss_size;
>  		oss.ss_flags = sas_ss_flags(sp);

I'd say the test you want to do is
if (sizeof (oss.ss_sp) + sizeof (oss.ss_size) + sizeof (oss.ss_flags)
    != sizeof oss)
  memset (&oss, 0, sizeof oss);
(i.e. check whether the struct has any padding in it or not).

	Jakub

  reply	other threads:[~2009-08-01  7:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-31 19:48 [PATCH] information leak in sigaltstack Ulrich Drepper
2009-07-31 21:15 ` Linus Torvalds
2009-07-31 21:31   ` Linus Torvalds
2009-07-31 21:37     ` Ulrich Drepper
2009-08-01  0:28       ` Linus Torvalds
2009-08-01  7:22         ` Jakub Jelinek [this message]
2009-08-01 16:13           ` Linus Torvalds
2009-08-01 17:52         ` Linus Torvalds

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=20090801072238.GV4462@tyan-ft48-01.lab.bos.redhat.com \
    --to=jakub@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rguenther@suse.de \
    --cc=torvalds@linux-foundation.org \
    /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