On 4/23/14 6:06 PM, Boris Zbarsky wrote:
On 4/23/14, 8:53 PM, Brian Anderson wrote:
We're assuming nobody is going to be attacking Rust symbols though
Oh, right, that's the other worry.
We've had security issues in the past due to things like <input
type="fİle"> being treated as a file input by some parts of the system
but not others. So anything that allows collisions between
user-provided things and built-in atoms for attribute names and values
is bad.
On the bright side, it may be possible to enforce that all built-in
atoms are under the 16 char limit and hence not susceptible to collisions.
Disclaimer: I am not a cryptographer; please correct me mercilessly.
A collision in a widely used cryptographic hash would be a major,
publishable security advance. SipHash was concerned with attacks that
could somehow exploit the properties of `hash(message) %
hash_table_size`, but we're taking the whole hash here. So I don't think
that would be an issue. (We could mix in a secret, per-browser-session
nonce if we were really paranoid, but since collisions are a death
sentence for cryptographic hashes in the first place it's likely overkill.)
I'm more concerned about the potential impact of a large hash on memory
bandwidth (e.g. if we want to match multiple selectors in parallel using
SIMD), but I haven't had a whole lot of luck with techniques that would
benefit from that anyhow. So I'm totally fine with this move, assuming
its performance characteristics are otherwise favorable; best not to
hold up things that we know *do* provide benefits in favor of nebulous
performance concerns for algorithms we don't know how to make work in
the first place.
As an added note, looks like Skylake is going to have SHA instructions
[1]. Based on my experience with AES-NI I wouldn't be surprised if using
these instructions ends up faster than interning in software anyway.
Patrick
[1]: http://en.wikipedia.org/wiki/Intel_SHA_extensions
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
