From: Mark Rutland <email@example.com> To: Kees Cook <firstname.lastname@example.org> Cc: Thomas Gleixner <email@example.com>, Elena Reshetova <firstname.lastname@example.org>, email@example.com, Andy Lutomirski <firstname.lastname@example.org>, Peter Zijlstra <email@example.com>, Catalin Marinas <firstname.lastname@example.org>, Will Deacon <email@example.com>, Alexander Potapenko <firstname.lastname@example.org>, Ard Biesheuvel <email@example.com>, Jann Horn <firstname.lastname@example.org>, "Perla, Enrico" <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH v2 5/5] arm64: entry: Enable random_kstack_offset support Date: Thu, 26 Mar 2020 11:15:21 +0000 [thread overview] Message-ID: <20200326111521.GA72909@C02TD0UTHF1T.local> (raw) In-Reply-To: <202003251319.AECA788D63@keescook> On Wed, Mar 25, 2020 at 01:22:07PM -0700, Kees Cook wrote: > On Wed, Mar 25, 2020 at 01:21:27PM +0000, Mark Rutland wrote: > > On Tue, Mar 24, 2020 at 01:32:31PM -0700, Kees Cook wrote: > > > Allow for a randomized stack offset on a per-syscall basis, with roughly > > > 5 bits of entropy. > > > > > > Signed-off-by: Kees Cook <firstname.lastname@example.org> > > > > Just to check, do you have an idea of the impact on arm64? Patch 3 had > > figures for x86 where it reads the TSC, and it's unclear to me how > > get_random_int() compares to that. > > I didn't do a measurement on arm64 since I don't have a good bare-metal > test environment. I know Andy Lutomirki has plans for making > get_random_get() as fast as possible, so that's why I used it here. Ok. I suspect I also won't get the chance to test that in the next few days, but if I do I'll try to share the results. My concern here was that, get_random_int() has to grab a spinlock and mess with IRQ masking, so has the potential to block for much longer, but that might not be an issue in practice, and I don't think that should block these patches. > I couldn't figure out if there was a comparable instruction like rdtsc > in aarch64 (it seems there's a cycle counter, but I found nothing in > the kernel that seemed to actually use it)? AArch64 doesn't have a direct equivalent. The generic counter (CNTxCT_EL0) is the closest thing, but its nominal frequency is typically much lower than the nominal CPU clock frequency (unlike TSC where they're the same). The cycle counter (PMCCNTR_EL0) is part of the PMU, and can't be relied on in the same way (e.g. as perf reprograms it to generate overflow events, and it can stop for things like WFI/WFE). Thanks, Mark.
next prev parent reply other threads:[~2020-03-26 11:15 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-24 20:32 [PATCH v2 0/5] Optionally randomize kernel stack offset each syscall Kees Cook 2020-03-24 20:32 ` [PATCH v2 1/5] jump_label: Provide CONFIG-driven build state defaults Kees Cook 2020-03-24 22:06 ` Peter Zijlstra 2020-03-24 20:32 ` [PATCH v2 2/5] init_on_alloc: Unpessimize default-on builds Kees Cook 2020-03-26 15:48 ` Alexander Potapenko 2020-03-24 20:32 ` [PATCH v2 3/5] stack: Optionally randomize kernel stack offset each syscall Kees Cook 2020-03-30 11:25 ` Mark Rutland 2020-03-30 18:18 ` Kees Cook 2020-03-30 18:27 ` Kees Cook 2020-03-24 20:32 ` [PATCH v2 4/5] x86/entry: Enable random_kstack_offset support Kees Cook 2020-03-28 22:26 ` Kees Cook 2020-03-24 20:32 ` [PATCH v2 5/5] arm64: entry: " Kees Cook 2020-03-25 13:21 ` Mark Rutland 2020-03-25 20:22 ` Kees Cook 2020-03-26 11:15 ` Mark Rutland [this message] 2020-03-26 16:31 ` Kees Cook 2020-03-30 11:26 ` Mark Rutland 2020-04-20 20:54 ` Will Deacon 2020-04-20 22:34 ` Kees Cook 2020-04-21 7:02 ` Will Deacon 2020-03-24 21:28 ` [PATCH v2 0/5] Optionally randomize kernel stack offset each syscall Jann Horn 2020-03-24 23:07 ` Kees Cook 2020-03-25 12:15 ` Reshetova, Elena 2020-03-25 20:27 ` Kees Cook 2020-03-25 23:20 ` Jann Horn 2020-03-26 17:18 ` Kees Cook
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=20200326111521.GA72909@C02TD0UTHF1T.local \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v2 5/5] arm64: entry: Enable random_kstack_offset support' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).