search for: mitigation

...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 <https://www.phoronix.com/scan.php?page=news_item&px=GNU-Assembler-LVI-Options>. We should try very hard to make sure the experience doesn't diverge unnecessarily between users of gcc and clang. On Fri, Mar 20, 2020 at 6:02 PM Jame...

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 option for mitigation. Th...

...lative 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. For the full details of the vulnerability, please follow the above link. The part of the vulnerability that is relevant to the toolchain mitigations is as follows. Some processors may speculatively execute the instructions imme...

...e 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 be used as a last resort mitigation. This pass is based on ideas from Chandler Carruth and Intel. This pass is primarily intended to share with the community as a basis for experimentation and may not be production ready. We are open to upstreaming this pass if there is interest from the community. It can be removed if it becomes a m...

Hi folks, Firstly; apologies in advance for what is a head wrecker of keeping on top of the speculative mitigations and also if this is a duplicate email; my first copy didn't seem to make it into the archive. Also a disclaimer that I may have misunderstood elements of the below but please bear with me. I write this hoping to find out a bit more about the state of the relevant kernel patches for the vari...

...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 kernel commandline - IBPB: Not disabled on kernel commandline and when I run the one from github I get this: CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigated according to the /sys...

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

Thanks for the notification, Chandler. I also wanted to note that I’ve just posted another component for Spectre mitigation (variant 1), see https://reviews.llvm.org/D41760 and https://reviews.llvm.org/D41761. I believe this is completely complementary to the retpoline mitigation you pointed to at https://reviews.llvm.org/D41723#, which is targeted at mitigating variant 2. Thanks, Kristof On 4 Jan 2018, at 11:23, Cha...

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....

...reasonably large body of code. Hopefully more details soon as folks have time. On Fri, Jan 5, 2018 at 6:15 AM Kristof Beyls <Kristof.Beyls at arm.com> wrote: > Thanks for the notification, Chandler. > > I also wanted to note that I’ve just posted another component for Spectre > mitigation (variant 1), see https://reviews.llvm.org/D41760 and > https://reviews.llvm.org/D41761. > I believe this is completely complementary to the retpoline mitigation you > pointed to at https://reviews.llvm.org/D41723#, which is targeted at > mitigating variant 2. > > Thanks, > >...

...se to what Philip Reames suggested on > https://reviews.llvm.org/D41761. > Cool, we'll definitely need *some* intrinsic in the IR to help model source annotations. I still need to think a bit about the interface and model for this... > > Then a later patch (D49072) adds automatic mitigation by inserting the > intrinsic > in necessary locations. > I was never able to get automatic mitigation with an intrinsic to avoid really signiifcant performance problems in the x86 backend. I'll look through your approach to see if you figured out a technique that works better than the...

Hi all, I saw the retpoline mitigation landed in r323155. Are we ready to merge this to 6.0, or are there any open issues that we're waiting for? Also, were there any followups I should know about? Also, release notes please :-) Thanks, Hans -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://...

...ity – and might potentially ease the requirements on the OS? Thanks! Kristof On 23 Mar 2018, at 11:56, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: 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....

On Wed, 2018-03-07 at 02:33 +0000, Daniel Migowski via samba wrote: > Hai, > > Already tried the bad user option. Samba still answers the client > that guest mode is to be used, but here is the problem. Windows 10 > forbids guest mode now because of Security concerns! I need a way for > Samba to accept the challenge response answer regardless of the user > so Windows believes

Hai, Already tried the bad user option. Samba still answers the client that guest mode is to be used, but here is the problem. Windows 10 forbids guest mode now because of Security concerns! I need a way for Samba to accept the challenge response answer regardless of the user so Windows believes it was authenticated. Any hack no matter how dirty is greatly appreciated. Greetings, Daniel Migowski

.... Thus if libguestfs is examining an untrusted guest and the libguestfs appliance/daemon is compromised (eg. by executing guest commands, or through some other compromise), then the compromised appliance will not be able to issue the above SG_IO ioctls and exploit the host. Note that this is just mitigation for libguestfs. Users will still want to fully update their host kernel, qemu/KVM and libvirt, in order to prevent other (non-libguestfs) routes to compromise. The following versions of libguestfs (will/have) this patch applied. libguestfs >= 1.15.13 libguestfs >= 1.14.8 libguestfs &...

Thanks Kelvin I'm a bit confised tho, is this patch already avaiable? if yes, what is the parameter that disable ssl into the smb.conf? Maybe the guys from Enterprise samba have already included the patch into their releases so it's just a maatter of enabling the flag. I'm using sernet-samba-4.2.2 Thanks!

Hi. Both GCC and clang are adding mitigations for Spectre variant 2 although neither have yet made a release and neither are on by default. After trolling through and building release candidate branches for both I believe this is what is required for the ssh programs (although all the dependent libraries will also need to be built with mitig...

I've built & tagged packages for CentOS 6 and 7 4.6.6-9, with XPTI "stage 1" Meltdown mitigation. This will allow 64-bit PV guests to run safely (with a few caveats), but incurs a fairly significant slowdown for 64-bit PV guests on Intel boxes (including domain 0). If you prefer using Vixen / Comet, you can turn it off by adding 'xpti=0' to your Xen command-line. Detailed informatio...

...imple, just run pktgen (pktgen_sample01_simple.sh) in >>>> guest and measure PPS on tap on host. >>>> >>>> Thanks >>> >>> Could you supply host configuration involved please? >> >> I wonder how much of that could be caused by Spectre mitigations >> blowing up indirect function calls... >> >> Cheers, >> Ben. > > I won't be surprised. If yes I suggested a way to mitigate the overhead. Did we get better results (lower regression due to indirect calls) with the suggested mitigation ? Just curious.