linux-kernel - Re: [RFC PATCH] rseq: x86: implement abort-at-ip extension

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: <1968088162.13310.1641584935813.JavaMail.zimbra@efficios.com>
Date:   Fri, 7 Jan 2022 14:48:55 -0500 (EST)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Florian Weimer <fw@...eb.enyo.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        paulmck <paulmck@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
        "H. Peter Anvin" <hpa@...or.com>, Paul Turner <pjt@...gle.com>,
        linux-api <linux-api@...r.kernel.org>,
        Christian Brauner <christian.brauner@...ntu.com>,
        carlos <carlos@...hat.com>
Subject: Re: [RFC PATCH] rseq: x86: implement abort-at-ip extension

----- On Jan 7, 2022, at 2:31 PM, Florian Weimer fw@...eb.enyo.de wrote:

> * Mathieu Desnoyers:
> 
>> Allow rseq critical section abort handlers to optionally figure out at
>> which instruction pointer the rseq critical section was aborted.
>>
>> This allows implementing rseq critical sections containing loops, in
>> which case the commit side-effect cannot be the last instruction. This
>> is useful to implement adaptative mutexes aware of preemption in
>> user-space. (see [1])
> 
> Could you write the program counter to the rseq area instead?  This
> would avoid discussing which register to clobber.

Using the rseq area for that purpose would be problematic for nested signal
handlers with rseq critical sections. If a signal happens to be delivered
right after the abort ip adjustment, its signal handler containing a rseq
critical section could overwrite the relevant "abort-at-ip" field in the
rseq per-thread area before it has been read by the abort handler interrupted
by the signal.

Making this architecture-agnostic is indeed a laudable goal, but I don't
think the rseq per-thread area is a good fit for this.

I also though about making the clobbered register configurable on a
per-critical-section basis, but I rather think that it would be
overengineered: too much complexity for the gain. Unless there are
very strong reasons for choosing one register over another on a per
use-case basis ?

I guess if we ever care about the state of a given register within a given
range of instructions, we may lose that information if it is overwritten
by the abort-at-ip value. For instance, in my adaptative mutex prototype,
I use the Zero Flag to check if cmpxchg has succeeded. But if I would have
wanted to use the register modified by cmpxchg, and it would happen to be
clobbered by the abort-at-ip on abort, then it limits what the abort handler
can observe. It's fine as long as instructions can select what registers they
operate on, but instructions like cmpxchg AFAIR work on specific registers,
which might warrant making the abort-at-ip register configurable per
critical section. But maybe just choosing a register for abort-at-ip which
is not typically used by instructions that rely on hardcoded registers might
be sufficient.

Thoughts ?

Thanks,

Mathieu

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