On Fri, Jan 5, 2018 at 5:40 AM, Woodhouse, David <d...@amazon.co.uk> wrote: > On Thu, 2018-01-04 at 21:01 -0500, james harvey wrote: >> >> >> I understand the GCC patches being discussed will fix the >> vulnerability because newly compiled kernels will be compiled with a >> GCC with these patches. > > The GCC patches work by eliminating all indirect branches, thus > avoiding 'variant 2' of the three problems which have been discovered. > > Note that we also need to eliminate all the indirect branches which > occurred in native assembler code too, and provide the 'thunks' that > GCC uses instead, which is why there's a series of kernel patches to go > with it. > > But building a kernel this way is *only* sufficient to protect the > kernel. Attacks between userspace processes are still possible — you > need the updated microcode, with branch-predictor flushes/restrictions, > to protect existing userspace processes from each other. > >> But, are the GCC patches being discussed also expected to fix the >> vulnerability because user binaries will be compiled using them? > > It would be possible to do that. Sensitive userspace processes could be > built this way, rendering them invulnerable to 'variant 2' attacks > without the kernel having to use the microcode features. > >> In such case, a binary could be maliciously changed back, or a custom GCC >> made with the patches reverted. > > If the attacker can replace the sensitive binary, or replace the > compiler with which the sensitive binary was compiled, then we have > other problems. I'm not going to lose sleep over that. > > > Note that *none* of this addresses 'variant 1'. There's a separate > patch series which addresses likely 'variant 1 gadgets' in the kernel, > which I haven't seen posted in public yet. And I'm not sure what we do > about that for userspace except extending the existing Coverity ruleset > and teaching GCC to emit barriers automatically in the right places, > which is a bit far-fetched right now. Elena? > Amazon Web Services UK Limited. Registered in England and Wales with > registration number 08650665 and which has its registered office at 60 > Holborn Viaduct, London EC1A 2FD, United Kingdom.
I could have written more clearly. What I'm getting at is if any of the GCC patches are intended to prevent an exploit from being able to be attempted, rather than making binaries immune from attacks. So, I don't mean being able to modify a sensitive binary or the system's compiler. I mean someone has non-root SSH access. Compiles GCC with whatever patches wind up for variant 1-3 reverted, or uses an old version. Leaves their custom compiled GCC in their user directory, to compile malicious code. Executes the compiled malicious code from their user directory. (Or, compiles a malicious program on their own system compatible in architecture, kernel and library versions, using GCC without new patches, and just copies over the binary to their user directory to execute.) Or, malicious customer with a VM on a shared machine who has root access within their VM, reverting GCC patches attempting to see into the host or other VM's on the machine.
