similar to: spectre variant 2

On 16/03/18 18:24, Fred Smith wrote: > Hi all! > > I'm running an up-to-date Centos-7 on an AMD Vishera 6300, 6 core CPU. > What kernel are you running (uname -r)? > 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

Il 07/08/19 01:02, Phil Perry ha scritto: > On 06/08/2019 14:45, Alessandro Baggi wrote: >> Il 05/08/19 20:07, Akemi Yagi ha scritto: >>> On Mon, Aug 5, 2019 at 9:21 AM Alessandro Baggi >>> <alessandro.baggi at gmail.com> wrote: >>>> >>>> Il 05/08/19 18:07, Akemi Yagi ha scritto: >>>>> On Mon, Aug 5, 2019 at 9:01 AM Alessandro

Il 07/08/19 20:15, Akemi Yagi ha scritto: > On Wed, Aug 7, 2019 at 9:00 AM Alessandro Baggi > <alessandro.baggi at gmail.com> wrote: >> >> Il 07/08/19 01:02, Phil Perry ha scritto: >>> On 06/08/2019 14:45, Alessandro Baggi wrote: > >>> Please post the actual error message in dmesg or /var/log/messages. >>> >>> It's likely that the

Does anyone know if Red Hat are working on backporting improved mitigation techniques and features from newer, 4.14.14+ kernels? $ grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable /sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline

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]

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

By now, we're sure most everyone have heard of the Meltdown and Spectre attacks. If not, head over to https://meltdownattack.com/ and get an overview. Additional technical details are available from Google Project Zero. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The FreeBSD Security Team was notified of the issue in late December and received a

By now, we're sure most everyone have heard of the Meltdown and Spectre attacks. If not, head over to https://meltdownattack.com/ and get an overview. Additional technical details are available from Google Project Zero. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The FreeBSD Security Team was notified of the issue in late December and received a

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

On Tue, Feb 6, 2018 at 4:46 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Wed, 2018-02-07 at 00:36 +0000, Chandler Carruth wrote: > > > > > > > That would be __x86_indirect_thunk but the kernel doesn't use it. > > > We use -mindirect-branch-register and only ever expect the compiler > > > to use the register versions which are

On Mon, Sep 14, 2020 at 8:42 AM Yedidyah Bar David <didi@redhat.com> wrote: > > On Mon, Sep 14, 2020 at 12:28 AM wodel youchi <wodel.youchi@gmail.com> wrote: > > > > Hi, > > > > Thanks for the help, I think I found the solution using this link : https://www.berrange.com/posts/2018/06/29/cpu-model-configuration-for-qemu-kvm-on-x86-hosts/ > > > >

Also, could you patch and test Clang with the Linux kernel after I make this change? I'd like to know that we actually successfully call the correct thunks and that they behave correctly. I'm not super worried, but good to actually get this right. I'm am slightly more worried about the stack-based retpoline than the register ones just due to the overall lower amount of testing

The patch is up for review here: https://reviews.llvm.org/D42998 On Tue, Feb 6, 2018 at 4:58 PM Chandler Carruth <chandlerc at google.com> wrote: > Also, could you patch and test Clang with the Linux kernel after I make > this change? I'd like to know that we actually successfully call the > correct thunks and that they behave correctly. I'm not super worried, but >

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

The proposed mitigation for variant 2 of CVE-2017-5715, “branch target injection”, is to send all indirect branches through an instruction sequence known as a retpoline. Because the purpose of a retpoline is to prevent attacker-controlled speculation, we also end up losing the benefits of benign speculation, which can lead to a measurable loss of performance. We can regain some of those benefits

Wouldn't a branch funnel open the door to a type 1 attack? E.g. if the code looks like this, then a branch funnel basically turns into a standard type 1 pattern AFAICT: struct Base { virtual int f(long) = 0; }; struct A : Base { int f(long x) override { return 0; }; }; struct B : Base { int f(long x) override { // As in listing 1 in

Hi, Sean Silva via llvm-dev wrote: > Wouldn't a branch funnel open the door to a type 1 attack? Only if the code looks exactly as you wrote it. If I understand this correctly the problem with indirect branches is that the "gadget", the code leaking the data, could be *anywhere* in the binary, giving the attacker much more freedom. So restricting these calls to one of the

Il 05/08/19 20:07, Akemi Yagi ha scritto: > On Mon, Aug 5, 2019 at 9:21 AM Alessandro Baggi > <alessandro.baggi at gmail.com> wrote: >> >> Il 05/08/19 18:07, Akemi Yagi ha scritto: >>> On Mon, Aug 5, 2019 at 9:01 AM Alessandro Baggi >>> <alessandro.baggi at gmail.com> wrote: > >>> Do you have secureboot enabled? Then yes, that requires a

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

On Wed, Aug 7, 2019 at 9:00 AM Alessandro Baggi <alessandro.baggi at gmail.com> wrote: > > Il 07/08/19 01:02, Phil Perry ha scritto: > > On 06/08/2019 14:45, Alessandro Baggi wrote: > > Please post the actual error message in dmesg or /var/log/messages. > > > > It's likely that the kernel is just grumbling that the module is not > > signed (missing