171–180 of 264 posts
The bare metal cloud providers will be rubbing their hands together
I never understand why people don't go bare metal. It is just as easy to automate, just as cheap (or cheaper) if you plan well, and more secure. A decade ago everyone knew that shared hosting was for hobby sites and stuff that didn't really matter. Maybe some more people will learn that lesson.
Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would resu…
They might have succeeded to make it work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...
The top comment said:
> This basically adds another set of tools to the architectural-level attack toolbox. From reading this I expect we'll see some interesting developments in the future.
And of course there's an obligatory comment beginning with "this cannot possibly work... "
Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would resu…
Do you think this could be within the rather new Intel AVX 512 ISA or older intel CPUs like Sandy Bridge (first AVX chip) could also suffer? - edit - I checked Ryzen ISA, they support AVX2. So probably AVX512 is the issue.
[1] I do hope they rename that flag to something like X86_BUG_NEEDS_PTI as the current name is bloody abysmal: way too broad and ambiguous, as if this is the only insecurity that ever has or ever will impact x86.
Earlier quoted context omitted.
Do you think this could be within the rather new Intel AVX 512 ISA or older intel CPUs like Sandy Bridge (first AVX chip) could also suffer? - edit - I checked Ryzen ISA, they support AVX2. So probably AVX512 is the issue.
It has nothing to do with AVX AFAICT. They are going to set X86_BUG_CPU_INSECURE [1] on all public Intel CPUs, including old ones that lack AVX (Core2, etc). [1] I do hope they rename that flag to something like X86_BUG_NEEDS_PTI as the current name is bloody abysmal: way too broad and ambiguous, as if this is the only insecurity that ever has or ever will impact x86.
Earlier quoted context omitted.
And the source of an older version of NT leaked a while back.
I think that was NT 4. I don’t think there’s much of that 20-year old code left in the kernel.
https://web.archive.org/web/20120412091908/http://www.facult...
IMHO, with RowHammer, the hardware is broken and it will continue to be broken until users complain enough --- maybe to the point of absolutely refusing to buy --- that the manufacturers and designers stop thinking "works 99.9999999999% of the time" is good enough: https://news.ycombinator.com/item?id=12410274
Aren't there now hardware fixes for this in current generation ram?
Earlier quoted context omitted.
I edited my reply to remove the actual number. The argument still stands that you cannot expect 100% reliability.
No, but it’s straightforward engineering to prevent many of these problems. Error-correcting codes have been well understood for most of a century. Yes, it costs in performance and in money. For life-safety applications, it shouldn’t be optional. Amazon is hosting life-safety applications in EC2. Commodity x86 hardware is grossly negligent for that environment.
Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would resu…
They might have succeeded to make it work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...
Note that under Linux x64 IIRC the whole physical memory is mapped in kernel pages... playing with some adjusting variables, if this theory is correct, I don't see why we could not read all of it. Might be the same under Windows.
I've not checked in depth yet but it could match with all the technical facts we have: very important bug for which the semi-rushed workaround with high perf impact will be backported; affect general purpose OSes but IIRC does not affect some hypervisors (I guess they already do not map at all the pages of other systems while one is running), does not affect AMD (or maybe at least not this way and KPTI can not fix it for them) because of their microarch, involves data leak.
Earlier quoted context omitted.
They might have succeeded to make it work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...
Previously posted on HN as well: https://news.ycombinator.com/item?id=14988157 The top comment said: > This basically adds another set of tools to the architectural-level attack toolbox. From reading this I expect we'll see some interesting developments in the future. And of course there's an obligatory comment beginning with "this cannot possibly work... "
its a good point about TLB and VIPT but I don't think this closes the whole class of potential issue; if too-much speculative execution is performed (even just a little bit, even just when you use some obscure instructions) on anything data depend that has been speculatively loaded before privilege checking, I guess its possible to recover the data.
Earlier quoted context omitted.
I think you need high energy radiation like cosmic rays from space to create problems. So those at higher elevation are at more risk. Heavy material like concrete may block this radiation.
Alpha particle emissions are common causes of single-bit errors, especially from ceramic enclosure materials in integrated circuits. Mitigating soft errors from circuit packaging is an active area of research in materials science. Parity bits and CRC error checking are needed precisely to reduce the impact of these errors down to manageable levels.
This is what I read online. A typical hardware components is enclosed in a aluminum case so really gamma radiation is of concern right?