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  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:   Fri, 14 Jun 2019 06:14:09 -0400 (EDT)
From:   Mathieu Desnoyers <>
To:     Florian Weimer <>
Cc:     carlos <>, Joseph Myers <>,
        Szabolcs Nagy <>,
        libc-alpha <>,
        Thomas Gleixner <>,
        Ben Maurer <>,
        Peter Zijlstra <>,
        "Paul E. McKenney" <>,
        Boqun Feng <>,
        Will Deacon <>,
        Dave Watson <>, Paul Turner <>,
        Rich Felker <>,
        linux-kernel <>,
        linux-api <>
Subject: Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup
 and thread creation (v10)

----- On Jun 14, 2019, at 12:06 PM, Florian Weimer wrote:

> * Mathieu Desnoyers:
>> ----- On Jun 12, 2019, at 4:00 PM, Mathieu Desnoyers
>> wrote:
>>> ----- On Jun 10, 2019, at 4:43 PM, carlos wrote:
>>>> On 6/6/19 7:57 AM, Florian Weimer wrote:
>>>>> Let me ask the key question again: Does it matter if code observes the
>>>>> rseq area first without kernel support, and then with kernel support?
>>>>> If we don't expect any problems immediately, we do not need to worry
>>>>> much about the constructor ordering right now.  I expect that over time,
>>>>> fixing this properly will become easier.
>>>> I just wanted to chime in and say that splitting this into:
>>>> * Ownership (__rseq_handled)
>>>> * Initialization (__rseq_abi)
>>>> Makes sense to me.
>>>> I agree we need an answer to this question of ownership but not yet
>>>> initialized, to owned and initialized.
>>>> I like the idea of having __rseq_handled in
>>> Very good, so I'll implement this approach. Sorry for the delayed
>>> feedback, I am traveling this week.
>> I had issues with cases where application or LD_PRELOAD library also
>> define the __rseq_handled symbol. They appear not to see the same
>> address as the one initialized by
> What exactly did you do?  How did you determine the addresses?  How is
> __rseq_handled defined in

The easiest way to answer these questions is through links to my github
dev branch:

specifically this commit:
and this attempt at using GL():

My test programs are:

* a.c:

#include <stdio.h>
#include <linux/rseq.h>

extern __thread struct rseq __rseq_abi
__attribute__ ((tls_model ("initial-exec")));/* = {
	.cpu_id = -1,
extern int __rseq_handled;

int main()
	fprintf(stderr, "__rseq_handled main: %d %p\n", __rseq_handled, &__rseq_handled);
	fprintf(stderr, "__rseq_abi.cpu_id main: %d %p\n", __rseq_abi.cpu_id, &__rseq_abi);
	return 0;

* s.c:

#include <stdio.h>
#include <linux/rseq.h>

#if 0
__thread struct rseq __rseq_abi
__attribute__ ((tls_model ("initial-exec"))) = {
	.cpu_id = -1,
int __rseq_handled;

extern __thread struct rseq __rseq_abi
__attribute__ ((tls_model ("initial-exec")));
extern int __rseq_handled;

void __attribute__((constructor)) myinit(void)
	fprintf(stderr, "__rseq_handled %d %p\n", __rseq_handled, &__rseq_handled);
	fprintf(stderr, "__rseq_abi.cpu_id %d %p\n", __rseq_abi.cpu_id, &__rseq_abi);

* Makefile:

CFLAGS=-I${KERNEL_HEADERS} -L${LIBCPATH} -Wl,--rpath=${LIBCPATH} -Wl,--dynamic-linker=${LIBCPATH}/

	gcc ${CFLAGS} -o a a.c
	gcc ${CFLAGS} -shared -fPIC -o s.c



> Thanks,
> Florian

Mathieu Desnoyers
EfficiOS Inc.

Powered by blists - more mailing lists