wilun

12 ms·

61.
by wilun 9y ago
They do, and it's what runs the Intel ME.
62.
by wilun 9y ago
You can use other microarchitectural features than the cache to create a covert channel and do measurements.
63.
by wilun 9y ago
I don't see where the contrary is stated; in a nutshell their architecture is not sensible and deeply flawed in regard to security, if they can't check that without throwing all the perf out the window.
64.
by wilun 9y ago
With the right new instructions inserted at the right place, assisted by a good type system, and a processor that does not share its resources like crazy in highly uncontrolled ways, this seems fixable. Sadly, I feel the only part that won&
65.
by wilun 9y ago
About Meltdown, it was well known since even before that speculative execution has to stop at security boundaries.
66.
by wilun 9y ago
Great. Now we just have to think of new attacks using the same general idea to slow down all computers by yet another 10% :p
67.
by wilun 9y ago
> Linux is, of course, great, but what hardware? We are in 2018, not in 1995. You can easily find good desktop and laptop that run fine under pretty much all major distros. Especially if you compare to MBP & the like, meaning you hav
68.
by wilun 9y ago
Intel seems committed to write everywhere that their current processors work as intended and according to their specification. I'm not mad at them for Spectre, but Meltdown is ridiculous. If this is the quality of specification they wa
69.
by wilun 9y ago
You are confusing different things.
70.
by wilun 9y ago
Speculating memory reference reads across security boundaries is not a trade-off (except if you can prove that you will not further act on them in any data dependant way that is observable). That's mostly common sense. Spectre does not
71.
by wilun 9y ago
There are still a lot of simple attacks yet to be discovered. In SW and in HW designs.
72.
by wilun 9y ago
Meltdown could have been avoided by following what is in CPU design text books about speculative execution. Spectre is clever. Meltdown, as known today, is (mainly) an Intel major fuck-up.
73.
by wilun 9y ago
So what? IIRC we used to have (and maybe still have) a feature that patched out spinlocks in binary code when it detects it is run on monoprocessor systems. You "just" have to identify all the call sites, and patch the code there
74.
by wilun 9y ago
I don't see why the text could not be fixed at boot time. It has been done before.
75.
by wilun 9y ago
> 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 speculativ
76.
by wilun 9y ago
Ok so it seems that Intel CPU do some speculative execution on priviledged data from unpriviledged code, including from (at least some and at least part of) separate following instructions. Given the microarchitectural complexity and the
77.
by wilun 9y ago
Well that very name hints that it is probably a very annoying bug, with an impact way more annoying that a simple ASLR address leak or data access trace (hell, Intel does not even consider side-channel data access / tlb tracing to SGX
78.
by wilun 9y ago
Its even worse than that. KASLR is only a mitigation, not an architectural protection (and "breaking KASLR" does not gives you an exploit by itself, you have to find another bug), so there is absolutely no way Linus would consider
79.
by wilun 9y ago
What do you think this fixes? Tiny info leak about kernel addresses? There are still other more reliable ways to get that (even if there is active work to remove those), and I don't believe this would yield to a semi-rushed patch with
80.
by wilun 9y ago
I guess Intel decided to speculate data access regardless of privilege level of the target address, with the theory that what has been successfully speculated can't be accessed anyway before the permission are really checked, and someb
81.
by wilun 9y ago
The first section is weird: it compares random opinions from random social websites with another semi-random one from Hacker News (from someone who says it worked on it, but we don't even now at which level, and the "I think I wou
82.
by wilun 9y ago
You sound like you somewhat understand politics more than you really understand engineering. Engineering is not math. Neither you can practice it in an idealized world and winning all arguments by showing a pretty table of numbers; you alre
83.
by wilun 9y ago
> In engineering problems, tradeoffs are known Not really. In non trivial projects, you also have to "manage" the unknowns. Viewing engineering projects as completely controlled is a myth; even what we make with actual engineer
84.
by wilun 9y ago
> Even then you have to worry about glibc symbol versioning. Symbol versioning will actually permit the binary compat (unless you have a rather clueless approach), and not break it by some kind of "oh my god I don't know what i
85.
by wilun 9y ago
Security updates would only be patches against coding errors and the like, but the architectural security until Vista was defective, and no amount of patches (without changing the OS so much it would have to be considered another one anyway
86.
by wilun 9y ago
Architectural security until at least Vista was, hm, let's say weak.
87.
by wilun 9y ago
We have invented that really useful thing named version control to know about the history of code. If yours has commit messages not good enough to properly understand its history, fix that.
88.
by wilun 9y ago
There is no reason the philosophy can't be the same.
89.
by wilun 9y ago
Hu. Bubble Sort. And not only that; a buggy version! And if you believe sequential access is gonna save you from O()... you're so wrong its not even funny. Of course the curves will cross latter. But they will cross. Especially on a
90.
by wilun 9y ago
Nodes are hard to compare, and pretty much everybody agrees that what Intel called 14nm is roughly equivalent to other foundries' 10nm. (Maybe some of the 10nm processes are 10 or 15% more dense than Intel's 14, but nothing like t

More ›