From: Kees Cook <keescook@chromium.org>
To: Dan Li <ashimida@linux.alibaba.com>
Cc: akpm@linux-foundation.org, arnd@arndb.de,
catalin.marinas@arm.com, gregkh@linuxfoundation.org,
linux@roeck-us.net, luc.vanoostenryck@gmail.com,
elver@google.com, mark.rutland@arm.com, masahiroy@kernel.org,
ojeda@kernel.org, nathan@kernel.org, npiggin@gmail.com,
ndesaulniers@google.com, samitolvanen@google.com,
shuah@kernel.org, tglx@linutronix.de, will@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
llvm@lists.linux.dev, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3 2/2] lkdtm: Add Shadow Call Stack tests
Date: Wed, 9 Mar 2022 12:16:47 -0800 [thread overview]
Message-ID: <202203091211.4F00F560@keescook> (raw)
In-Reply-To: <92a767c4-09e1-8783-2581-9848bb72890d@linux.alibaba.com>
On Mon, Mar 07, 2022 at 07:16:36AM -0800, Dan Li wrote:
> The following code seems to work fine under clang/gcc, x86_64/aarch64
> (also tested in lkdtm_CFI_BACKWARD_SHADOW):
>
> #include <stdio.h>
>
> static __attribute__((noinline))
> void set_return_addr(unsigned long *expected, unsigned long *addr)
> {
> /* Use of volatile is to make sure final write isn't seen as a dead store. */
> unsigned long * volatile *ret_addr = (unsigned long **)__builtin_frame_address(0) + 1;
>
> /* Make sure we've found the right place on the stack before writing it. */
> if(*ret_addr == expected)
> *ret_addr = (addr);
> }
>
> static volatile int force_label;
>
> int main(void)
> {
> void *array[] = {0, &&normal, &&redirected};
>
> if (force_label) {
> /* Call it with a NULL to avoid parameters being treated as constants in -02. */
> set_return_addr(NULL, NULL);
> goto * array[force_label];
> }
Hah! I like that. :) I had a weird switch statement that was working for
me; this is cleaner.
>
> do {
>
> set_return_addr(&&normal, &&redirected);
>
> normal:
> printf("I should be skipped\n");
> break;
>
> redirected:
> printf("Redirected\n");
>
> } while (0);
>
> return 0;
> }
>
> But currently it still crashes when I try to enable
> "-mbranch-protection=pac-ret+leaf+bti".
>
> Because the address of "&&redirected" is not encrypted under pac,
> the autiasp check will fail when set_return_addr returns, and
> eventually cause the function to crash when it returns to "&&redirected"
> ("&&redirected" as a reserved label always seems to start with a bti j
> insn).
Strictly speaking, this is entirely correct. :)
> For lkdtm, if we're going to handle both cases in one function, maybe
> it would be better to turn off the -mbranch-protection=pac-ret+leaf+bti
> and maybe also turn off -O2 options for the function :)
If we can apply a function attribute to turn off pac for the "does this
work without protections", that should be sufficient.
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Dan Li <ashimida@linux.alibaba.com>
Cc: akpm@linux-foundation.org, arnd@arndb.de,
catalin.marinas@arm.com, gregkh@linuxfoundation.org,
linux@roeck-us.net, luc.vanoostenryck@gmail.com,
elver@google.com, mark.rutland@arm.com, masahiroy@kernel.org,
ojeda@kernel.org, nathan@kernel.org, npiggin@gmail.com,
ndesaulniers@google.com, samitolvanen@google.com,
shuah@kernel.org, tglx@linutronix.de, will@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
llvm@lists.linux.dev, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3 2/2] lkdtm: Add Shadow Call Stack tests
Date: Wed, 9 Mar 2022 12:16:47 -0800 [thread overview]
Message-ID: <202203091211.4F00F560@keescook> (raw)
In-Reply-To: <92a767c4-09e1-8783-2581-9848bb72890d@linux.alibaba.com>
On Mon, Mar 07, 2022 at 07:16:36AM -0800, Dan Li wrote:
> The following code seems to work fine under clang/gcc, x86_64/aarch64
> (also tested in lkdtm_CFI_BACKWARD_SHADOW):
>
> #include <stdio.h>
>
> static __attribute__((noinline))
> void set_return_addr(unsigned long *expected, unsigned long *addr)
> {
> /* Use of volatile is to make sure final write isn't seen as a dead store. */
> unsigned long * volatile *ret_addr = (unsigned long **)__builtin_frame_address(0) + 1;
>
> /* Make sure we've found the right place on the stack before writing it. */
> if(*ret_addr == expected)
> *ret_addr = (addr);
> }
>
> static volatile int force_label;
>
> int main(void)
> {
> void *array[] = {0, &&normal, &&redirected};
>
> if (force_label) {
> /* Call it with a NULL to avoid parameters being treated as constants in -02. */
> set_return_addr(NULL, NULL);
> goto * array[force_label];
> }
Hah! I like that. :) I had a weird switch statement that was working for
me; this is cleaner.
>
> do {
>
> set_return_addr(&&normal, &&redirected);
>
> normal:
> printf("I should be skipped\n");
> break;
>
> redirected:
> printf("Redirected\n");
>
> } while (0);
>
> return 0;
> }
>
> But currently it still crashes when I try to enable
> "-mbranch-protection=pac-ret+leaf+bti".
>
> Because the address of "&&redirected" is not encrypted under pac,
> the autiasp check will fail when set_return_addr returns, and
> eventually cause the function to crash when it returns to "&&redirected"
> ("&&redirected" as a reserved label always seems to start with a bti j
> insn).
Strictly speaking, this is entirely correct. :)
> For lkdtm, if we're going to handle both cases in one function, maybe
> it would be better to turn off the -mbranch-protection=pac-ret+leaf+bti
> and maybe also turn off -O2 options for the function :)
If we can apply a function attribute to turn off pac for the "does this
work without protections", that should be sufficient.
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-03-09 20:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-03 7:33 [PATCH v3 0/2] AARCH64: Enable GCC-based Shadow Call Stack Dan Li
2022-03-03 7:33 ` Dan Li
2022-03-03 7:43 ` [PATCH v3 1/2] AARCH64: Add gcc Shadow Call Stack support Dan Li
2022-03-03 7:43 ` Dan Li
2022-03-10 18:15 ` (subset) " Kees Cook
2022-03-10 18:15 ` Kees Cook
2022-03-03 7:43 ` [PATCH v3 2/2] lkdtm: Add Shadow Call Stack tests Dan Li
2022-03-03 7:43 ` Dan Li
2022-03-03 18:42 ` Kees Cook
2022-03-03 18:42 ` Kees Cook
2022-03-03 19:09 ` Kees Cook
2022-03-03 19:09 ` Kees Cook
2022-03-04 14:54 ` Dan Li
2022-03-04 14:54 ` Dan Li
2022-03-04 15:01 ` Dan Li
2022-03-04 15:01 ` Dan Li
2022-03-07 15:16 ` Dan Li
2022-03-07 15:16 ` Dan Li
2022-03-09 20:16 ` Kees Cook [this message]
2022-03-09 20:16 ` Kees Cook
2022-03-11 2:46 ` Dan Li
2022-03-11 2:46 ` Dan Li
2022-03-04 14:34 ` Dan Li
2022-03-04 14:34 ` Dan Li
2022-03-14 13:53 ` [PATCH v4 " Dan Li
2022-03-14 13:53 ` Dan Li
2022-03-14 14:02 ` Dan Li
2022-03-14 14:02 ` Dan Li
2022-04-06 1:28 ` Dan Li
2022-04-06 1:28 ` Dan Li
2022-04-06 1:48 ` Dan Li
2022-04-06 1:48 ` Dan Li
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=202203091211.4F00F560@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=ashimida@linux.alibaba.com \
--cc=catalin.marinas@arm.com \
--cc=elver@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=llvm@lists.linux.dev \
--cc=luc.vanoostenryck@gmail.com \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=npiggin@gmail.com \
--cc=ojeda@kernel.org \
--cc=samitolvanen@google.com \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=will@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.