| 1 |
On Tue, 13 Dec 2005, Mark Loeser wrote: |
| 2 |
|
| 3 |
> Basically what I'm looking for here is an easy to understand explanation of |
| 4 |
> what textrels are, why they are bad, and why they should hold back marking a |
| 5 |
> package stable. The only information I've been able to find states that they |
| 6 |
> could cause a performance hit, but this doesn't seem to warrant banning them |
| 7 |
> completely in my eyes. |
| 8 |
|
| 9 |
Given my limited knowledge on this, this is my understanding. |
| 10 |
|
| 11 |
TEXTRELS are basically text relocations. What this is, is relocation |
| 12 |
within the text segment of the process image. This brings up the |
| 13 |
question of what a relocation is. A relocation is simply the |
| 14 |
replacement of some text with a memory location. The big issue with |
| 15 |
this is that the text segment is usually suppose to be read only for |
| 16 |
security reasons. But because the text segment needs a relocation, it |
| 17 |
needs to be read-write since the relocation happens at runtime |
| 18 |
dynamically. The constant need to look up the address is what causes |
| 19 |
the performance degredation. The performance degredation however is of |
| 20 |
no worry to us. The issue is that since the text segment is now |
| 21 |
read-write, the image of the process is no longer guaranteed to remain |
| 22 |
the same as it can be overwritten (allowing code modifications at |
| 23 |
runtime which can happen other ways as well). Because of this, the |
| 24 |
application is far more vurnerable to arbitrary code execution as if an |
| 25 |
exploit manages to overwrite the text segment properly, it can execute |
| 26 |
code that it wants. |
| 27 |
|
| 28 |
I am not sure how correct this explanation is or it is even what you |
| 29 |
were looking for. |
| 30 |
|
| 31 |
> Getting a clear cut policy on exactly what issues should hold a package back |
| 32 |
> from being marked stable is what I'm looking for. Issues like textrels, |
| 33 |
> executable stacks, etc is what I'm looking for to be defined and explained why |
| 34 |
> we are to always avoid them. This should be added to existing documentation |
| 35 |
> policy so it is somewhere for new devs to know about, and existing devs to |
| 36 |
> have for a reference. |
| 37 |
|
| 38 |
I agree, this would be very nice to have. It would make stabilization |
| 39 |
of packages a little bit easier. |
| 40 |
|
| 41 |
|
| 42 |
Thanks. |
| 43 |
|
| 44 |
Saleem Abdulrasool |
| 45 |
compnerd (at) gentoo (dot) org |
Archives