A couple of weekends ago it was FOSDEM 2018, the largest conference on open source in Europe. It was held in Brussels. In keeping with the open source ethos, it was free, anyone could go, there was no registration, and all of the dozen or more parallel sessions were live-streamed. I didn't go to Brussels, and so I missed out on the chocolate, fries, and beer. But I did tune into the live-stream of Jon Masters from Red Hat, who is the head of their response team to Spectre and Meltdown. His presentation was titled Exploiting Modern Microarchitectures: Meltdown, Spectre, and Other Attacks . Since it was 7am on a Saturday morning, I forwent (is that a word?) the beer and fries, and had a café, which is what an espresso is called in French (and Italy. Despite the word espresso being Italian, in Italy, it is just a coffee). As it happens, Jon is also the head of Red Hat's activities in the Arm server space. So I guess he wears two hats, both of them Red. In his Arm job, it turns out I've written about presentations he's given twice here on Breakfast Bytes. See How Arm Servers Can Take over the World and Red Hat's Mr Arm Talks Open Source for those posts. Earlier that week, I attended a presentation by Paul Kocher, who was the lead author of the Spectre paper. I wrote about that last week in Paul Kocher: Differential Power Analysis and Spectre . Paul is a security researcher who can point out the problems, and indicate solutions. But Jon works for Red Hat, whose Linux runs a lot of enterprise servers. He has to deliver a response. If you are coming to this cold, you should probably also read my earlier post Spectre and Meltdown: An Update . If you wonder why it is not even March yet, and I've written four or five posts on Spectre and Meltdown, it is because this is something that directly or indirectly is going to affect lots of semiconductor designs. It doesn't affect chips where the code is firmware supplied by the company selling the SoC, but potentially it affects any chip that can run user-supplied code, such as the processors that are exposed to the user in mainframes, servers, PCs, smartphones, and probably more. Unlike most security issues, it is not something that only affects the software teams, it affects chip design too. Designing secure systems just got a lot harder. Last year, there must have been something in the air. Seemingly independently, a few teams around the world started to look for hardware vulnerabilities in processors, and some were found fairly quickly. Once people start looking harder, more are almost certain to be found. Processor architects are going to have to worry about making sure that the speculation they add to get acceptable performance doesn't also create security holes that bad guys can exploit. All over the semiconductor ecosystem, people need to start to worry about something that wasn't even on their radar screen when the New Year rolled over a couple of months ago. The details of Spectre, and its mitigation, are rather complex, and they will get their own post tomorrow. The Vulnerabilities In a perfect example of what a side-channel is, Jon said that Red Hat found out the names for Spectre and Meltdown when one of the universities that had discovered the vulnerabilities registered website names: spectreattack and meltdownattack. These are serious exploits that require mitigation, not some theoretical weakness that is impractical to exploit. It is especially important in shared environments, different code is running on the same server. This happens all the time in the cloud, where (at least a lot of the time) different users are all running on the same set of servers. One thing that has made this worse over the last decade or so is the move from separate servers for each function, to grouping a lot of functions on each physical server, and making them look like separate machines using virtualization. Jon reckons that: We do not need to panic and throw away all of our performance toys. Speculation is not entirely broken forevermore, some implementations are vulnerable. I'm actually more negative than that. For sure, future generations of processors will be designed with the knowledge of this kind of exploit, but it is hard to see a general solution to Spectre (Meltdown is simpler, see below) which is not so much a single exploit, more an approach to using speculative execution to leak information through side channels. Jon knows a lot more about this than I do, of course, but despite having worked in EDA all my life, I do know something about operating systems. My Ph.D. is on operating system design, although long before PCs and Linux. Just to give you an example of closing off a side channel, here is one. I wrote about storing passwords in Passwords: Even Your Bank Doesn't Know Your PIN . When you log into a system, you provide a username and password. In old-school systems, you would type the username, then the system would ask for the password, and you would type that. What if the username is wrong? You could tell the user that the username is bad (and on an old-school system, you could tell the user before even asking for the password). However, good security advice is that you don't do that. You just tell the user that their login credential were invalid. That way, it is hard for the bad guys to use the system to build a list of all the valid usernames, or derive other information that might be useful (does Paul still work at Cadence? Let's just see if his username is still valid even though we don't know his password). What about processing the password when the username is wrong? There isn't any point, obviously, since whether the password is good or bad, the login attempt is going to be rejected. But I also told you when talking about storing passwords that you want the cryptographic hash function used to be slow (to make brute force attack impractical). This means that there is a side-channel created if you don't encrypt the password before rejecting the username: if the password is rejected instantly, it is an invalid username, but if it takes time, it is a valid username with an invalid password. To close up that side-channel, standard practice is to encrypt the password, do the comparison, and only then reject the login attempt. In fact, in security in general, a good piece of high-level advice is to do the same thing all the time as much as possible. Whenever you do not, there is a potential side channel created if the bad guys can detect the difference. For example, differential power analysis (DPA) relies on detecting the chip doing something different depending on whether the key bit is 1 or 0. The defenses against differential power analysis are, in effect, to make the power look the same whether the key bits are ones or zeros so that there is no side channel created for devious guys like Paul Kocher to exploit. This can even involve creating dummy logic along the lines of "if the key bit is 0 use the real adder, and if the key bit is 1, use the dummy adder". Jon started off by giving the history. Meltdown and Spectre are branded vulnerabilities (I think that means they have a name and a logo, which I can't think I've ever seen before) and were discovered independently by several teams in the middle of 2017, including TU Graz (in Austria), Google Project Zero (in Mountain View), and Paul Kocher (presumably at home in San Francisco). Meltdown I'm not going to say much about Meltdown, because it has already been effectively fixed. One optimization that Linux, Windows, and probably other operating systems used, is that the kernel memory is mapped into every process's address space, with a bit set to deny access to user code. This means that system calls can be fast, since no address space swap is required. However, Meltdown works by taking advantage of this, using speculative execution to look at bytes before the bit that denies access is noticed, and then using cache timing to pick up the byte accessed. The solution to Meltdown is thus to remove the kernel address space from memory almost completely, leaving only the so-called trampolines, the code that needs to be in user space to enter and return from the operating system. Linux calls this Page Table Isolation (PTI) since the kernel and application page tables are separated (if you don't know what a page table is, don't worry about it). It does require an expensive write to control registers on each entry/exit from the kernel, to switch the page tables. There is some performance impact from this, but a lot of code is limited by some sort of algorithmic inner loops that doesn't make calls on the operating system much. My guess (and at this stage, it is just a guess) is that EDA software, in general, won't be affected materially in performance. Web servers might be more materially affected since they don't really have algorithmic loops, they are largely directing data movements, all of which require operating system calls. Tomorrow, the details of Spectre. The Slides A pdf of Jon's presentation is on the Red Hat website . Note that it is 184 pages long, since it contains the whole presentation in both slide form, and note page form. If you want to print it out, you only need the first 90 pages (yes, still long). Sign up for Sunday Brunch, the weekly Breakfast Bytes email.![]()
↧