Rust anyone?
Serious Chrome zero-day
371–377 of 377 posts
Re: Serious Chrome zero-day
#372Earlier quoted context omitted.
Sorry. Until Go gets its head out of its ass and gets proper generics Go will still be painful to use and slow. Not to mention with all the extra code complexity from writing everything with interface{}{} and reflection there are bound to be plenty of exploitable vulnerabilities. I honestly think it is worse than pre-generic Java because switching over the type of the variable is encouraged. Most sane type-checked la…
Generics are slower, that's the trade-off. Developer time vs. execution time. Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.
>Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.
No, because Go really has its head up it's ass.
Re: Serious Chrome zero-day
#373Earlier quoted context omitted.
> where JIT compilers are designed to optimize away...bounds checks V8 does not optimize away bounds checks on array buffers. For one thing, array buffers can be detached, so their length can suddenly drop to zero.
It does for native arrays, at least: > This is the incorrect optimization we’re looking for. JavaScript array accesses are guarded by CheckBounds nodes, which ensure that the index falls within the array bounds. If the optimizer can determine statically that the index is always in-bounds, it can eliminate the CheckBounds node. Image tying the index to the result of Object.is: since the typing information is off, we c…
JavaScript arrays and ArrayBuffers are totally separate animals.
Re: Serious Chrome zero-day
#374Earlier quoted context omitted.
> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI. Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.
Go has a garbage collector, and it's the fastest garbage collector that currently exists, by a wide margin, I believe. When Go 1.8 released, it measured I don't believe that "it uses garbage collection" is a valid complaint against Go anymore, except in a real-time application, and I don't know of any real-time applications written in Go. I'm sure there are some, I just don't know of them.
Go's garbage collection is optimised for reducing GC pause times, and while it is extremely fast in this regard this is only one of many ways GC performance can be measured.
If for your workload GC pauses are tolerable and throughput is important (say when doing offline CPU bound batch processing) then the Go GC is not optimal for your use case and will be slower than other options on the market.
Some runtimes (such as the JVM) allow the user to pick from one of many GCs so that they can use the one that is most appropriate for their workload.
Re: Serious Chrome zero-day
#375Earlier quoted context omitted.
That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in…
> Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Yes, it is, because the language has the concept of safe code to begin with. The problem with C++ is that all C++ code could potentially be unsafe. > Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, u…
Yup, and besides, Go has the unsafe (https://golang.org/pkg/unsafe/) package, which allows for basically the same sort of unsafety as Rust's unsafe.
In fact, I would say Rust is typically more safe than Go, because in Rust you can mark any code as unsafe, it doesn't necessarily have to involve unsafe pointers. For example in Rust FFI functions are typically marked unsafe even if they don't involve pointers. There's no way to do that in Go.
Another example is strings: Rust ensures that strings are always valid UTF-8 by marking any function that could break that as unsafe. OTOH in Go you strings can contain invalid UTF-8 if I recall correctly.
Re: Serious Chrome zero-day
#376Earlier quoted context omitted.
> Remove V8's JIT and GC and then one can have a meaningful discussion about memory safe languages. But remove those and the vast majority of Chrome bugs would also disappear. Those are the places of highest complexity while also being the areas which no language offers any meaningful assistance. No, just no. The data just does not back this up. The vast majority of Chrome bugs are not due to the V8 JIT or GC. Full s…
Instead of "getting rid of C++" in a project written almost exclusively in C++, it would seem more sensible for Google to just wait for Firefox to be completely rewritten in Rust in the next ~10 years and if it's really that much better, fork it, add some googley stuff on top like user-tracking and mandatory log-in and then release it as the new Chrome.
Alternatively, since Rust natively interops with C and C++ pretty straightforwardly, it should be possible to write new components in something like Rust and opportunistically rewrite old components on an as-needed basis.
Re: Serious Chrome zero-day
#377Earlier quoted context omitted.
So it's possible that t1 < t0? Because something might had been exploited before whatever time is taken as the official "discovery date".
I assume it is 0day irrespective of who discovered it. It remains 0day until an action is taken to mitigate it. So you have 0day exploits being traded on various markets - those are exploits which are known to certain groups, but the affected party hasn't yet taken action to mitigate them (most likely because they don't know).
That's slightly inconsistent with the OP's interpretation because the vulnerability would be traded so it could be exploited (presumably), but by the OP's definition that would make it no longer be a 0day.