3 ms·

There are so many more low hanging fruits that makes the architecture (in relation to arm vs. x86) completely irrelevant to the equation. When we get to those

by tjoff 4y ago

There are so many more low hanging fruits that makes the architecture (in relation to arm vs. x86) completely irrelevant to the equation. When we get to those kind of details, maybe you shouldn't rely on drivers that were written without proper information about the hardware?

astrange 4y ago
No, in the web browser case this is literally the most important thing. Second most important would be hardware image/video codecs but that's an optional power optimization. Third would be setting up IOMMUs so the wifi chip can't read all your memory. Writing hardware drivers through reverse engineering is actually fairly common, not too difficult, and the people doing it for Asahi aren't running into problems - it's more like everyone else just assumes they will.
- tjoff 4y ago
  I would have thought the browser was the most important thing. Do you have any examples to share? Particularly and genuinely curious about how variable length instructions have affected browser security. "not too difficult", I guess everything is relative. But I'd have to disagree and say that the work they do is quite difficult. "aren't running into problems". How would we know? (obviously talking about security problems here)
  - astrange 4y ago
    > I would have thought the browser was the most important thing. Do you have any examples to share? No, you're right. The architectural differences like pointer signing sometimes need the code to adopt them but mostly you get them for free after the compiler adopts them. A browser is special though because it runs JavaScript so it's got a compiler (JIT) in it. So exploiting the JIT lets you attack the rest of the system after you find something like a use-after-free or type confusion bug. The ARM security techniques MTE and PAC protect against this. > Particularly and genuinely curious about how variable length instructions have affected browser security. Basically the issue is that you can jump into the middle of an instruction and it can be another valid instruction. This lets you find something called a "ROP gadget" and construct a new evil program out of little bits of browser code. Harder but not impossible with fixed length instructions. BTI is meant to protect against this too. It also makes it easier to hide evil code inside an innocent looking binary, but that's more of a problem for like an antivirus and there's other ways to do it anyway. > "aren't running into problems". How would we know? (obviously talking about security problems here) We wouldn't, that is possible. I just meant that they're making good progress getting everything to run at all, and most of the image of it being super hard is coming from commenters. (Of course it is pretty hard.) Performance and power is pretty easy to observe just by watching your battery life though.
    - deleted 4y ago
      [deleted]

by tjoff 4y ago

astrange 4y ago

No, in the web browser case this is literally the most important thing. Second most important would be hardware image/video codecs but that's an optional power optimization. Third would be setting up IOMMUs so the wifi chip can't read all your memory. Writing hardware drivers through reverse engineering is actually fairly common, not too difficult, and the people doing it for Asahi aren't running into problems - it's more like everyone else just assumes they will.

tjoff 4y ago
I would have thought the browser was the most important thing. Do you have any examples to share? Particularly and genuinely curious about how variable length instructions have affected browser security. "not too difficult", I guess everything is relative. But I'd have to disagree and say that the work they do is quite difficult. "aren't running into problems". How would we know? (obviously talking about security problems here)
- astrange 4y ago
  > I would have thought the browser was the most important thing. Do you have any examples to share? No, you're right. The architectural differences like pointer signing sometimes need the code to adopt them but mostly you get them for free after the compiler adopts them. A browser is special though because it runs JavaScript so it's got a compiler (JIT) in it. So exploiting the JIT lets you attack the rest of the system after you find something like a use-after-free or type confusion bug. The ARM security techniques MTE and PAC protect against this. > Particularly and genuinely curious about how variable length instructions have affected browser security. Basically the issue is that you can jump into the middle of an instruction and it can be another valid instruction. This lets you find something called a "ROP gadget" and construct a new evil program out of little bits of browser code. Harder but not impossible with fixed length instructions. BTI is meant to protect against this too. It also makes it easier to hide evil code inside an innocent looking binary, but that's more of a problem for like an antivirus and there's other ways to do it anyway. > "aren't running into problems". How would we know? (obviously talking about security problems here) We wouldn't, that is possible. I just meant that they're making good progress getting everything to run at all, and most of the image of it being super hard is coming from commenters. (Of course it is pretty hard.) Performance and power is pretty easy to observe just by watching your battery life though.
  - deleted 4y ago
    [deleted]