[sldev] How Far For Security?

[Lawson English]

Argent Stonecutter 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?
>
> There's no solid engineering reason to go with a standard file format 
> for a *cache*.
>
>> 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.
>
> I happen to agree that there's probably no need for obfuscation beyond 
> just not using a standard format, I proposed XOR as the cheapest 
> possible concession to obfuscation, and I'm not going to argue hard at 
> all to keep it... but there's no need to make up arguments like that 
> against it, because there's all KINDS of problems that have to be 
> solved to get anywhere near that kind of solution. Is there even a 
> usermode API for that in any modern OS, or would you have to ship 
> device drivers with SL and make SL bypass local user permissions in 
> the OS?

Given The low-end for the GPU is a Geforce 2, you'd have to decide what 
facilities were available for that level.

And I think deliberate low-level obfuscation should take a backburner to 
improvements in speed. It may turn out that the most effective simple 
optimizations for texture-handling in the cache will provide sufficient 
"bozo-bit" type obfuscation (for those that remember the file flag in 
the original Mac OS that simply told the GUI to not allow drag copying 
of files via file icons) that we need not worry about it at all. All we 
need, is a way to make it non-transparent to casual explorers, how to 
extract the textures. Anything more than that will be a losing battle 
because there's always someone who will be willing to create a utility 
to break the "copy protection," no matter how involved we're willing to 
get. If our simple "protection scheme" actually results in a speedup of 
the system, so much the better and I think THAT should be the go: 
optimize the cache handling in the best way we can find without getting 
TOO fancy (because that becomes system-dependent, and keep an eye out 
for viable solutions that add a tad of obfuscation while we're at it.

My intuition says we'll probably find that the best optimization 
solution will provide the desired level of obfuscation as a side-effect.


Lawson