This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/4] S390: Use own tbegin macro instead of __builtin_tbegin.
On 01/13/2017 04:32 PM, Torvald Riegel wrote:
On Fri, 2017-01-13 at 15:50 +0100, Florian Weimer wrote:
On 01/13/2017 12:28 PM, Torvald Riegel wrote:
On Thu, 2017-01-12 at 16:45 +0100, Florian Weimer wrote:
On 01/10/2017 05:34 PM, Torvald Riegel wrote:
(2) This introduces a facility to probe memory for being accessible or
not, considering that you say it masks segfaults. It seems that this
probing may not be visible to the same extent as possible if a signal
handler were installed. Is this relevant from a security perspective?
If the fallback implementation has essentially the same behavior, I
don't think there is a transaction-specific security problem.
We don't know what the fallback implementation in the user code does.
It can detect whether it is running in a HW transaction and run
different code depending on that.
Yes, the user can detect if it is running within a transaction (e.g.
with the __builtin_tx_nesting_depth like used in elision_trylock).
With non transactional stores, he could also store something even if the
transaction aborts.
Is this really supported? I assumed that if you acquire a lock (which
might use elision), hardware transactions are off limits because glibc
might require their use internally.
If someone starts a transaction within a transaction, then the nesting
depth is incremented. If the outermost transaction is ended, the changes
are committed.
You can check whether you run in a transaction. That's no guarantee
that that transaction has been started by the elision code, but you can
check that nonetheless.
HW transactions must be usable regardless of whether something else uses
elision or not. One of course shouldn't just commit transactions that
one did not start, though.
You are right, but this is possible.
Anyway, I'm not sure whether this gives user code more means to exploit
or probe something, or not. Maybe I was just too cautious here.
That's correct, you can probe something.
But if someone wants to do that, he can also start a transaction
directly without pthread_mutex_lock.