linux-kernel - Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v5)

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <1887968822.1146.1547833305059.JavaMail.zimbra@efficios.com>
Date:   Fri, 18 Jan 2019 12:41:45 -0500 (EST)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Carlos O'Donell <carlos@...hat.com>
Cc:     Florian Weimer <fweimer@...hat.com>,
        Joseph Myers <joseph@...esourcery.com>,
        Szabolcs Nagy <szabolcs.nagy@....com>,
        libc-alpha <libc-alpha@...rceware.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ben Maurer <bmaurer@...com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Will Deacon <will.deacon@....com>,
        Dave Watson <davejwatson@...com>, Paul Turner <pjt@...gle.com>,
        Rich Felker <dalias@...c.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-api <linux-api@...r.kernel.org>
Subject: Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C
 startup and thread creation (v5)

----- On Jan 14, 2019, at 8:51 PM, Mathieu Desnoyers mathieu.desnoyers@...icios.com wrote:

[...]

> diff --git a/sysdeps/unix/sysv/linux/rseq-sym.c
> b/sysdeps/unix/sysv/linux/rseq-sym.c
> new file mode 100644
> index 0000000000..6856d0388a
[...]
> +/* volatile because fields can be read/updated by the kernel.  */
> +__thread volatile struct rseq __rseq_abi = {
> +  .cpu_id = RSEQ_CPU_ID_UNINITIALIZED,
> +};
> +
> +/* volatile because refcount can be read/updated by signal handlers.  */
> +__thread volatile uint32_t __rseq_refcount;

Back to the weak vs non-weak question about those two symbols. I understand
that tagging them as weak symbols has little effect on the dynamic loader
when it loads libc.so. However, I'm worried about that happens when
libc is statically linked into an application, and there happens to
be more than one instance of those symbols (e.g. libc and another library
define the same symbols, and both are statically linked into the same
application). Isn't it a situation where tagging those symbols as "weak"
becomes useful ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com