Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory safety for web fonts

developer.chrome.com

Post reply on HN
Print view View original

71–80 of 230 posts

Re: Memory safety for web fonts

#71

Post by steveklabnik »

EE84M3i wrote: post #52
steveklabnik wrote: post #33

Earlier quoted context omitted.

Yes, these issues are real, but as you say, it's not really the same as UB. As such, Go is generally considered a MSL. For anyone not familiar with this, see https://go.dev/ref/mem#restrictions Incidentally, Java is very similar: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...

It's been quite a while since I worked with golang details but I seem to remember writes to the same map from multiple goroutines being UB if GOMAXPROCS>1? Did they eventually solve that, or is that excluded from the definition of memory-safe language because it's a different type of safety?

I believe that post 1.6, the runtime will try and detect this, but it's not my area of expertise.

Re: Memory safety for web fonts

#72

Post by RKFADU_UOFCCLEL »

SquareWheel wrote: post #25

I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…

Windows has always allowed you to change subpixel layout, its right there in the clear type settings.

Re: Memory safety for web fonts

#73

Post by pradn »

declan_roberts wrote: post #8

> Merely keeping up with the stream of issues found by fuzzing costs Google at least 0.25 full time software engineers I like this way of measuring extra work. Is this standard at Google?

Yes, a SWE-year is a common unit of cost.

And there are internal calculators that tell you how much CPU, memory, network etc a SWE-year gets you. Same for other internal units, like the cost of a particular DB.

This allows you to make time/resource tradeoffs. Spending half an engineer’s year to save 0.5 SWE-y of CPU is not a great ROI. But if you get 10 SWE out of it, it’s probably a great idea.

I personally have used it to argue that we shouldn’t spend 2 weeks of engineering time to save a TB of DB disk space. The cost of the disk comes to less than a SWE-hour per year!

Re: Memory safety for web fonts

#74

Post by steveklabnik »

ameliaquining wrote: post #68
steveklabnik wrote: post #33

Earlier quoted context omitted.

Yes, these issues are real, but as you say, it's not really the same as UB. As such, Go is generally considered a MSL. For anyone not familiar with this, see https://go.dev/ref/mem#restrictions Incidentally, Java is very similar: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...

IIUC word tearing in Java cannot cause arbitrary memory corruption. Any read is guaranteed to see either the old value, or the new value, or half of each. Since these are just numbers we're talking about, not pointers, and the language doesn't otherwise allow memory-unsafe things like pointer arithmetic, a data race resulting in word tearing in Java can at worst result in a runtime crash or a logic bug, not arbitrary…

Yes, you are correct that Java's guarantee is stronger.

> By contrast, in Go, all it takes to cause full-blown undefined behavior, in the same sense as C or C++ or Rust

It's a little more tricky than that. UB in C/C++/Rust is something that the compiler can use to transform the code. This can lead to other issues. Go's compiler will not do those kinds of things. So on one hand, yes, it can lead to arbitrary Bad Things, but on the other hand, it is different.

> Maybe it's the same in Go.

I was having a discussion about this topic last week, regarding Uber's paper from a few years back trying to analyze the prevalence of these issues: https://news.ycombinator.com/item?id=43336293 You'll notice the person replying to me has pointed out some additional mitigations that have happened since.

Re: Memory safety for web fonts

#75

Post by wiredfool »

kiicia wrote: post #54
Ono-Sendai wrote: post #31

FreeType is a dinosaur that should be replaced regardless of Rust or not.

It already is replaced by HarfBuzz https://harfbuzz.github.io

Harfbuzz is designed to run on top of the FreeType Renderer. https://harfbuzz.github.io/what-does-harfbuzz-do.html

Re: Memory safety for web fonts

#76

Post by hombre_fatal »

graemep wrote: post #67
jasonthorsness wrote: post #51

Earlier quoted context omitted.

I sort of have this perspective, slowly changing… I think it comes from a fallacy of take a small 20-line function in C, it can be made bug-free and fully tested, a program is made of small functions, why can’t the whole thing be bug free? But somehow it doesn’t work like that in the real world.

There would be far fewer bugs if people actually stick to writing code like that. I once had to reverse engineer (extract the spec from the code) a C++ function that was hundreds of lines long. I have had to fix a Python function over a thousand lines long. I am sure the people who wrote that code will find ways to make life difficult with Rust too, but I cannot regret having one less sharp knife in their hands.

On the other hand, parceling a large function into smaller functions can create indirection that is even harder to follow and harder to verify as bug-free.

Re: Memory safety for web fonts

#77

Post by dpe82 »

jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

C and modern C++ are so different that lumping them together in a blanket assertion doesn't really carry much meaning.

Re: Memory safety for web fonts

#79

Post by steveklabnik »

dpe82 wrote: post #77
jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

C and modern C++ are so different that lumping them together in a blanket assertion doesn't really carry much meaning.

It is true that they are different, but also, given the significant overlap between the two, people will reasonably talk about them together.

Re: Memory safety for web fonts

#80

Post by pcwalton »

steveklabnik wrote: post #33
gpm wrote: post #26

Earlier quoted context omitted.

I'd argue technically not due to data races on interface values, maps, slices, and strings... but close enough for almost all purposes. PS. Note that unlike most languages, a datarace on something like an int in go isn't undefined behavior, just non-deterministic and discouraged.

Yes, these issues are real, but as you say, it's not really the same as UB. As such, Go is generally considered a MSL. For anyone not familiar with this, see https://go.dev/ref/mem#restrictions Incidentally, Java is very similar: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...

Java only has tearing for double and long, which are POD types and so are irrelevant to memory safety. Go has tearing for pointer-like objects (interfaces, slices), which causes the memory safety problems.

Data races on those pointer-like objects are undefined behavior in Go, whereas there isn't something comparable in Java. The reason why Go is considered a memory safe language is actually pretty mundane: it's simply that the data race issues are pretty hard to exploit in practice for a variety of reasons.

Post reply on HN