[sldev] How Far For Security?

[Nik Radford]

Callum Lerwick wrote:
> On Sat, Jun 21, 2008 at 3:14 PM, Argent Stonecutter 
> <secret.argent at gmail.com <mailto:secret.argent at gmail.com>> wrote:
>
>     On 2008-06-21, at 01:12, Callum Lerwick wrote:
>
>         I may be late to the party here, but mark my words, if the
>         cache is changed to anything other than plain, complete files
>         in a standard file format, it will be the final nail in the
>         coffin for my already tenuous faith in Linden Lab's collective
>         engineering sense.
>
>
>     Even if a non-standard format that's a serialization of the
>     internal structures is faster and more efficient?
>
>
> Until you have to change the internal structures and suddenly your 
> cache needs to be wiped and re-filled. Which would defeat the purpose 
> of the cache. To avoid this you have to abstract your internal 
> structures from the on disk format, and if you're going to do that, 
> you might as well use a pre-existing standard. There's plenty to 
> choose from already. And as noted, there's already TGA reading code in 
> the viewer.
>
>     There's no solid engineering reason to go with a standard file
>     format for a *cache*.
>
>
> Seriously, have we not been bitten by lack of engineering foresight in 
> SL infrastructure enough as it is?
>
> Why do I even have to explain this?
>
>         Also note, if we're going to do the uncompressed cache thing,
>         XORing the file will eliminate the possibility of zero-copy
>         DMAing of the texture directly from disk into VRAM. XOR is
>         still more overhead than having the texture not hit the
>         processor at all.\
>
>
>     The Amiga did MFM decoding on the blitter, and that had a fraction
>     of the versatility of any modern GPU, there's no reason that the
>     GPU can't do any operations needed to remove obfuscation.
>
>
> Except that programmable cards only do FP, not integer/binary 
> operations like XOR. And shaderless cards are still in wide use, not 
> to mention bugs in shader implementations are still widespread, and 
> the open source r300 drivers for one still don't support shaders.
>   
So XORing and image provides a minimal overhead and only has to be 
applied once per texture. Would that be so detrimental to performance. 
Surely you can understand why some obsfucation is needed even if it's 
minimal and can easily be broken by anyone with the inclination and will 
to do so?
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080622/f6ec78fe/attachment.htm