similar to: [cfe-dev] More verbose -mspeculative-load-hardening

Another thing to consider about your feature idea is that the output may be noisy depending on what you were hoping for. SLH tries to mitigate anything that could potentially be a problem and thus it instruments almost every branch, load, and function entry, for example. There isn't a lot of signal about what is really a gadget among the code instrumented by SLH. It really tries to be

Hi everyone! I want to clarify the purpose and design of SESES. Thus far, I've characterized it as an LVI mitigation which is somewhat incorrect. SESES was built as a "big hammer." It is intended to protect against many side channel vulnerabilities (Spectre v1, Spectre v4, LVI, etc, etc) even though it was built in response to LVI. For folks protecting against LVI, this is an

Hi everyone, Some Intel processors have a newly disclosed vulnerability named Load Value Injection. One pager on Load Value Injection: https://software.intel.com/security-software-guidance/software-guidance/load-value-injection Deep dive on Load Value Injection: https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection I wrote this compiler pass that can

I'm also a bit unclear on that point. I think one input here has to be: what are some example, existing codebases we want to mitigate, and what should the user experience be to mitigate them? I don't think we can make good engineering tradeoffs without having concrete use cases to evaluate. Another point: it seems some mitigation options have already been added to the GNU toolchain

Hi all, I understand how the speculative information flow attack works. I'm trying get my head around the spectre v1 mitigation of LLVM. In the design document here : https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening. <https://llvm.org/docs/SpeculativeLoadHardening.html#speculative-load-hardening> Example: void leak(int data);void example(int* pointer1,

Hi, Thanks for your email, I understand that the execution stalls until the predicated state is computed, then we mask pointers with all_zeros_mask if there is a mis-prediction. But I understand that as soon as the condition value is available, the processor can check about it's assumptions and revert back. That is, If the branch prediction is correct during speculation, we mask with

Hi, Yeah, now I understand the problem here. Thanks. But I too have another doubt in "Bounds check bypass store" In this example in the Speculative load hardening : unsigned char local_buffer[4];unsigned char *untrusted_data_from_caller = ...;unsigned long untrusted_size_from_caller = ...;if (untrusted_size_from_caller < sizeof(local_buffer)) { // Speculative execution enters here

Hi everyone, I followed up with some folks at Google about how we wanted to be involved in this group and we decided that Matthew Riley (mattdr at google.com) would be the right person to be involved here. Sorry about the confusion. I'd like to withdraw my request. Thanks again to everyone involved! I'm glad to see this becoming a part of how LLVM works. :) Zola Bridges On Wed, Jun

Thanks Zola, I’d rather have point-contact people, instead of having mailing lists. I have a few goals with this: Listing particular people makes it clear who’s on the hook from your organization These people can still communicate internally, but are responsible to ensure that the internal folks know what the LLVM process and disclosure restrictions are Listing a limited number of specific people

Hi Chandler, Thank you very much for sharing this! The RFC is pretty lengthy but the far majority of it makes sense to me. I’m sure I’m forgetting to react to some aspects below, but I thought I’d summarize some initial thoughts and questions I had after reading the RFC end-to-end. * I believe the same high-level principles you outline can also be used to implement the same protection on the

FYI to all: I've updated the design document to include the newly disclosed variants 1.1 and 1.2 (collectively called Bounds Check Bypass Store or BCBS). There is no change to the proposed implementation which can already robustly mitigate these variants. I've also updated my patch as we have very significant interest in getting at least an early "beta" version of this into the

Hello all, I've been working for the last month or so on a comprehensive mitigation approach to variant #1 of Spectre. There are a bunch of reasons why this is desirable: - Critical software that is unlikely to be easily hand-mitigated (or where the performance tradeoff isn't worth it) will have a compelling option. - It gives us a baseline on performance for hand-mitigation. - Combined

Great idea! Sign me up, please! On Fri, 12 Jun 2020 at 16:59, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Great! On the Apple side, we’ll propose Oliver Hunt (clang team) and Scotty Bolin (product security team), CC’ed to this email. > > > On Jun 12, 2020, at 6:50 AM, Kristof Beyls <Kristof.Beyls at arm.com> wrote: > > Thank you for progressing

Hi, A new speculative cache side-channel vulnerability has been published at https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation, named "straight-line speculation”, CVE-2020-13844. In this email, I'd like to explain the toolchain mitigation we've prepared to mitigate against this vulnerability for AArch64.

On 6 February 2018 at 20:09, David Newall <openssh at davidnewall.com> wrote: > Do we need to do anything? It's not clear to me how SSH is vulnerable to > Spectre -- that is, how SSH can be used to execute a Spectre attack? I am more concerned with it being the target of a Spectre style attack. There's some long lived private data (host keys in the case of sshd, session keys

Hi all! I'm running an up-to-date Centos-7 on an AMD Vishera 6300, 6 core CPU. I note that when I run the redhat script to test for spectre & meltdown I get this result for variant 2: Variant #2 (Spectre): Vulnerable CVE-2017-5715 - speculative execution branch target injection - Kernel with mitigation patches: OK - HW support / updated microcode: NO - IBRS: Not disabled on

On 01/22/2018 10:06 AM, Valeri Galtsev wrote: > > > On 01/22/18 09:08, Johnny Hughes wrote: >> On 01/18/2018 09:42 AM, Valeri Galtsev wrote: >>> >>> >>> On 01/18/18 03:41, Pete Biggs wrote: >>>> >>>>> Look at: >>>>> >>>>> https://t.co/6fT61xgtGH >>>>> >>>>> Get the

What's amazing to me is, after "Intel Inside - don't divide" (their 486 debacle), they didn't learn and have a better plan for addressing these kinds of things. ----- Original Message ----- From: "Chris Murphy" <lists at colorremedies.com> To: "centos" <centos at centos.org> Sent: Wednesday, January 24, 2018 12:06:01 PM Subject: Re: [CentOS]

Hi, I am very sorry to do this on short notice, but obviously Meltdown and Spectre are a lot more than anyone was really expecting to come down the pipeline. Xen 4.4 has been EOL upstream for about a year now and I have personally been reviewing and backporting patches based on the 4.5 versions made available upstream. Given that 4.5 is now also reaching EOL, backporting to 4.4 will become

On Mon, Aug 06, 2018 at 04:36:43PM +0300, Michael S. Tsirkin wrote: > On Mon, Aug 06, 2018 at 02:32:28PM +0530, Anshuman Khandual wrote: > > On 08/05/2018 05:54 AM, Michael S. Tsirkin wrote: > > > On Fri, Aug 03, 2018 at 08:21:26PM -0500, Benjamin Herrenschmidt wrote: > > >> On Fri, 2018-08-03 at 22:08 +0300, Michael S. Tsirkin wrote: > >