No. Architectural leakage via a side-channel is far from simple. It requires deep understanding of the code (i.e. what it does, why it is doing it that way and the implied effect of executing the code on the architecture) and also of the architecture (i.e. how it is executing and why that causes leakage to be observable via the side-channel).
If anything, these are canonical examples of non-simple bugs.
> It requires deep understanding of the code (i.e. what it does, why it is doing it that way and the implied effect of executing the code on the architecture) and also of the architecture (i.e. how it is executing and why that causes leakage to be observable via the side-channel).
For exploitation, or for patching, maybe. But characterizing these bugs is still clear and simple IMO. I mean, rowhammer is about as basic as a bug can get - the value of this bit in memory changed even though it was never written to.
Rowhammer isn't a speculative execution bug. Without getting into how complex Rowhammer is or isn't, speculative execution is an inherently complex and software-involved pattern of vulnerability.
You're letting yourself get dragged into some weird rhetorical places trying to defend this part of Raymond's essay.
> Rowhammer isn't a speculative execution bug. Without getting into how complex Rowhammer is or isn't, speculative execution is an inherently complex and software-involved pattern of vulnerability.
Rowhammer was one of the examples the person I was replying to listed. But the same applies for spectre/meltdown/etc.. They're all issues that can be understood - perhaps not exploited, certainly not fixed, but understood that a bug is there - without any deep architectural knowledge.
> You're letting yourself get dragged into some weird rhetorical places trying to defend this part of Raymond's essay.
If anyone other than you talked like this they'd be quite rightly downvoted to oblivion.
> They're all issues that can be understood - perhaps not exploited, certainly not fixed, but understood that a bug is there - without any deep architectural knowledge.
I don't think it is clear how you would do this other than with hindsight. When the bug was discovered, if we avoid architectural knowledge of why the bug was occurring then what information would the discoverer have access to?
- Memory corruption is occuring during execution.
- We can't find any part of code that appears to corrupt the values.
Finding the bug requires finding the Rowhammer affect, which means looking isolating the instructions that are accessing similar uncached addresses, and then finding the pattern of accesses and cache flushes which triggers the corruption.
Could you explain how this would be simple, or do you have a different view of the bug complexity that you could explain?
> if we avoid architectural knowledge of why the bug was occurring then what information would the discoverer have access to?
> Finding the bug requires finding the Rowhammer affect, which means looking isolating the instructions that are accessing similar uncached addresses, and then finding the pattern of accesses and cache flushes which triggers the corruption.
AIUI you don't need to know the details of the caches though? I guess you could argue that knowing the physical memory layout is deep knowledge, but you don't need to be an expert on e.g. that specific chip or memory controller to find that effect, no? And fundamentally if you can produce memory corruption then you can know that's a bug without having to understand the details of the memory hierarchy or hardware.
Perhaps we are talking about overlapping but slightly different concepts? If I run the program and it goes wrong then I know there is a bug - but I don't know what or where it is.
So observing that Rowhammer causes buggy behavior may be simple. But finding the actual bug - i.e. this sequence of instructions on this data causes the memory corruption would be much harder.
Part of this comes down to how you interpret the "many eyes makes bugs shallow" but I suspect that no number of eyes would have found the Rowhammer bugs by looking at the code.
