similar to: add Spectre variant 2 mitigations

Anyone see any reason not to add these extra compiler/linker flags if they're supported? Index: aclocal.m4 =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/aclocal.m4,v retrieving revision 1.8 diff -u -p -r1.8 aclocal.m4 --- aclocal.m4 20 May 2011 01:45:25 -0000 1.8 +++ aclocal.m4 17 Dec 2012 03:56:32 -0000 @@ -21,6 +21,23 @@

Hi all. Any reason not to turn these on if the system supports them? They're cheap but not free (a bit under 1% slower to run the complete regress suite in a completely unscientific test). They're based on info from these places: https://wiki.ubuntu.com/ToolChain/CompilerFlags http://wiki.debian.org/Hardening http://www.gentoo.org/proj/en/hardened/gnu-stack.xml and I've attempted to

Verifying a report I just got pinged about, building vanilla openssh 7.7p1 on linux configures ok, but fails build around 'retpoline' I've started looking through recent reports; haven't _yet_ found anything similar. While I continue, is any of the following familiar/expected? Either known bug/issue or env conflict? The current env includes supposedly retpoline-ready GCC 8.1.1,

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

hi On 6/7/18 4:03 PM, Darren Tucker wrote: > On 8 June 2018 at 07:09, PGNet Dev <pgnet.dev at gmail.com> wrote: >> Verifying a report I just got pinged about, building vanilla openssh 7.7p1 on linux configures ok, but fails build around 'retpoline' > [...] >> Should the retpoline flag be getting added? If so, what's needed to make LD happy with it? > >

We recently discovered that our OpenSSH distribution binaries contain retpoline thunks. It's due to this OSSH_CHECK_CFLAG_COMPILE([-mfunction-return=thunk]) # gcc OSSH_CHECK_CFLAG_COMPILE([-mindirect-branch=thunk]) # gcc This was quite surprising because at least the GNU/Linux userspace has no provisions for retpolines. You also fail to enable -fno-plt, so you need

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

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

What are the patches that I can download and install to be protected against the Meltdown and Spectre security vulnerabilities? ===BEGIN SIGNATURE=== Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 30 Oct 2017 [1] https://tdtemcerts.wordpress.com/ [2] http://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming ===END SIGNATURE===

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

Hi All, Over the last few weeks I have been developing an LLVM Utility pass to check a program at the IR level for Spectre variant 1 (bounds check bypass) vulnerabilities. The pass was initially developed for internal use. However, as it has proved to be useful we have decided to share it with the LLVM community. The pass currently must be enabled with -mllvm -enable-sceptre. When it finds

Sending a note here as this seems likely to be of relatively broad interest. Thread: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html Review link: https://reviews.llvm.org/D41723# -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180104/78682480/attachment.html>

Awesome, replied. We've been working on similar things, but didn't have them ready-to-publish due to slightly lower urgency (there are reasonable ways to locally mimic these kinds of things in sensitive areas like the Linux kernel, and even finding code patterns for variant #1 is substantially harder). We have some significantly different APIs we'd like to discuss here based on

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,

I have a clean install, fully updated CentOS 6 32-bit. When I run the Red Hat detection script: https://access.redhat.com/sites/default/files/spectre-meltdown--a79614b.sh it finds that the system is vulnerable. Is this false positive or there is no patches for CentOS 6 32-bit systems? Thank you, -- Peter

Hi Johnny, Thank you for your reply. It seems to me that my message may have came around as offensive but that was not my intend. I have basic understanding how things work and when I said CentOS I actually meant Red Hat and all its derivatives. I asked CentOS community because that's the community I'm member of. Not to say that CentOS is not secure or anything like that. Anyway,

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