lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 10 Aug 2014 23:32:31 -0400
From:	Jason Baron <>
To:	Borislav Petkov <>, Ingo Molnar <>
CC:	x86-ml <>, lkml <>,
	Peter Zijlstra <>,
	Steven Rostedt <>,
	Thomas Gleixner <>,
	Linus Torvalds <>,
	Andrew Morton <>
Subject: Re: [RFC PATCH] Flipped jump labels

On 08/10/2014 12:07 PM, Borislav Petkov wrote:
> On Sun, Aug 10, 2014 at 05:45:15PM +0200, Ingo Molnar wrote:
>> Indeed - but could we use that interface to cleanly expose the
>> arch_static_branch_active() code you've written, or do we need new
>> variants?
> We could probably.
> The thing is, if we want to do the _active thing, the whole jump labels
> infrastructure would need to know about those, let's call them "new
> types" because they'd need different handling when enabling - see
> __jump_label_transform() in arch/x86/kernel/jump_label.c with all the
> NOP checks.
> Which begs the more important question: is adding those just to save us
> a JMP penalty justify the additional code complexity. Frankly, I'm still
> on the fence here and I'd rather do some perf measurements of a kernel
> build with and without the JMP in native_sched_clock() to see whether it
> is even noticeable or it disappears in the noise.
> Because if it does disappear, the whole trouble is just for nothing.
> Thanks.

That is correct. We don't currently support having the default
branch direction or the fast path be different from how the
'static_key' is initialized.

If I understand your use-case correctly,  you can't have the tsc
path be the default *before* tsc_init() is called?

If not, another thought on the implementation here might be
to re-visit the work the Steven Rostedt  proposed a while back,
to use jump instead of no-ops by default, and then convert
the jumps to no-ops in a post-processing phase in order to
reduce code size (by having 2-byte jumps for example on
x86). Potentially, we could then avoid converting some of the
jumps, if they didn't match the default branch direction.

In that way there is no API change, we are just relaxing the
restriction that the default branch direction must match the
way that the keys are initialized.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists