From: Mark Rutland <mark.rutland@arm.com> To: Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de>, Elena Reshetova <elena.reshetova@intel.com>, x86@kernel.org, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Alexander Potapenko <glider@google.com>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, Jann Horn <jannh@google.com>, "Perla, Enrico" <enrico.perla@intel.com>, kernel-hardening@lists.openwall.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 5/5] arm64: entry: Enable random_kstack_offset support Date: Thu, 26 Mar 2020 11:15:21 +0000 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 <keescook@chromium.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 index 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 \ --to=mark.rutland@arm.com \ --cc=ard.biesheuvel@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=elena.reshetova@intel.com \ --cc=enrico.perla@intel.com \ --cc=glider@google.com \ --cc=jannh@google.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=luto@kernel.org \ --cc=peterz@infradead.org \ --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
Kernel-hardening Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/kernel-hardening/0 kernel-hardening/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 kernel-hardening kernel-hardening/ https://lore.kernel.org/kernel-hardening \ kernel-hardening@lists.openwall.com public-inbox-index kernel-hardening Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/com.openwall.lists.kernel-hardening AGPL code for this site: git clone https://public-inbox.org/public-inbox.git