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

61–70 of 230 posts

Re: Memory safety for web fonts

#61

Post by cyberax »

kypro wrote: post #37
fresh_broccoli wrote: post #28

It's very annoying that Google's websites, including this blog, are automatically translated to my browser's preferred language. Sillicon Valley devs clearly believe that machine translation is a magical technology that completely solved internationalization, like in Star Trek. No, it's far from it. Ever since internet has been flooded with automatically translated garbage, the experience of international users, at l…

Wouldn't the alternative be worse for most people? If you're a global company it would be silly to assume all your readers speak/read a single language. AI translations (assuming that's what this is) are not perfect, but better than nothing. I get how poor translation could be irritating for bilingual people who notice the quality difference though, but I guess you guys have the advantage of being able to switch the…

I have `en-US` set as the second preference language, so just show me the content in `en-US` unless you have a real human-vetted translation into my primary language.

Re: Memory safety for web fonts

#62

Post by graemep »

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.

Not disagreeing but its not absolutely fresh - the library used was released more than an year ago, and its built on a low level library released three years ago.

Obviously a lot younger than Freetype.

It would also be a lot less important if we did not do silly things like loading fonts from random websites.

Re: Memory safety for web fonts

#63

Post by arccy »

kevingadd wrote: post #48
kiicia wrote: post #41

Earlier quoted context omitted.

The real issue is the effort required to rewrite everything without introducing new bugs resulting from a misunderstanding of the original code

New (likely aesthetic only) bugs in font rendering are probably considered preferable to existing security vulnerabilities, I would hope.

if you have too many aesthetic bugs, nobody will use it. it then becomes the most secure code because it doesn't run anywhere so can't be exploited.

Re: Memory safety for web fonts

#64

Post by steveklabnik »

cyberax wrote: post #60
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...

Java is not similar. It guarantees memory safety even for multithreaded code with data races. It can result in stack overflows, infinite loops, but not in memory corruption. That's not the case for Go, it's trivially easy to create memory corruption with multiple threads there.

"Similar" does not mean "the same," you are correct that Java's guarantee is stronger.

Re: Memory safety for web fonts

#65

Post by oergiR »

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.

FreeType was written when fonts were local, trusted, resources, and it was written in low-level C to be fast. The TrueType/OpenType format is also made for fast access, e.g. with internal pointers, making validation a pain.

So though FreeType is carefully written w.r.t. correctness, it was not meant to deal with malicious input and that robustness is hard to put in afterwards.

Re: Memory safety for web fonts

#66

Post by gpm »

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?

This is my understanding (both that that can occur, and that it does not count as memory safe).

I called out the types I did in my post specifically because they're the types where data races can result in arbitrary memory corruption (in the actual implementation, the spec is arguably not even that strict). Per https://go.dev/ref/mem#restrictions (the same linke as in Steve's reply to me)

Re: Memory safety for web fonts

#67

Post by graemep »

jasonthorsness wrote: post #51
cbdumas wrote: post #30

Earlier quoted context omitted.

Despite mounting evidence this perspective remains shockingly common. There seems to be some effect where one might convince oneself that while others are constantly introducing high severity bugs related to memory un-safety, I always follow best practices and use good tooling so I don't have that issue. Of course evidence continues to build that no tooling or coding practice eliminates the risk here. I think what's…

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.

Re: Memory safety for web fonts

#68

Post by ameliaquining »

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...

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 memory corruption.

By contrast, in Go, all it takes to cause full-blown undefined behavior, in the same sense as C or C++ or Rust, is accessing an interface/map/slice value in a racy way, not having the race detector on, and being sufficiently unlucky.

I agree that in practice this doesn't stop people from calling Go a memory-safe language. I think it's reasonable to argue that this statement is just wrong. That said, I think the Carbon people once said something along the lines of, in their experience, it's rare in practice for memory corruption bugs in C++ to be caused solely by data races. So a language that's memory-safe in single-threaded contexts, but where concurrency is not memory-safe, is "good enough". Maybe it's the same in Go.

I am still suspicious of this, though. Maybe it's just that concurrent operations are rarer in general because they're so famously hard to get right, and this makes it less likely that you'll have one that's exactly the right kind of wrong to cause memory corruption. Certainly it seems at odds with the notion that you want the exceptions to memory safety to be auditable.

Re: Memory safety for web fonts

#69

Post by hgs3 »

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.

Is the FreeType2 test suite public? It looks like the project's tests/ directory only contains a script for downloading a single font [1]. They have a fuzz test repo with what appears to be a corpus of only a few hundred tests [2]. For critical infrastructure, like FreeType, I'd expect hundreds of thousands if not millions of tests, just like SQLite [3].

[1] https://gitlab.freedesktop.org/freetype/freetype/

[2] https://github.com/freetype/freetype2-testing/

[3] https://www.sqlite.org/testing.html

Re: Memory safety for web fonts

#70

Post by tadfisher »

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…

The standard is EDID-DDDB, and subpixel layout is a major part of that specification. However I believe display manufacturers are dropping the ball here.

https://glenwing.github.io/docs/VESA-EEDID-DDDB-1.pdf

Post reply on HN