On Mon, Oct 30, 2017 at 9:22 PM, Steven Rostedt wrote:
> How quickly do you need static_branch_disable() executed? You could
> always pass the work off to a worker thread (that can schedule).
>
> random_ready_callback -> initiates worker thread -> enables the static branch
I had already suggested
On Mon, Oct 30, 2017 at 04:22:44PM -0400, Steven Rostedt wrote:
> On Wed, 25 Oct 2017 14:49:34 +1100
> "Tobin C. Harding" wrote:
> >
> > First, the static_key stuff.
> >
> > DEFINE_STATIC_KEY_TRUE(no_ptr_secret) : Doesn't sleep, just a
> > declaration.
> >
> > if (static_branch_unlikely(&no_pt
On Wed, 25 Oct 2017 14:49:34 +1100
"Tobin C. Harding" wrote:
>
> First, the static_key stuff.
>
> DEFINE_STATIC_KEY_TRUE(no_ptr_secret) : Doesn't sleep, just a
> declaration.
>
> if (static_branch_unlikely(&no_ptr_secret)) {} : Doesn't sleep, just
> some assembler to jump to returning true or
On Thu, Oct 26, 2017 at 09:00:03AM +0200, Greg KH wrote:
> On Thu, Oct 26, 2017 at 12:59:08AM +0200, Jason A. Donenfeld wrote:
> > On Thu, Oct 26, 2017 at 12:27 AM, Tobin C. Harding wrote:
> > > How good is unlikely()?
> >
> > It places that branch way at the bottom of the function so that it's
>
On Thu, Oct 26, 2017 at 12:59:08AM +0200, Jason A. Donenfeld wrote:
> On Thu, Oct 26, 2017 at 12:27 AM, Tobin C. Harding wrote:
> > How good is unlikely()?
>
> It places that branch way at the bottom of the function so that it's
> less likely to pollute the icache.
But always measure it. Lots o
On Thu, Oct 26, 2017 at 12:59:08AM +0200, Jason A. Donenfeld wrote:
> On Thu, Oct 26, 2017 at 12:27 AM, Tobin C. Harding wrote:
> > How good is unlikely()?
>
> It places that branch way at the bottom of the function so that it's
> less likely to pollute the icache.
>
> > It doesn't _feel_ right
On Thu, Oct 26, 2017 at 12:27 AM, Tobin C. Harding wrote:
> How good is unlikely()?
It places that branch way at the bottom of the function so that it's
less likely to pollute the icache.
> It doesn't _feel_ right adding a check on every call to printk just to
> check for a condition that was on
On Wed, Oct 25, 2017 at 06:00:21AM +0200, Jason A. Donenfeld wrote:
> On Wed, Oct 25, 2017 at 5:49 AM, Tobin C. Harding wrote:
> > static_branch_disable(&no_ptr_secret) : Doesn't sleep, just atomic read
> > and set and maybe a WARN_ONCE.
>
> Are you sure about that? I just looked myself, and thou
On Wed, Oct 25, 2017 at 09:02:34PM +0200, Rasmus Villemoes wrote:
> On 25 October 2017 at 01:57, Tobin C. Harding wrote:
> > On Tue, Oct 24, 2017 at 09:25:20PM +0200, Rasmus Villemoes wrote:
> >>
> >> I haven't followed the discussion too closely, but has it been
> >> considered to exempt NULL fro
On 25 October 2017 at 01:57, Tobin C. Harding wrote:
> On Tue, Oct 24, 2017 at 09:25:20PM +0200, Rasmus Villemoes wrote:
>>
>> I haven't followed the discussion too closely, but has it been
>> considered to exempt NULL from hashing?
>
[snip]
>
> The code in question is;
>
> static noinline_for_sta
On Wed, Oct 25, 2017 at 06:00:21AM +0200, Jason A. Donenfeld wrote:
> On Wed, Oct 25, 2017 at 5:49 AM, Tobin C. Harding wrote:
> > static_branch_disable(&no_ptr_secret) : Doesn't sleep, just atomic read
> > and set and maybe a WARN_ONCE.
>
> Are you sure about that? I just looked myself, and thou
On Wed, Oct 25, 2017 at 5:49 AM, Tobin C. Harding wrote:
> static_branch_disable(&no_ptr_secret) : Doesn't sleep, just atomic read
> and set and maybe a WARN_ONCE.
Are you sure about that? I just looked myself, and though there is a
!HAVE_JUMP_LABEL ifdef that does what you described, there's als
On Tue, Oct 24, 2017 at 01:25:52PM +0200, Jason A. Donenfeld wrote:
> On Tue, Oct 24, 2017 at 2:31 AM, Tobin C. Harding wrote:
> > On Tue, Oct 24, 2017 at 01:00:03AM +0200, Jason A. Donenfeld wrote:
> >> Provided you've tested this and the static_key guard stuff actually
> >> works as intended,
>
On Tue, Oct 24, 2017 at 01:25:52PM +0200, Jason A. Donenfeld wrote:
> On Tue, Oct 24, 2017 at 2:31 AM, Tobin C. Harding wrote:
> > On Tue, Oct 24, 2017 at 01:00:03AM +0200, Jason A. Donenfeld wrote:
> >> Provided you've tested this and the static_key guard stuff actually
> >> works as intended,
>
On Tue, Oct 24, 2017 at 2:31 AM, Tobin C. Harding wrote:
> On Tue, Oct 24, 2017 at 01:00:03AM +0200, Jason A. Donenfeld wrote:
>> Provided you've tested this and the static_key guard stuff actually
>> works as intended,
>
> I tested by inserting a simple module that calls printf() with a bunch of
On Tue, Oct 24, 2017 at 01:00:03AM +0200, Jason A. Donenfeld wrote:
> Provided you've tested this and the static_key guard stuff actually
> works as intended,
I tested by inserting a simple module that calls printf() with a bunch of
different specifiers. So it's tested but not stress tested. Some
Provided you've tested this and the static_key guard stuff actually
works as intended, for the crypto/rng/siphash aspects:
Reviewed-by: Jason A. Donenfeld
Currently there are many places in the kernel where addresses are being
printed using an unadorned %p. Kernel pointers should be printed using
%pK allowing some control via the kptr_restrict sysctl. Exposing addresses
gives attackers sensitive information about the kernel layout in memory.
We can
18 matches
Mail list logo
