5 ms·

Another comment brough up memory safety. I'm surprised myself that the project is moving forward without using a memory safe language at its core. A browser is

by loufe 2y ago

Another comment brough up memory safety. I'm surprised myself that the project is moving forward without using a memory safe language at its core. A browser is a huge attack surface and all the example I know point to a necessarily enormous code base. I understand the project started as a hobby, and anyone who wishes to be involved has their own prerogative, but I'd have a hard time getting behind it myself.

amelius 2y ago
A memory safe language may force you to think about memory safety, but it can also work as a straightjacket that makes it more difficult to think about other security issues.
- timeon 2y ago
  Seems other way around. Since you can focus more on other security issues instead of memory safety and other security.
  - amelius 2y ago
    No, because the memory safety part comes at a cognitive cost. You may be right if you're talking about a GC'ed language, which gives memory safety and at the same time frees up the developer's mind. But if you're talking about constructs like borrow checkers then they do add cognitive load that is perhaps better spent elsewhere.
- bennettnate5 2y ago
  I've not found this to be my experience; if anything, working in Rust has freed me to think about other aspects of security in my project since I don't need to spend all my effort applying extra tools to find segfaults. Do you have an example?
eknkc 2y ago
All the major operating systems these browsers are running on, are written in c and c++. How can you have a real memory safe application when the memory itself is managed by a shit ton of code written in an unsafe language?
- parl_match 2y ago
  > How can you have a real memory safe application when the memory itself is managed by a shit ton of code written in an unsafe language? It turns out actually pretty effectively? There are going to be more bugs and boundary issues of the OS, but memory unsafety isn't some goop that oozes into your runtime.
  - dmurray 2y ago
    Right, or equivalently, you can rely on the million eyeballs and the million developer-years poured into those OSes, while developing your project with a much smaller team.
  - eknkc 2y ago
    Yeah just a hyperbole. My point is, people act like anything built with non memory safe languages is shit ever since Rust became the Jesus. We have the actual operating systems written in C, working ok. It is fine. Yeah maybe Rust would be better but it is not a magic bullet and memory safety comes with many caveats in design of the code and possible performance issues when you are building something low level like a browser.
    - deleted 2y ago
      [deleted]
- Sayrus 2y ago
  In many cases, you'd need to escape the browser before exploiting the OS itself. Security is not an all or nothing, layers and layers are effective at mitigating or increasing the time it takes for exploit to work. For instance ASLR is absolutely not a bulletproof solution, but many exploits are order of magnitude more complex to execute when enabled. In addition to that, the browser is executing third-party code all the time while making it a good point of entry.
  - eknkc 2y ago
    My remark was a little more abstract and frankly, absurd though. I mean, the most memory safe language will invoke syscalls. It will ask for memory pages and stuff. If we assume the app is running on a pile of shit because the OS is written in C, how can we be sure that the language is memory safe? I understand the value of memory safe languages but people bashing on C/C++ code does not make sense to me when everything is essentially running on C. That’s all. > In addition to that, the browser is executing third-party code all the time while making it a good point of entry. This made me curious about something. Has there been many exploits stemming from JavaScript engines? I honestly do not know but as far as I can tell, most of the issues originate from faulty image decoders screwing up memory and tls implementations etc.
lkdfjlkdfjlg 2y ago
Do you know that memory safety is relevant for security, compared to other causes of exploits? Or are you just guessing?
- mkopinsky 2y ago
  The developer of curl has done an analysis of what percent of his CVEs would have been avoided in a memory safe language. I think the answer was a bare majority.
- lolinder 2y ago
  As a very relevant example, Chrome found that 70% of their serious security bugs were memory safety bugs. 36% of them were use-after-free. https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
- ethanol 2y ago
  It's been discussed at length multiple times. This should be enough to get you started on further research: https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/ https://msrc.microsoft.com/blog/2019/07/a-proactive-approach... > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues
lgg 2y ago
From https://ladybird.org https://ladybird.org (not some subpage, but literally on the main page): Why build a new browser in C++ when safer and more modern languages are available? Ladybird started as a component of the SerenityOS hobby project, which only allows C++. The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain. However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect. We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages.
- deleted 2y ago
  [deleted]
pizlonator 2y ago
It’s not as simple as “just” using a memory safe language. The languages that are memory safe either impose too much of a straightjacket to be productive (Rust), don’t give you a GC or a memory safe way of writing one (Swift, Rust), or give you a GC with the wrong semantics (Java, Go, etc). Yes, the browser needs to have a GC. No, there’s no way around that. I’m not saying it can’t be done - but there are good reasons to stick with C++ to get this job done. Not an ideal situation but it’s where the world is at.
- fabrice_d 2y ago
  Both Firefox and Chromium are moving to Rust, incrementally. There are good reasons for that, like the fact that even their very good C++ developers are on board.
- ethanol 2y ago
  GC is but one component of the massive operating system that is current web browsers. This is classic anti-Rust "argument" which states that code with tiny islands of well tested and thoroughly reviewed unsafe functions is somehow equal to 100% unsafe C++.
  - pizlonator 2y ago
    It’s not an island. The whole rest of the browser has to interact with the GC the right way (barriers, pointer tracking) or else you escape memory safety
    - Dylan16807 2y ago
      A ton of things using the GC code fits fine with what they meant by "island". You shouldn't need unsafe code all over, just normal ownership tracking that calls into the GC. And while I wouldn't normally call a GC "tiny", browsers are pretty enormous.
      - pizlonator 2y ago
        That's not what happens in the browser at all. The JS engine - about 1/3 of the browser engine, ish - is tightly coupled to the GC through-and-through. Let's even assume you have a JS engine that doesn't JIT. (If it did JIT then rewriting it in a memory safe language isn't going to do much for you at all.) The interpreter, the runtime, and the libraries are going to have to be making decisions on behalf of the GC (for stuff like weak maps, at least) and is going to have to play along with the GC's tracing (every class in the JS engine participates in the JS GC and so must tell the GC how to mark - or worse, move - outgoing references). The rest of the browser has to play along as well, just not as much. The DOM is basically JS's "standard library" within the browser and it also needs to have its objects play along with the GC's semantics. So, maybe there is code out there where the GC can be an island. The browser is not that.
deleted 2y ago
[deleted]

by loufe 2y ago

amelius 2y ago

A memory safe language may force you to think about memory safety, but it can also work as a straightjacket that makes it more difficult to think about other security issues.

timeon 2y ago
Seems other way around. Since you can focus more on other security issues instead of memory safety and other security.
- amelius 2y ago
  No, because the memory safety part comes at a cognitive cost. You may be right if you're talking about a GC'ed language, which gives memory safety and at the same time frees up the developer's mind. But if you're talking about constructs like borrow checkers then they do add cognitive load that is perhaps better spent elsewhere.
bennettnate5 2y ago
I've not found this to be my experience; if anything, working in Rust has freed me to think about other aspects of security in my project since I don't need to spend all my effort applying extra tools to find segfaults. Do you have an example?

eknkc 2y ago

All the major operating systems these browsers are running on, are written in c and c++. How can you have a real memory safe application when the memory itself is managed by a shit ton of code written in an unsafe language?

parl_match 2y ago
> How can you have a real memory safe application when the memory itself is managed by a shit ton of code written in an unsafe language? It turns out actually pretty effectively? There are going to be more bugs and boundary issues of the OS, but memory unsafety isn't some goop that oozes into your runtime.
- dmurray 2y ago
  Right, or equivalently, you can rely on the million eyeballs and the million developer-years poured into those OSes, while developing your project with a much smaller team.
- eknkc 2y ago
  Yeah just a hyperbole. My point is, people act like anything built with non memory safe languages is shit ever since Rust became the Jesus. We have the actual operating systems written in C, working ok. It is fine. Yeah maybe Rust would be better but it is not a magic bullet and memory safety comes with many caveats in design of the code and possible performance issues when you are building something low level like a browser.
  - deleted 2y ago
    [deleted]
Sayrus 2y ago
In many cases, you'd need to escape the browser before exploiting the OS itself. Security is not an all or nothing, layers and layers are effective at mitigating or increasing the time it takes for exploit to work. For instance ASLR is absolutely not a bulletproof solution, but many exploits are order of magnitude more complex to execute when enabled. In addition to that, the browser is executing third-party code all the time while making it a good point of entry.
- eknkc 2y ago
  My remark was a little more abstract and frankly, absurd though. I mean, the most memory safe language will invoke syscalls. It will ask for memory pages and stuff. If we assume the app is running on a pile of shit because the OS is written in C, how can we be sure that the language is memory safe? I understand the value of memory safe languages but people bashing on C/C++ code does not make sense to me when everything is essentially running on C. That’s all. > In addition to that, the browser is executing third-party code all the time while making it a good point of entry. This made me curious about something. Has there been many exploits stemming from JavaScript engines? I honestly do not know but as far as I can tell, most of the issues originate from faulty image decoders screwing up memory and tls implementations etc.

lkdfjlkdfjlg 2y ago

Do you know that memory safety is relevant for security, compared to other causes of exploits? Or are you just guessing?

mkopinsky 2y ago
The developer of curl has done an analysis of what percent of his CVEs would have been avoided in a memory safe language. I think the answer was a bare majority.
lolinder 2y ago
As a very relevant example, Chrome found that 70% of their serious security bugs were memory safety bugs. 36% of them were use-after-free. https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
ethanol 2y ago
It's been discussed at length multiple times. This should be enough to get you started on further research: https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/ https://msrc.microsoft.com/blog/2019/07/a-proactive-approach... > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues

lgg 2y ago

From https://ladybird.org https://ladybird.org (not some subpage, but literally on the main page): Why build a new browser in C++ when safer and more modern languages are available? Ladybird started as a component of the SerenityOS hobby project, which only allows C++. The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain. However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect. We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages.

deleted 2y ago
[deleted]

pizlonator 2y ago

It’s not as simple as “just” using a memory safe language. The languages that are memory safe either impose too much of a straightjacket to be productive (Rust), don’t give you a GC or a memory safe way of writing one (Swift, Rust), or give you a GC with the wrong semantics (Java, Go, etc). Yes, the browser needs to have a GC. No, there’s no way around that. I’m not saying it can’t be done - but there are good reasons to stick with C++ to get this job done. Not an ideal situation but it’s where the world is at.

fabrice_d 2y ago
Both Firefox and Chromium are moving to Rust, incrementally. There are good reasons for that, like the fact that even their very good C++ developers are on board.
ethanol 2y ago
GC is but one component of the massive operating system that is current web browsers. This is classic anti-Rust "argument" which states that code with tiny islands of well tested and thoroughly reviewed unsafe functions is somehow equal to 100% unsafe C++.
- pizlonator 2y ago
  It’s not an island. The whole rest of the browser has to interact with the GC the right way (barriers, pointer tracking) or else you escape memory safety
  - Dylan16807 2y ago
    A ton of things using the GC code fits fine with what they meant by "island". You shouldn't need unsafe code all over, just normal ownership tracking that calls into the GC. And while I wouldn't normally call a GC "tiny", browsers are pretty enormous.
    - pizlonator 2y ago
      That's not what happens in the browser at all. The JS engine - about 1/3 of the browser engine, ish - is tightly coupled to the GC through-and-through. Let's even assume you have a JS engine that doesn't JIT. (If it did JIT then rewriting it in a memory safe language isn't going to do much for you at all.) The interpreter, the runtime, and the libraries are going to have to be making decisions on behalf of the GC (for stuff like weak maps, at least) and is going to have to play along with the GC's tracing (every class in the JS engine participates in the JS GC and so must tell the GC how to mark - or worse, move - outgoing references). The rest of the browser has to play along as well, just not as much. The DOM is basically JS's "standard library" within the browser and it also needs to have its objects play along with the GC's semantics. So, maybe there is code out there where the GC can be an island. The browser is not that.

deleted 2y ago

[deleted]