[PATCH 2/4] S390: Use own tbegin macro instead of __builtin_tbegin.

[Stefan Liebler]

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.