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: <1798976202.14561.1641605611712.JavaMail.zimbra@efficios.com>
Date:   Fri, 7 Jan 2022 20:33:31 -0500 (EST)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     Florian Weimer <fw@...eb.enyo.de>,
        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 8:08 PM, Mathieu Desnoyers mathieu.desnoyers@...icios.com wrote:

> ----- On Jan 7, 2022, at 5:27 PM, David Laight David.Laight@...LAB.COM wrote:
> 
>>> 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.
>> 
>> Stack redzone in a leaf function?
> 
> Good point!
> 
> For x86-64 for instance, which has a redzone of 128 bytes, there are a few
> alternatives.
> On abort:
> 
> Approach A) Move the stack pointer as little as possible
> 
>   1. On abort in kernel:
>   1.1 Subtract 8 bytes from the stack pointer
>   1.2 Store the abort-at-ip value at stack pointer - 128
>   2. In abort handler (userspace)
>   2.1 user-space knows that it can find the abort-at-ip value at stack pointer -
>   128
>   2.2 after using that value, the abort handler needs to add 8 bytes to the stack
>   pointer
> 
> Approach B) Move the stack pointer to skip the entire redzone
> 
>   1. On abort in kernel:
>   1.1 Subtract 128 bytes from the stack pointer
>   1.2 Store the abort-at-ip value at stack pointer - 8 (basically within a new red
>   zone)
>   2. In abort handler (userspace)
>   2.1 user-space knows that it can find the abort-at-ip value at stack pointer - 8
>   2.2 after using that value, the abort handler needs to add 128 bytes to the
>   stack pointer

Or approach C)

  1. On abort in kernel:
  1.1 Subtract 136 bytes from the stack pointer
  1.2 Store the abort-at-ip value at stack pointer
  2. In abort handler (userspace)
  2.1 user-space knows that it can find the abort-at-ip value at stack pointer, so
      it can pop it from the stack
  2.2 after popping that value, the abort handler needs to add 128 bytes to the stack pointer

So far, approach C seems to be the most elegant IMHO.

Thanks,

Mathieu


> 
> I suspect both approaches should work.
> 
> Any preference or other ideas ?
> 
> Thanks,
> 
> Mathieu
> 
>> 
>> -
>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
>> UK
>> Registration No: 1397386 (Wales)
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

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