Hi All, My understanding of how these exploits work does not match most of the rhetoric surrounding "patching" them. These are attacks that steal actual data by exploiting L1 cache side effects. They are not attacks that steal or infer address mappings out of the TLB Addresses are stored in data, not least including the stack, thus stealing them by way of the cache side channel is still possible (and achievable within 128 guesses even with ASLR according to the paper).
There are 2 different mechanisms by which the data gets inserted into the cache side channel; pipelines and speculative execution. These mechanisms are attacker initiated - it's *their code* containing those pipelines and speculative exploits - not kernel etc code. Thus - retpoline is irrelevant as far as I can tell?, as are (IMHO) many other weird proposed patch solutions - no amount of kernel tweaking is going to prevent a user process pipeline or speculation - we are dealing with a CPU architecture mistake, not anything easily (if at all) addressed in software. Chris. On Sat, Jan 6, 2018 at 2:44 AM, Jim <[email protected]> wrote: > Retpoline: a software construct for preventing branch-target-injection > appears to offer a possible mitigation of CVE-2017-5715 (Spectre). > > https://support.google.com/faqs/answer/7625886 > > Allegedly Google have deployed Retpoline across their infrastructure. > > "It is predicated on the fact that many CPUs implement a separate > predictor for function returns. When available, this predictor is used > with high priority, allowing for the construction of an indirect branch > which is safe from speculation-based attacks... > > “Retpoline” sequences are a software construct which allow indirect > branches to be isolated from speculative execution. This may be applied to > protect sensitive binaries (such as operating system or hypervisor > implementations) from branch target injection attacks against their > indirect branches." > > Jim > > > > On Fri, 5 Jan 2018 12:14:43 +0000, Marco Giglio <[email protected]> > wrote: > > > By reading that advisory and information posted here ( > > https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ > ), > > it seems that there are 2 possible short-term mitigations against > > Meltdown for QubesOS 3.2 users. > > - Move PV VMs to HVM. > > - Move PV VMs to use 32-bit kernels. It should prevent to use > > Meltdown/SP3 against the hypervisor, but it won't prevent it against the > > kernel itself. Then update when newer 32-bit kernel with KPIT are > > available. > > > > Qubes 4 users shouldn't be affected by SP3/Meltdown, but should be > > affected from SP1/SP2/Spectre. > > > > > > On 01/04/2018 10:53 PM, Chris Drake wrote: > > > It is very clear: https://xenbits.xen.org/xsa/advisory-254.html > > > > > > IMPACT > > > ====== > > > > > > Xen guests may be able to infer the contents of arbitrary host memory, > > > including memory assigned to other guests. > > > > > > VULNERABLE SYSTEMS > > > ================== > > > > > > Systems running all versions of Xen are affected. > > > > > > MITIGATION > > > ========== > > > > > > There is no mitigation for SP1 and SP2. > > > > > > RESOLUTION > > > ========== > > > > > > There is no available resolution for SP1 or SP3. > > > > > > > > > For those unaware - this is a hardware fault. CPUs make use of > speculative execution (Spectre) or Pipelines (Meltdown) - both of which can > be used to attempt to access illegal memory. The access fails, however, > it's possible to use the "stolen" memory before the access-fail is enforced > in a way that makes it available on a side-channel (cache in these > exploits, but could be anything else like ports/dma) to any non-privileged > process. > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "qubes-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To post to this group, send email to [email protected]. > > To view this discussion on the web visit https://groups.google.com/d/ > msgid/qubes-devel/ade43b3a-8050-df93-aa7c-d595cbb1a7cc%40gmail.com. > > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "qubes-devel" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/qubes-devel/oHk1o2rsX60/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/qubes-devel/E1eXV6A-0005bR-Bu%40rmmprod07.runbox. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CAH6gCJA%2Bw2VFDDyC7kaqeYSG4vtN9mUPcOn%3Ds%3DxOcU0gr4HYZw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
