> Can the DMP be disabled?
> Yes, but only on some processors. We observe that the DIT bit set on m3 CPUs effectively disables the DMP. This is not the case for the m1 and m2.
Surely there is a chicken bit somewhere to do this?
GoFetch: New side-channel attack using data memory-dependent prefetchers
41–50 of 100 posts
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#42Earlier quoted context omitted.
I don’t think the security community is also going to become experts in chip design, these are two full skill sets that are already very difficult to obtain. We must stop running untrustworthy code on modern full-performance chips. The feedback loop that powers everything is: faster chips allow better engineering and science, creating faster chips. We’re not inserting the security community into that loop and slowing…
I almost gave you up an upvote until your third paragraph, but I have to now give a hard disagree. We're running more untrusted code than ever, and we absolutely should trust it less than ever and have hardware and software designed with security in mind. Security should be priority #1 from here on out. We are absolutely awash in performance and memory capacity but keep getting surprised by bad security outcomes beca…
Turning off bounds checks is like a 5% performance penalty. Turning off prefetching is like using a computer from twenty years ago.
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#43Earlier quoted context omitted.
I almost gave you up an upvote until your third paragraph, but I have to now give a hard disagree. We're running more untrusted code than ever, and we absolutely should trust it less than ever and have hardware and software designed with security in mind. Security should be priority #1 from here on out. We are absolutely awash in performance and memory capacity but keep getting surprised by bad security outcomes beca…
> I fundamentally don't understand the mindset of people who want to take that kind of risk for a 10% boost in their games' FPS[1] Me either. But, lots of engineers are out there just writing single threaded matlab and python codes with lots of data-dependencies and just hoping the system manages to do a good job (for those operations that can’t be offloaded to BLAS). So I'm glad gamer dollars subsidize the developme…
How is RISC-V going to solve anything here?
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#44As long as we're getting efficiency cores and such, maybe we need some "crypto cores" added to modern architectures, that make promises specifically related to constant time algorithms like this and promise not to prefetch, branch predict, etc. Sort of like the Itanium, but confined to a "crypto processor". Given how many features these things wouldn't have, they wouldn't be much silicon for the cores themselves, in…
Speaking as a cryptography implementer, yes, these drive us up the wall. However, crypto coprocessors would be a tremendously disruptive solution: we'd need to build mountains of scaffolding to allow switching to and off these cores, and to share memory with them, etc. Even more critically, you can't just move the RSA multiplication to those cores and call it a day. The key is probably parsed from somewhere, right? D…
Processor designers are very unlikely to do that for you, because everyone not working on constant time crypto gives them a whole lot of money to keep doing this. The best you might get is a mode where the set of assumptions they violate is reduced.
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#45Why does every attack needs its own branding, marketing page, etc...? Genuine question.
Why does the comments of every such attack need a question about why it has its own branding, marketing page, etc…? Genuine question.
(Seriously, this comes up every time, just do a search for it if you actually want to figure out why.)
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#46Earlier quoted context omitted.
> I fundamentally don't understand the mindset of people who want to take that kind of risk for a 10% boost in their games' FPS[1] Me either. But, lots of engineers are out there just writing single threaded matlab and python codes with lots of data-dependencies and just hoping the system manages to do a good job (for those operations that can’t be offloaded to BLAS). So I'm glad gamer dollars subsidize the developme…
How is RISC-V going to solve anything here?
It isn’t a sure thing. Just, since it is a more open ecosystem, maybe the designers of chips that need to be able to safely run untrusted code can still borrow some features from the general population.
I think it is basically impossible to run untrusted code safely or to build sand-proof sandboxes, but I thought the rest of my post was too pessimistic.
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#47Is it naive to ask whether implementing this mitigation would impact performance and memory interaction speed?
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#48Earlier quoted context omitted.
I don’t think the security community is also going to become experts in chip design, these are two full skill sets that are already very difficult to obtain. We must stop running untrustworthy code on modern full-performance chips. The feedback loop that powers everything is: faster chips allow better engineering and science, creating faster chips. We’re not inserting the security community into that loop and slowing…
I almost gave you up an upvote until your third paragraph, but I have to now give a hard disagree. We're running more untrusted code than ever, and we absolutely should trust it less than ever and have hardware and software designed with security in mind. Security should be priority #1 from here on out. We are absolutely awash in performance and memory capacity but keep getting surprised by bad security outcomes beca…
I agree that hardware/software codesign are critical to solving things like this, but features like prefetching, speculation, and prediction are absolutely critical to modern pipelines and broadly speaking are what enable what we think of as "modern computer performance." This has been true for over 20 years now. In terms of "overhead" it's not in the same ballpark -- or even the same sport, frankly -- as something like bounds checking or even garbage collection. Hell, if the difference was within even one order magnitude, they'd have done it already.
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#49Earlier quoted context omitted.
Well, names are useful for the same reason people's names are useful. The rest just kinda happens naturally, I think.
Name makes enough sense. "Branding, marketing page, etc..." was my question. "Happens naturally" isn't really an answer.
Is your position that any write-up about an attack must be plain text only, and must not use its own URL?
I truly cannot understand why this is brought up so often. You aren't paying for it, it doesn't hurt you in any way, it detracts nothing from the findings (in fact, it makes the findings easier to discuss), etc. There is no downside I can think of.
Can you share what the downsides of a picture of a puppy and a $5 domain are? Sorry, "branding" and "marketing page"?
Or at least, maybe you can share what you think would be a more preferable way?
Re: GoFetch: New side-channel attack using data memory-dependent prefetchers
#50Earlier quoted context omitted.
> download random programs onto their computers and run them at random To be clear that includes what we're all doing by downloading and running Javascript to read HN. Maybe I can say "don't run adversarial code on my same CPU" and only care about over-the-network CPU side-channels (of which there are still some), because I write Go crypto, but it doesn't sound like something my colleagues writing browser code can do…
Is this exploitable through JavaScript? In general from what I've seen, most of these JS-based CPU exploits didn't strike me as all that practical in real world conditions. I mean, it is a problem, but not really all that worrying.
> Is this exploitable through JavaScript?
Why wouldn't it be?