All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>,
	stable@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] selftests/x86/ldt_gdt_32: Work around a glibc sigaction bug
Date: Wed, 22 Mar 2017 07:48:12 +0100	[thread overview]
Message-ID: <20170322064812.GA9848@gmail.com> (raw)
In-Reply-To: <371a5620248568efaf31dd9d897af3775725d9b8.1490114317.git.luto@kernel.org>


* Andy Lutomirski <luto@kernel.org> wrote:

> i386 glibc is buggy and calls the sigaction syscall incorrectly.
> This is asymptomatic for normal programs, but it blows up on
> programs that do evil things with segmentation.  ldt_gdt an example
> of such an evil program.
> 
> This doesn't appear to be a regression -- I think I just got lucky
> with the uninitialized memory that glibc threw at the kernel when I
> wrote the test.
> 
> This hackish fix manually issues sigaction(2) syscalls to undo the
> damage.  Without the fix, ldt_gdt_32 segfaults; with the fix, it
> passes for me.
> 
> See https://sourceware.org/bugzilla/show_bug.cgi?id=21269
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
> 
> I'll see about factoring out sethandler(), etc into a separate file
> soon.  In the mean time, this at least makes the test pass.
> 
>  tools/testing/selftests/x86/ldt_gdt.c | 36 +++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/tools/testing/selftests/x86/ldt_gdt.c b/tools/testing/selftests/x86/ldt_gdt.c
> index f6121612e769..18e6ae1f1bb6 100644
> --- a/tools/testing/selftests/x86/ldt_gdt.c
> +++ b/tools/testing/selftests/x86/ldt_gdt.c
> @@ -409,6 +409,24 @@ static void *threadproc(void *ctx)
>  	}
>  }
>  
> +#ifdef __i386__
> +
> +#ifndef SA_RESTORE
> +#define SA_RESTORER 0x04000000
> +#endif

This looks nicer IMHO:

#ifndef SA_RESTORE
# define SA_RESTORER 0x04000000
#endif

> +
> +/*
> + * The UAPI header calls this 'struct sigaction', which conflicts with
> + * glibc.  Sigh.
> + */
> +struct fake_ksigaction {
> +	void *handler;  /* the real type is nasty */
> +        unsigned long sa_flags;
> +        void (*sa_restorer)(void);
> +	unsigned long sigset1, sigset2;
> +};

Please use tabs, not spaces. Also, don't merge types on the same line. I.e. 
something like:

struct fake_ksigaction {
	void *handler; /* the real type is nasty */
	unsigned long sa_flags;
	void (*sa_restorer)(void);
	unsigned long sigset1;
	unsigned long sigset2;
};


> +#ifdef __i386__
> +	struct fake_ksigaction ksa;

Please either move this into a helper function or add a new block, we shouldn't 
declare new local variables C++ style. How come the compiler didn't warn about 
this? We should use the kernel build warnings.

> +	if (syscall(SYS_rt_sigaction, sig, NULL, &ksa, 8) == 0) {
> +		/*
> +		 * glibc has a nasty bug: it sometimes writes garbage to
> +		 * sa_restorer.  This interacts quite badly with anything
> +		 * that fiddles with SS because it can trigger legacy
> +		 * stack switching.  Patch it up.
> +		 */
> +		printf("%d asdf %lx %p\n", sig, ksa.sa_flags, ksa.sa_restorer);
> +		if (!(ksa.sa_flags & SA_RESTORER) && ksa.sa_restorer) {
> +			printf("asdffff\n");
> +			ksa.sa_restorer = NULL;
> +			if (syscall(SYS_rt_sigaction, sig, &ksa, NULL, 8) != 0)
> +				err(1, "rt_sigaction");

What does the '8' stand for?

Thanks,

	Ingo

  reply	other threads:[~2017-03-22  6:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-21 16:39 [PATCH] selftests/x86/ldt_gdt_32: Work around a glibc sigaction bug Andy Lutomirski
2017-03-22  6:48 ` Ingo Molnar [this message]
2017-03-22 16:37   ` Andy Lutomirski

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=20170322064812.GA9848@gmail.com \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.