Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On Wednesday, 31 January 2018 12:20:51 GMT Nikos Chantziaras wrote: > On 31/01/18 14:04, Mick wrote: > > Just to dilute my confusion on what I should do to keep desktops safe(r), > > would someone please clarify: > > > > Is it necessary to keyword gcc 7.3 + kernel 4.15 and emerge kernel 4.15 > > with gcc 7.3, or wait until these versions have been stabilised in the > > tree? > > > > What gcc version shall I use to update @world from then on? > > > > PS. Some desktops are Intel, some are AMD and I also have 3-4 devices with > > ARM in them ... > > At the moment, you do need GCC 7.3. However, there is talk about these > new flags being ported to GCC 6 and possibly even older versions. > > As for the kernel, you don't need 4.15. 4.14 is the latest LTS kernel, > and it has the needed patches. I think 4.9 (the previous LTS kernel) has > them too. Kernel 4.14.15 has the latest patches, so I stayed with the 4.14 series. > Currently, once you enable CONFIG_RETPOLINE in the kernel config and > rebuild with GCC 7.3, you should have all currently available kernel > mitigations. Which currently are: > >$ cat /sys/devices/system/cpu/vulnerabilities/* >Mitigation: PTI >Vulnerable >Mitigation: Full generic retpoline I'm good here: $ dmesg | grep -i Spectre [0.011822] Spectre V2 mitigation: Mitigation: Full generic retpoline although this post indicates Skylake may still be vulnerable: https://lkml.org/lkml/2018/1/4/724 Anyway, as I understand it, we'll have to wait for gcc-8.1 in March, which utilises 'gcc -mindirect-branch=thunk-extern' to get the benefit of the retpoline kernel patch. > However, improvements to these mitigations will from now on happen for > kernel 4.16 first and backported later. 4.16 for example got mitigations > for ARM. It's how kernel upstream works; new stuff is done in the > current development version, and backported later to still supported > versions. Spectre_v1 still shown as vulnerable on both Intel and AMD. Is there a fix planned for this? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On Wed, Jan 31, 2018 at 7:07 AM, Nikos Chantziaras wrote: > > I was under the impression that it's the function that performs the call > that needs protection. The called function doesn't need protection, because > if it ends up being actually called, then it's too late already. > > For example, if sandboxed, untrusted code wants to speculatively execute a > memcpy(), then the sandbox would need to call it on behalf of the untrusted > code. But if the sandbox is protected, the memcpy() call would never be made > speculatively, since retpoline will trap it. So memcpy() itself doesn't need > protection. If memcpy() ends up being called, then it's too late. Protecting > memcpy() doesn't do anything to prevent memcpy() from being called, as it's > been called already. > I think there is some confusion here because in your scenario there are actually 3 calls being made, and the sandbox is both being called, and issuing a call. In your scenario the code executing inside the sandbox calls an API in the sandbox which in turn calls memcpy. Code can be vulnerable to Spectre even if it doesn't call anything at all (variant 2 of Spectre in particular does require a call, variant 1 does not, and who knows what other variants will be discovered in the future). In any case, the issue is that your untrusted code inside the sandbox is calling trusted code via the sandbox API, and it is the sandbox API that requires protection, as this is where there is a privilege boundary. Again, Spectre is not limited to code running in sandboxes. Your ssh server could be vulnerable to an incoming ssh client connection if the client is colluding with another process on the same physical CPU, assuming your ssh server contains vulnerable code. Sandboxes are just a particularly nasty and obvious target of this attack since they routinely execute untrusted code on the same hardware as the software being protected from the code. However, this isn't a reason to just go rebuilding everything with gcc-7.3 and assuming all is fine. The maintainers of the upstream projects really need to assess their code for vulnerabilities, and treat gcc as a tool that might help solve things. -- Rich
Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On Wed, Jan 31, 2018 at 4:16 AM, Nikos Chantziaras wrote: > On 30/01/18 23:43, Rich Freeman wrote: >> >> If you had some program that listened on a socket and accepted a >> length and a string and then did a bounds check using the length, it >> might be exploitable if a local process could feed it data. Even if >> the process only listened for outside connections it might be >> vulnerable if a local process colluded with a remote host to make that >> connection. > > > Well, if you're running a local process that is trying to attack you, you've > been compromised already, imo. > > Local processes are always trusted. Not at all. This is the whole point of uids on linux and any POSIX OS. There is separation of privilege. I should be able to give you ssh access to my database server using a UID different from my database server, and it should be impossible for you to damage my database (particularly if I am using resource limits/etc). Spectre allows local processes to probe the cache to obtain data leaked from other processes running under different UIDs (or even the kernel) which they should not have access to. If MariaDB has vulnerable code listening on its socket, and you can talk to that socket, and run code under a different UID, then you could in theory read arbitrary data from MariaDB's memory. That could include tables you don't otherwise have privileges to read, or possibly even credentials stored in memory that could allow you to connect to the server and execute arbitrary queries. Also, all this is requires is code running on the same CPU. It could be in a different VM, or a different container. However, I wouldn't completely neglect local priv escalation attacks. Sure, every sysadmin would prefer to not have code running on their server that they didn't put there, but there is still such a thing as defense in depth. There is a reason we don't run all our daemons as root. If your server's ntp client somehow has a vulnerability and now there is malicious code running under the ntp UID, it would still be preferable that this code STAY contained in the ntp UID vs having access to more mission-critical processes on the server. Sure, you will still want to wipe the server and install a clean one, but it would be nice if you could do that after migrating your production database/website/whatever to another server, versus having to revert to the last backup. -- Rich
Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On Wednesday, 31 January 2018 12:20:51 GMT Nikos Chantziaras wrote: > On 31/01/18 14:04, Mick wrote: > > Just to dilute my confusion on what I should do to keep desktops safe(r), > > would someone please clarify: > > > > Is it necessary to keyword gcc 7.3 + kernel 4.15 and emerge kernel 4.15 > > with gcc 7.3, or wait until these versions have been stabilised in the > > tree? > > > > What gcc version shall I use to update @world from then on? > > > > PS. Some desktops are Intel, some are AMD and I also have 3-4 devices with > > ARM in them ... > > At the moment, you do need GCC 7.3. However, there is talk about these > new flags being ported to GCC 6 and possibly even older versions. > > As for the kernel, you don't need 4.15. 4.14 is the latest LTS kernel, > and it has the needed patches. I think 4.9 (the previous LTS kernel) has > them too. > > Currently, once you enable CONFIG_RETPOLINE in the kernel config and > rebuild with GCC 7.3, you should have all currently available kernel > mitigations. Which currently are: > >$ cat /sys/devices/system/cpu/vulnerabilities/* >Mitigation: PTI >Vulnerable >Mitigation: Full generic retpoline > > However, improvements to these mitigations will from now on happen for > kernel 4.16 first and backported later. 4.16 for example got mitigations > for ARM. It's how kernel upstream works; new stuff is done in the > current development version, and backported later to still supported > versions. Thanks Nikos, I'm presently on 4.14.14, so I can update this to 4.14.15 and compile it with gcc-7.3; then pick up future improvements as part of gentoo- sources updates when kernels start being marked as stable. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On Wednesday, 31 January 2018 11:30:13 GMT Martin Vaeth wrote: > Nikos Chantziaras wrote: > > Yeah, that's the kind of software that benefits from the Spectre > > mitigation patches. Like browsers, virtualization or emulation software, > > the kernel, etc. > > No. It's software like gnupg, encfs, openssl and all the library they > use (glibc, glib, X etc) which need these patches. > > > Rebuilding the whole system with these flags on doesn't sound like a > > good idea. Now, I don't know if it would hurt anything, but it's not > > uncommon for build flags to break random stuff. > > Yep. On x86, gcc cannot compile itself if built with -fno-plt. > > > I haven't seen any word from anyone yet as to whether these flags are > > actually recommended or not on a system-wide basis. > > Actually, it is not even clear in the moment which flags should be > used in which settings. (There has been some discussion in the > gentoo forums but to no completely satisfactory result yet.) > > > So my educated guess is: No. Don't do that. > > Yes and no: It is probably recommended, but the flags are so no and > so poorly understood that people are hesitating with recommendations. > Also, spectre is hard to exploit, so it is perhaps better to wait in > the moment until some experience ins there. > > > If a package is affected, it > > stands to reason that the upstream of that package would change their > > build system to use these new flags where needed. > > No, for many reasons: > > 1. Packages often try to not add any flags; especially in gentoo it is a > policy that they _must_ not: If they do, it would get patched out in gentoo. > > 2. A library has no idea what it is used for. Why should it add something, > only because some program using it should be protected? > > 3. Adding the flags slows down the programs. It is the user who must > decide whether patches are desirable for his use case and architecture. > (Maybe this is less relevant know but in a while when versions of > processors "immune" to spectre come out.) Just to dilute my confusion on what I should do to keep desktops safe(r), would someone please clarify: Is it necessary to keyword gcc 7.3 + kernel 4.15 and emerge kernel 4.15 with gcc 7.3, or wait until these versions have been stabilised in the tree? What gcc version shall I use to update @world from then on? PS. Some desktops are Intel, some are AMD and I also have 3-4 devices with ARM in them ... -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On 01/31/2018 04:16 AM, Nikos Chantziaras wrote: On 30/01/18 23:43, Rich Freeman wrote: If you had some program that listened on a socket and accepted a length and a string and then did a bounds check using the length, it might be exploitable if a local process could feed it data. Even if the process only listened for outside connections it might be vulnerable if a local process colluded with a remote host to make that connection. Well, if you're running a local process that is trying to attack you, you've been compromised already, imo. Local processes are always trusted. If Spectre is a vulnerability that can be exploited by trusted code, it's not really a vulnerability. Trusted code is called "trusted" for a reason. I wouldn't classify for instance running a multiplayer game in a VM as "trusted" code, the whole point of hardware virtualization is that you don't have to trust what is being executed there. Not to mention the issue with most websites requiring javascript for no reason to function properly.
Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On Mon, Jan 29, 2018 at 11:35 PM, Nikos Chantziaras wrote: > On 30/01/18 00:36, Henry Kohli wrote: >> >> Would it be usefull to do a emerge -e @world with the new GCC 7.3 ? > > These flags are for *affected* applications only. That means application > that: a) run third-party code, and b) do so in a sandbox. While I agree that it doesn't make sense to go rebuilding everything right now, I did want to caution that Spectre is probably a bit wider-reaching than you're suggesting. The sandboxed code issue is actually more of a problem with meltdown as it doesn't require vulnerable interfaces to work - but meltdown has nothing to do with gcc 7.3. Meltdown does not require any process vulnerability to work - it just requires a vulnerable CPU and data mapped into virtual address space that shouldn't be accessible. Spectre is more about having vulnerable functions in your code being executable by untrusted code, acting on untrusted data. Now, a lot of sandboxes do have APIs in them that would be vulnerable, but the problem goes beyond this. Any kind of API/IPC mechanism, including sockets, could potentially be exploitable, as long as it is interacting with some kind of local process (perhaps indirectly). Spectre is about using data to trick a process to leak state via the side channel of the cache, and then using local code to probe the cache. If you had some program that listened on a socket and accepted a length and a string and then did a bounds check using the length, it might be exploitable if a local process could feed it data. Even if the process only listened for outside connections it might be vulnerable if a local process colluded with a remote host to make that connection. Now, the more directly coupled the untrusted process is to the vulnerable one the easier this would probably be to pull off. This is why the kernel system call interface is so attractive. That, and also the fact that kernel memory is of course a high-value target. How exploitable any particular process is depends a lot on the actual code/etc. Spectre should be seen as a class of vulnerabilities just like buffer overflows. Not every call to strcpy is vulnerable to a buffer overflow, but it is certainly an opportunity for one. Well, in the same way things like bounds checks or indirect calls that are associated with untrusted input are also opportunities. I imagine that other classes of Spectre will emerge over the coming years as well. To some degree compilers might be able to become smart enough on their own to detect vulnerable code and add protections. The question is whether that can be done with little overhead, vs having developers identify these points and mark them for the compiler (which I think is the current approach). Disclaimer: I'm definitely not a major authority in Spectre. However, the attack should not be considered limited to sandboxes and JIT and such. -- Rich
Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On Mon, Jan 29, 2018 at 1:56 PM, Mick wrote: > On Monday, 29 January 2018 18:35:58 GMT Mike Gilbert wrote: >> On Mon, Jan 29, 2018 at 12:50 PM, Ian Zimmerman > wrote: >> > On 2018-01-29 20:11, Adam Carter wrote: >> >> Comparing the contents of >> >> /sys/devices/system/cpu/vulnerabilities/spectre_v2 >> >> >> >> With gcc 7.2 + kernel 4.14.15; >> >> Intel system shows; Vulnerable: Minimal generic ASM retpoline >> >> AMD system shows: Vulnerable: Minimal AMD ASM retpoline >> >> >> >> With gcc 7.3 + kernel 4.15.0; >> >> Intel system shows; Mitigation: Full generic retpoline >> >> AMD system shows' Mitigation: Full AMD retpoline >> > >> > Is there a simple way, with the upstream (kernel.org) sources, to force >> > a compiler different from the system default? If there is, it's not in >> > the >> > README, and a simple grep over the Makefiles also doesn't enlighten. >> > >> > I am not ready to activate a keyworded gcc for general use. >> >> You could pass CC=gcc-7.3.0 to the make command, like so: >> >> make -j6 CC=gcc-7.3.0 > > Shouldn't you have at least compiled your whole toolchain with gcc-7.3.0 > first? I don't see any reason that would be necessary.
Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On Monday, 29 January 2018 18:35:58 GMT Mike Gilbert wrote: > On Mon, Jan 29, 2018 at 12:50 PM, Ian Zimmerman wrote: > > On 2018-01-29 20:11, Adam Carter wrote: > >> Comparing the contents of > >> /sys/devices/system/cpu/vulnerabilities/spectre_v2 > >> > >> With gcc 7.2 + kernel 4.14.15; > >> Intel system shows; Vulnerable: Minimal generic ASM retpoline > >> AMD system shows: Vulnerable: Minimal AMD ASM retpoline > >> > >> With gcc 7.3 + kernel 4.15.0; > >> Intel system shows; Mitigation: Full generic retpoline > >> AMD system shows' Mitigation: Full AMD retpoline > > > > Is there a simple way, with the upstream (kernel.org) sources, to force > > a compiler different from the system default? If there is, it's not in > > the > > README, and a simple grep over the Makefiles also doesn't enlighten. > > > > I am not ready to activate a keyworded gcc for general use. > > You could pass CC=gcc-7.3.0 to the make command, like so: > > make -j6 CC=gcc-7.3.0 Shouldn't you have at least compiled your whole toolchain with gcc-7.3.0 first? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On Mon, Jan 29, 2018 at 12:50 PM, Ian Zimmerman wrote: > On 2018-01-29 20:11, Adam Carter wrote: > >> Comparing the contents of /sys/devices/system/cpu/vulnerabilities/spectre_v2 >> >> With gcc 7.2 + kernel 4.14.15; >> Intel system shows; Vulnerable: Minimal generic ASM retpoline >> AMD system shows: Vulnerable: Minimal AMD ASM retpoline >> >> With gcc 7.3 + kernel 4.15.0; >> Intel system shows; Mitigation: Full generic retpoline >> AMD system shows' Mitigation: Full AMD retpoline > > Is there a simple way, with the upstream (kernel.org) sources, to force > a compiler different from the system default? If there is, it's not in the > README, and a simple grep over the Makefiles also doesn't enlighten. > > I am not ready to activate a keyworded gcc for general use. You could pass CC=gcc-7.3.0 to the make command, like so: make -j6 CC=gcc-7.3.0
Re: [gentoo-user] Re: gcc 7.3 + kernel 4.15 = spectre_v2 fixed
On Mon, Jan 29, 2018 at 7:50 PM, Ian Zimmerman wrote: > On 2018-01-29 20:11, Adam Carter wrote: > >> Comparing the contents of /sys/devices/system/cpu/vulnerabilities/spectre_v2 >> >> With gcc 7.2 + kernel 4.14.15; >> Intel system shows; Vulnerable: Minimal generic ASM retpoline >> AMD system shows: Vulnerable: Minimal AMD ASM retpoline >> >> With gcc 7.3 + kernel 4.15.0; >> Intel system shows; Mitigation: Full generic retpoline >> AMD system shows' Mitigation: Full AMD retpoline > > Is there a simple way, with the upstream (kernel.org) sources, to force > a compiler different from the system default? If there is, it's not in the > README, and a simple grep over the Makefiles also doesn't enlighten. > > I am not ready to activate a keyworded gcc for general use. > > -- > Please don't Cc: me privately on mailing lists and Usenet, > if you also post the followup to the list or newsgroup. > To reply privately _only_ on Usenet, fetch the TXT record for the domain. > To compile the kernel with a different compiler, the method shown below may be used, e.g.: make CC=clang See [1], for details: Building the kernel with Clang: [1] https://lwn.net/Articles/734071/
