linux-kernel - Re: Reconciling rcu_irq_enter()/rcu_nmi

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CALCETrX3Rb1tKAmD_FY3HYUNb9QrCG1b0rBs5ufsQsotoRZF5A@mail.gmail.com>
Date:	Fri, 17 Jul 2015 15:45:18 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc:	Sasha Levin <sasha.levin@...cle.com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>, X86 ML <x86@...nel.org>,
	Rik van Riel <riel@...hat.com>
Subject: Re: Reconciling rcu_irq_enter()/rcu_nmi_enter() with context tracking

On Fri, Jul 17, 2015 at 2:22 PM, Paul E. McKenney
<paulmck@...ux.vnet.ibm.com> wrote:
> And please see attached for an in-process LWN article on RCU's requirements.
> If you get a chance to look it over, I would value any feedback that you
> might have.
>

Sure.  Nice article!

I found the add_gp_buggy thing a bit confusing.  What's the rcu reader
doing?  What's the rcu_access_pointer for?  You have a spinlock for
the updater.

You reference remove_gp_synchronous before you define it.

You say:

Quick Quiz 4: Without the rcu_dereference() or the
rcu_access_pointer(), what destructive optimizations might the
compiler make use of?

Answer: It could reuse a value formerly fetched from this same
pointer. It could also fetch the pointer from gp in a byte-at-a-time
manner, resulting in load tearing, in turn resulting a bytewise
mash-up of two distince pointer values. It might even use
value-speculation optimizations, where it makes a wrong guess, but by
the time it gets around to checking the value, an update has changed
the pointer to match the wrong guess. Too bad about any dereferences
that returned pre-initialization garbage in the meantime!

Doesn't the spinlock protect against that?

Requirement #2: you say "Each CPU that has an RCU read-side critical
section that ends after synchronize_rcu() returns is guaranteed to
execute a full memory barrier between the time that synchronize_rcu()
begins and the time that the RCU read-side critical section begins. "
Don't you mean an RCU read-side critical section that *starts* after
synchronize_rcu() returns?

Having read it: on x86 right now with nohz_full, a cpu can go into
user mode and come back without executing a full barrier (I think).
Certainly there's no such barrier in the entry code.  I don't know
what user_enter and user_exit do.  Is that okay?  The issue here is
that a SYSRET/SYSCALL pair doesn't serialize or enforce any ordering
whatsoever.  I got Intel to promise that SYSCALL will always force a
TSX abort [1], but that's about it.

For timer-driven idle/user detection, we're fine: IRET is serializing.
However, there are a couple of kernels in which we don't promise to
IRET after an IRQ.

This also reminds me: we really really need task switches to be full
barriers in general.  Otherwise store forwarding can bite
otherwise-correct code on x86.

s/Guaranteed Unconditional/Guaranteed Unconditionally/

[1] Because of an amusing possible attack.  If you attempt a TSX
transaction and it fails, you get to leak at least 8 bits out of the
aborted transaction.  If you manage to read /dev/urandom in a
transaction, you can abort the read and still know the random number.
Whoops!

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/