From: Joao Moreira <joao@overdrivepizza.com>
To: Peter Collingbourne <pcc@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Kees Cook <keescook@chromium.org>,
x86@kernel.org, hjl.tools@gmail.com, jpoimboe@redhat.com,
andrew.cooper3@citrix.com, linux-kernel@vger.kernel.org,
ndesaulniers@google.com, samitolvanen@google.com,
llvm@lists.linux.dev
Subject: Re: [RFC][PATCH 6/6] objtool: Add IBT validation / fixups
Date: Tue, 01 Mar 2022 19:32:47 -0800 [thread overview]
Message-ID: <f07f50b634e160f543c2a77ec39a2b4f@overdrivepizza.com> (raw)
In-Reply-To: <Yh7fLRYl8KgMcOe5@google.com>
On 2022-03-01 19:06, Peter Collingbourne wrote:
> Hi Peter,
>
> One issue with this call sequence is that:
>
> On Fri, Feb 11, 2022 at 02:38:03PM +0100, Peter Zijlstra wrote:
>> caller:
>> cmpl $0xdeadbeef, -0x4(%rax) # 7 bytes
>
> Because this instruction ends in the constant 0xdeadbeef, it may
> be used as a "gadget" that would effectively allow branching to an
> arbitrary address in %rax if the attacker can arrange to set ZF=1.
>
>> je 1f # 2 bytes
>> ud2 # 2 bytes
>> 1: call __x86_indirect_thunk_rax # 5 bytes
>>
>>
>> .align 16
>> .byte 0xef, 0xbe, 0xad, 0xde # 4 bytes
>> func:
>> endbr # 4 bytes
>> ...
>> ret
>
> I think we can avoid this problem with a slight tweak to your
> instruction sequence, at the cost of 2 bytes per function prologue.
> First, change the call sequence like so:
>
> cmpl $0xdeadbeef, -0x6(%rax) # 6 bytes
> je 1f # 2 bytes
> ud2 # 2 bytes
> 1: call __x86_indirect_thunk_rax # 5 bytes
>
> The key difference is that we've changed 0x4 to 0x6.
>
> Then change the function prologue to this:
>
> .align 16
> .byte 0xef, 0xbe, 0xad, 0xde # 4 bytes
> .zero 2 # 2 bytes
> func:
>
> The end result of the above is that the constant embedded in the cmpl
> instruction may only be used to reach the following ud2 instruction,
> which will "harmlessly" terminate execution in the same way as if
> the prologue signature did not match.
FWIIW, this makes sense IMHO. These additional pre-prologue bytes are
also what might be needed to enable the smaller version of FineIBT that
I suggested in this thread some time ago.
next prev parent reply other threads:[~2022-03-02 3:37 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 17:03 [RFC][PATCH 0/6] x86: Kernel IBT beginnings Peter Zijlstra
2021-11-22 17:03 ` [RFC][PATCH 1/6] x86: Annotate _THIS_IP_ Peter Zijlstra
2021-11-23 13:53 ` Mark Rutland
2021-11-23 14:14 ` Peter Zijlstra
2021-11-24 18:18 ` Josh Poimboeuf
2021-11-22 17:03 ` [RFC][PATCH 2/6] x86: Base IBT bits Peter Zijlstra
2022-02-08 23:32 ` Kees Cook
2021-11-22 17:03 ` [RFC][PATCH 3/6] x86: Add ENDBR to IRET-to-Self Peter Zijlstra
2021-11-22 18:09 ` Peter Zijlstra
2022-02-08 23:33 ` Kees Cook
2021-11-22 17:03 ` [RFC][PATCH 4/6] objtool: Read the _THIS_IP_ hints Peter Zijlstra
2021-11-22 17:03 ` [RFC][PATCH 5/6] x86: Sprinkle ENDBR dust Peter Zijlstra
2021-11-23 14:00 ` Mark Rutland
2021-11-23 14:21 ` Peter Zijlstra
2022-02-08 23:38 ` Kees Cook
2021-11-22 17:03 ` [RFC][PATCH 6/6] objtool: Add IBT validation / fixups Peter Zijlstra
2021-11-24 19:30 ` Josh Poimboeuf
2022-02-08 23:43 ` Kees Cook
2022-02-09 5:09 ` Josh Poimboeuf
2022-02-09 11:41 ` Peter Zijlstra
2022-02-09 11:45 ` Peter Zijlstra
2021-12-24 2:05 ` joao
2022-02-08 23:42 ` Kees Cook
2022-02-09 2:21 ` Joao Moreira
2022-02-09 4:05 ` Kees Cook
2022-02-09 5:18 ` Joao Moreira
2022-02-11 13:38 ` Peter Zijlstra
2022-02-14 21:38 ` Sami Tolvanen
2022-02-14 22:25 ` Peter Zijlstra
2022-02-15 16:56 ` Sami Tolvanen
2022-02-15 20:03 ` Kees Cook
2022-02-15 21:05 ` Peter Zijlstra
2022-02-15 23:05 ` Kees Cook
2022-02-15 23:38 ` Joao Moreira
2022-02-16 12:24 ` Peter Zijlstra
2022-02-15 20:53 ` Peter Zijlstra
2022-02-15 22:45 ` Joao Moreira
2022-02-16 0:57 ` Andrew Cooper
2022-03-02 3:06 ` Peter Collingbourne
2022-03-02 3:32 ` Joao Moreira [this message]
2022-06-08 17:53 ` Fāng-ruì Sòng
2022-06-09 0:05 ` Sami Tolvanen
2021-11-23 7:58 ` [RFC][PATCH 0/6] x86: Kernel IBT beginnings Christoph Hellwig
2021-11-23 9:02 ` Peter Zijlstra
2022-02-08 23:48 ` Kees Cook
2022-02-09 0:09 ` Nick Desaulniers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f07f50b634e160f543c2a77ec39a2b4f@overdrivepizza.com \
--to=joao@overdrivepizza.com \
--cc=andrew.cooper3@citrix.com \
--cc=hjl.tools@gmail.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=ndesaulniers@google.com \
--cc=pcc@google.com \
--cc=peterz@infradead.org \
--cc=samitolvanen@google.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.