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

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: <a1bd2595-b7ae-b06b-9c71-802901ed8587@arm.com>
Date:   Tue, 23 Apr 2019 11:16:03 +0000
From:   Szabolcs Nagy <Szabolcs.Nagy@....com>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
CC:     nd <nd@....com>, Joseph Myers <joseph@...esourcery.com>,
        Will Deacon <Will.Deacon@....com>, carlos <carlos@...hat.com>,
        Florian Weimer <fweimer@...hat.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>,
        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: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and
 thread creation (v8)

On 18/04/2019 19:17, Mathieu Desnoyers wrote:
> ----- On Apr 18, 2019, at 1:37 PM, Szabolcs Nagy Szabolcs.Nagy@....com wrote:
>> you have to add a documentation comment somewhere
>> explaining if RSEQ_SIG is the value that's passed to
>> the kernel and then aarch64 asm code has to use
>>
>> .inst endianfixup(RSEQ_SIG) // or
>> .word RSEQ_SIG
> 
> Using ".word" won't allow objdump to show the instruction it
> maps to. It will consider it as data. So .inst is preferred here.

is there some specific reason you prefer .inst?

disassembling a canary value as data (that is
never executed, but loaded and compared by the
kernel as data) sounds more semantically correct
to me than showing it as an instruction.

i guess having it as an instruction can avoid
issues if some tools dislike .word in .text,
but otherwise .word seems better.