Re: [PATCH v1 7/10] Uprobes Implementation

[Srikar Dronamraju <srikar@linux.vnet.ibm.com>]

 
> > > > > One thing I would like to see is a slot per task, that has a number of
> > > > > advantages over the current patch-set in that it doesn't have one page
> > > > > limit in number of probe sites, nor do you need to insert vmas into each
> > > > > and every address space that happens to have your DSO mapped.
> > > > > 
> > > > 
> > > > where are the per task slots stored?
> > > > or Are you looking at a XOL vma area per DSO?
> > > 
> > > The per task slot (note the singular, each task needs only ever have a
> > > single slot since a task can only ever hit one trap at a time) would
> > > live in the task TLS or task stack.
> > > 
> > 
> > Do we need a buy-in from glibc folks to do this?
> > Also here is what Roland had once said about TLS.
> > 
> > "Next we come to the problem of where to store copied instructions for
> > stepping.  The idea of stealing a stack page for this is a non-starter.
> > For both security and robustness, it's never acceptable to introduce a
> > user mapping that is both writable and executable, even temporarily.  We
> > need to use an otherwise unused page in the address space, that will be
> > read/execute only for the user, we can write to it only from kernel
> > mode."
> 
> Before NX there simply was no option, anyway, I guess the writable
> requirement comes from being stack, and I'm not sure how TLS is done,
> but I guess that has similar constraints on being writable, right?
> 
> I've heard from people that some other OS does indeed have the
> trampoline in TLS.

Ulrich, 

Can you please comment if a slot in TLS can be used for storing and
executing an instruction? Are there any additional issues that we need
to take care of? Are there architectures that dont support TLS?

--
Thanks and Regards
Srikar