3 ms·
I’m not (yet) clear on if/how this impacts aarch64 (ARM architecture) chips, the distinction between how it affects Intel vs. doesn’t affect AMD reminds us of a
by qubex 9y ago
I’m not (yet) clear on if/how this impacts aarch64 (ARM architecture) chips, the distinction between how it affects Intel vs. doesn’t affect AMD reminds us of a fundamental lesson we seem to have conveniently forgotten: monocultures of anything are bad. We need diversity and diversification in order to have reasonable amount of robustness in the face of unknowable, unpredictable risks.
I’m wondering whether ARM chips are affected if they are whether they are uniformly affected or whether it depends on vendor implementation choices.
- thraweigh666 9y ago>We need diversity and diversification in order to have reasonable amount of robustness Ironically, in human populations it produces the opposite effect.
- adornedCupcake 9y agoWhy?
- edraferi 9y agoMore diverse population—> lower trust —> less social will to support each other.
- crimethink2017 9y agoThis might well be true, see e.g. [1]. An obvious irony is that those who are most happy with Intel's "velocity"-led culture, and the more general lack of diversity in the x86 CPU market, are probably also the most likely to reject this idea (that human diversity might have negative effects) outright. ____ [1] https://www.mpg.de/19440/Diversity_interaction_solidarity https://www.mpg.de/19440/Diversity_interaction_solidarity
- cryptonector 9y agoSo we should be tribal societies, then? (I.e., endogamous. As in cousin marriage.)
- dang 9y agoPlease don't take HN threads on ideological tangents. The point you're making has by now become well-known ideological flamebait. We ban users who derail HN threads in such directions, so please don't. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Edit: since https://news.ycombinator.com/item?id=16063749 https://news.ycombinator.com/item?id=16063749 makes it clear that you're using HN for that purpose, which is not allowed here, I've banned this account. Would you please not create accounts to break the site guidelines with?
- exabrial 9y agoYep, I'm still wondering how this affects ARM and if it can be corrected in microcode on that platform. I'm also wondering if/hoping for a fix that involves increased memory usage instead of the speed.
- qubex 9y agoI’m not a very proficient programmer/developer, so please bear with me. I’m intrigued by your reference to trading off greater memory footprint in exchange for diminishing performance by less. I'm trying to understand how this would work in practice: do you envision ‘padding’ the critical data structures with more empty or randomised buffer zones? Wouldn't that incur an additional penalty for the data transfer (Von Neumann bottleneck)? Would blank data be sufficient or would there be some additional kind of memory effect in the DRAM/SRAM that would demand using randomised data overwrites? How would you generate that random data? (I apologise if this is blindingly obvious for somebody well versed in low-level programming.)
- exabrial 9y agoOh I have no idea actually; it's just pretty normal to see a speed-memory trade in a lot of problems. I'm definitely not low-level enough either.
- yorick 9y agoA patch is in the works for ARM chips as well (http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/542751.html http://lists.infradead.org/pipermail/linux-arm-kernel/2017-N...), but I am not clear on whether it's enabled by default. It seems like a good idea to have this, independent of current ARM vulnerability.
- waz0wski 9y agoARM posted a good overview and affected product list today: https://developer.arm.com/support/security-update https://developer.arm.com/support/security-update