All of lore.kernel.org
 help / color / mirror / Atom feed
From: He Zhe <zhe.he@windriver.com>
To: Kees Cook <keescook@chromium.org>
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
	tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com,
	alexander.shishkin@linux.intel.com, jolsa@kernel.org,
	namhyung@kernel.org, benh@kernel.crashing.org, paulus@samba.org,
	borntraeger@linux.ibm.com, svens@linux.ibm.com, hpa@zytor.com,
	x86@kernel.org, linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-perf-users@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 2/8] arm64: stacktrace: Add arch_within_stack_frames
Date: Tue, 19 Apr 2022 22:01:11 +0800	[thread overview]
Message-ID: <b328bed3-ebb9-6fba-9585-79946262c40f@windriver.com> (raw)
In-Reply-To: <202204181457.9DE190CE@keescook>



On 4/19/22 05:59, Kees Cook wrote:
> On Mon, Apr 18, 2022 at 09:22:11PM +0800, He Zhe wrote:
>> This function checks if the given address range crosses frame boundary.
>> It is based on the existing x86 algorithm, but implemented via stacktrace.
>> This can be tested by USERCOPY_STACK_FRAME_FROM and
>> USERCOPY_STACK_FRAME_TO in lkdtm.
> Hi,
>
> Thanks for doing this implementation! One reason usercopy hardening
> didn't persue doing a "full" stacktrace was because it seemed relatively
> expensive. Did you do any usercopy-heavily workload testing to see if
> there was a noticeable performance impact?
>
> It would be nice to block the exposure of canaries and PAC bits, though,
> so I'm not opposed, but I'd like to get a better sense of how "heavy"
> this might be.

I just did some rough tests:
hackbench -s 512 -l 200 -g 15 -f 25 -P
Such line would hit arch_within_stack_frames at least 5000 times in my environment.
With hardened_usercopy=on, the execution time would be around 2.121 seconds(average for 30 times)
With hardened_usercopy=off, the execution time would be around 2.011 seconds(average for 30 times)

I'll test the original x86 way for arm64 tomorrow.

Any other workload needed to be run?

Thanks,
Zhe


>
> Thanks!
>
> -Kees
>


WARNING: multiple messages have this Message-ID (diff)
From: He Zhe <zhe.he@windriver.com>
To: Kees Cook <keescook@chromium.org>
Cc: mark.rutland@arm.com, linux-s390@vger.kernel.org, x86@kernel.org,
	hpa@zytor.com, alexander.shishkin@linux.intel.com,
	catalin.marinas@arm.com, dave.hansen@linux.intel.com,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	linux-perf-users@vger.kernel.org, bp@alien8.de,
	svens@linux.ibm.com, jolsa@kernel.org, namhyung@kernel.org,
	tglx@linutronix.de, borntraeger@linux.ibm.com, will@kernel.org,
	linux-riscv@lists.infradead.org, paulus@samba.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 2/8] arm64: stacktrace: Add arch_within_stack_frames
Date: Tue, 19 Apr 2022 22:01:11 +0800	[thread overview]
Message-ID: <b328bed3-ebb9-6fba-9585-79946262c40f@windriver.com> (raw)
In-Reply-To: <202204181457.9DE190CE@keescook>



On 4/19/22 05:59, Kees Cook wrote:
> On Mon, Apr 18, 2022 at 09:22:11PM +0800, He Zhe wrote:
>> This function checks if the given address range crosses frame boundary.
>> It is based on the existing x86 algorithm, but implemented via stacktrace.
>> This can be tested by USERCOPY_STACK_FRAME_FROM and
>> USERCOPY_STACK_FRAME_TO in lkdtm.
> Hi,
>
> Thanks for doing this implementation! One reason usercopy hardening
> didn't persue doing a "full" stacktrace was because it seemed relatively
> expensive. Did you do any usercopy-heavily workload testing to see if
> there was a noticeable performance impact?
>
> It would be nice to block the exposure of canaries and PAC bits, though,
> so I'm not opposed, but I'd like to get a better sense of how "heavy"
> this might be.

I just did some rough tests:
hackbench -s 512 -l 200 -g 15 -f 25 -P
Such line would hit arch_within_stack_frames at least 5000 times in my environment.
With hardened_usercopy=on, the execution time would be around 2.121 seconds(average for 30 times)
With hardened_usercopy=off, the execution time would be around 2.011 seconds(average for 30 times)

I'll test the original x86 way for arm64 tomorrow.

Any other workload needed to be run?

Thanks,
Zhe


>
> Thanks!
>
> -Kees
>


WARNING: multiple messages have this Message-ID (diff)
From: He Zhe <zhe.he@windriver.com>
To: Kees Cook <keescook@chromium.org>
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
	tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com,
	alexander.shishkin@linux.intel.com, jolsa@kernel.org,
	namhyung@kernel.org, benh@kernel.crashing.org, paulus@samba.org,
	borntraeger@linux.ibm.com, svens@linux.ibm.com, hpa@zytor.com,
	x86@kernel.org, linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-perf-users@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 2/8] arm64: stacktrace: Add arch_within_stack_frames
Date: Tue, 19 Apr 2022 22:01:11 +0800	[thread overview]
Message-ID: <b328bed3-ebb9-6fba-9585-79946262c40f@windriver.com> (raw)
In-Reply-To: <202204181457.9DE190CE@keescook>



On 4/19/22 05:59, Kees Cook wrote:
> On Mon, Apr 18, 2022 at 09:22:11PM +0800, He Zhe wrote:
>> This function checks if the given address range crosses frame boundary.
>> It is based on the existing x86 algorithm, but implemented via stacktrace.
>> This can be tested by USERCOPY_STACK_FRAME_FROM and
>> USERCOPY_STACK_FRAME_TO in lkdtm.
> Hi,
>
> Thanks for doing this implementation! One reason usercopy hardening
> didn't persue doing a "full" stacktrace was because it seemed relatively
> expensive. Did you do any usercopy-heavily workload testing to see if
> there was a noticeable performance impact?
>
> It would be nice to block the exposure of canaries and PAC bits, though,
> so I'm not opposed, but I'd like to get a better sense of how "heavy"
> this might be.

I just did some rough tests:
hackbench -s 512 -l 200 -g 15 -f 25 -P
Such line would hit arch_within_stack_frames at least 5000 times in my environment.
With hardened_usercopy=on, the execution time would be around 2.121 seconds(average for 30 times)
With hardened_usercopy=off, the execution time would be around 2.011 seconds(average for 30 times)

I'll test the original x86 way for arm64 tomorrow.

Any other workload needed to be run?

Thanks,
Zhe


>
> Thanks!
>
> -Kees
>


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: He Zhe <zhe.he@windriver.com>
To: Kees Cook <keescook@chromium.org>
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
	tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com,
	alexander.shishkin@linux.intel.com, jolsa@kernel.org,
	namhyung@kernel.org, benh@kernel.crashing.org, paulus@samba.org,
	borntraeger@linux.ibm.com, svens@linux.ibm.com, hpa@zytor.com,
	x86@kernel.org, linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-perf-users@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 2/8] arm64: stacktrace: Add arch_within_stack_frames
Date: Tue, 19 Apr 2022 22:01:11 +0800	[thread overview]
Message-ID: <b328bed3-ebb9-6fba-9585-79946262c40f@windriver.com> (raw)
In-Reply-To: <202204181457.9DE190CE@keescook>



On 4/19/22 05:59, Kees Cook wrote:
> On Mon, Apr 18, 2022 at 09:22:11PM +0800, He Zhe wrote:
>> This function checks if the given address range crosses frame boundary.
>> It is based on the existing x86 algorithm, but implemented via stacktrace.
>> This can be tested by USERCOPY_STACK_FRAME_FROM and
>> USERCOPY_STACK_FRAME_TO in lkdtm.
> Hi,
>
> Thanks for doing this implementation! One reason usercopy hardening
> didn't persue doing a "full" stacktrace was because it seemed relatively
> expensive. Did you do any usercopy-heavily workload testing to see if
> there was a noticeable performance impact?
>
> It would be nice to block the exposure of canaries and PAC bits, though,
> so I'm not opposed, but I'd like to get a better sense of how "heavy"
> this might be.

I just did some rough tests:
hackbench -s 512 -l 200 -g 15 -f 25 -P
Such line would hit arch_within_stack_frames at least 5000 times in my environment.
With hardened_usercopy=on, the execution time would be around 2.121 seconds(average for 30 times)
With hardened_usercopy=off, the execution time would be around 2.011 seconds(average for 30 times)

I'll test the original x86 way for arm64 tomorrow.

Any other workload needed to be run?

Thanks,
Zhe


>
> Thanks!
>
> -Kees
>


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-04-19 14:02 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18 13:22 [PATCH RFC 0/8] hardened usercopy and stacktrace improvement He Zhe
2022-04-18 13:22 ` He Zhe
2022-04-18 13:22 ` He Zhe
2022-04-18 13:22 ` He Zhe
2022-04-18 13:22 ` [PATCH RFC 1/8] stacktrace: Change callback prototype to pass more information He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-19 13:09   ` Mark Rutland
2022-04-19 13:09     ` Mark Rutland
2022-04-19 13:09     ` Mark Rutland
2022-04-19 13:09     ` Mark Rutland
2022-04-19 14:13     ` He Zhe
2022-04-19 14:13       ` He Zhe
2022-04-19 14:13       ` He Zhe
2022-04-19 14:13       ` He Zhe
2022-04-18 13:22 ` [PATCH RFC 2/8] arm64: stacktrace: Add arch_within_stack_frames He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 21:59   ` Kees Cook
2022-04-18 21:59     ` Kees Cook
2022-04-18 21:59     ` Kees Cook
2022-04-18 21:59     ` Kees Cook
2022-04-19 14:01     ` He Zhe [this message]
2022-04-19 14:01       ` He Zhe
2022-04-19 14:01       ` He Zhe
2022-04-19 14:01       ` He Zhe
2022-04-20  7:32       ` David Laight
2022-04-20  7:32         ` David Laight
2022-04-20  7:32         ` David Laight
2022-04-20  7:32         ` David Laight
2022-04-19 14:40   ` Mark Rutland
2022-04-19 14:40     ` Mark Rutland
2022-04-19 14:40     ` Mark Rutland
2022-04-19 14:40     ` Mark Rutland
2022-04-21  9:20     ` He Zhe
2022-04-21  9:20       ` He Zhe
2022-04-21  9:20       ` He Zhe
2022-04-21  9:20       ` He Zhe
2022-04-18 13:22 ` [PATCH RFC 3/8] arm64: stacktrace: Make callbacks use new prototype with frame info He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22 ` [PATCH RFC 4/8] powerpc: " He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22 ` [PATCH RFC 5/8] riscv: " He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22 ` [PATCH RFC 6/8] s390: " He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22 ` [PATCH RFC 7/8] x86: " He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22 ` [PATCH RFC 8/8] lkdtm: usercopy: Make USERCOPY_STACK_FRAME_x able to work for all archs He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe
2022-04-18 13:22   ` He Zhe

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=b328bed3-ebb9-6fba-9585-79946262c40f@windriver.com \
    --to=zhe.he@windriver.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mark.rutland@arm.com \
    --cc=namhyung@kernel.org \
    --cc=paulus@samba.org \
    --cc=svens@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --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.