This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.
> 
> 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.

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.

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]