Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 1 Sep 2020 20:20:37 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: i386 __set_thread_area will crash if the syscall fails

On Sun, Aug 30, 2020 at 10:51:38PM -0400, Rich Felker wrote:
> The attached should be the equivalent in C, but it's somewhat larger.
> Somewhat indifferent on replacing it.
>
> Rich

I support that change. I did send some comments for that file a while
ago, but actually moving this stuff to a language that is easier on the
eyes than assembler is probably the better move.


Plus, this way the compiler gets to optimize the access to the static
variable depending on compilation mode (e.g. PIC/non-PIC, i386/i686,
etc. etc.). The call/pop was always a little irksome to me.

> #define SYSCALL_NO_TLS 1
> #include <stdint.h>
> #include "syscall.h"
>
> struct user_desc {
> 	uint32_t entry_number;
> 	uint32_t base_addr;
> 	uint32_t limit;
> 	uint32_t flags;
> };
>
> static int entry_number = -1;
>
> int __set_thread_area_2(void *p)
> {
> 	struct user_desc desc = {
> 		entry_number, (uintptr_t)p, 0xfffff, 0x51
> 	};
> 	int r = __syscall(SYS_set_thread_area, &desc);
> 	if (!r) {
> 		entry_number = desc.entry_number;
> 		__asm__ __volatile__ ("mov %0,%%gs" :
> 			: "r"(3+8*desc.entry_number));

I always wonder why people put underscores around the volatile, though.
Given that volatile is always a keyword, no matter the compiler
settings. Plus, in this case it is unnecessary, since the asm snippet
has no outputs, so it is always volatile.

> 		return 0;
> 	}
> 	desc.entry_number = 0;
> 	r = __syscall(SYS_modify_ldt, 1, &desc, 16);
> 	if (!r) {
> 		__asm__ __volatile__ ("mov %0,%%gs" :
> 			: "r"(7));
> 		return 1;
> 	}
> 	return r;
> }

Ciao,
Markus

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.