lkml.org 
[lkml]   [2022]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] rseq: x86: implement abort-at-ip extension
----- On Jan 7, 2022, at 2:48 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:

> ----- On Jan 7, 2022, at 2:31 PM, Florian Weimer fw@deneb.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 ?

That being said, there might be an architecture agnostic alternative available.
On abort of a RSEQ_CS_FLAG_ABORT_AT_IP critical section, we could let the kernel
decrement/increment the stack pointer to make room for a pointer (depending if the
stack grows down or up). It would then store the abort-at-ip value at the top of
stack.

The abort handler would be expected to use this top of stack abort-at-ip value,
and would be required to increment/decrement (depending on the stack direction)
the stack pointer back to its rightful value before the end of the assembly block.

Thoughts ?

Thanks,

Mathieu

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

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

\
 
 \ /
  Last update: 2022-01-07 22:28    [W:1.044 / U:1.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site