similar to: Concerns about enabling retpolines by default

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

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 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 CET-compatible. > > > > However, in at least one case in the 32-bit kernel we do emit the > > old

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

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 Wed, 2018-02-07 at 00:26 +0000, Chandler Carruth wrote: > On Tue, Feb 6, 2018 at 4:16 PM Chandler Carruth <chandlerc at google.com > > wrote: > > On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org > > > wrote: > > > At this point, what we really want is for identical thunks to > > > have identical names — just like we do for

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 >

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 mitigations, and I suspect libcrypto is a more likely

On Tue, Feb 6, 2018 at 4:32 PM David Woodhouse <dwmw2 at infradead.org> wrote: > > > On Wed, 2018-02-07 at 00:26 +0000, Chandler Carruth wrote: > > On Tue, Feb 6, 2018 at 4:16 PM Chandler Carruth <chandlerc at google.com> > wrote: > > On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org> > wrote: > > At this point, what we

On Thu, Jun 07, 2018 at 06:14:42PM -0700, PGNet Dev wrote: > On 6/7/18 6:08 PM, Darren Tucker wrote: > > Well the intent is you should be able to set CC and LD to whatever you > > want as long as they work. In this case, the OSSH_CHECK_LDFLAG_LINK > > test invokes autoconf's AC_LINK_IFELSE with uses CC not LD. I'm not > > sure what to do about it yet though. I

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

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

One difference I notice is that in your failing example you are invoking /usr/bin/ld directly to link: /usr/bin/ld -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect2.o mux.o -L. -Lopenbsd-compat/ -Wl,-z,retpolineplt -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -pie -lssh -lopenbsd-compat -lutil -lz -lcrypt -lresolv whereas my example is

On Tue, Feb 6, 2018 at 4:16 PM Chandler Carruth <chandlerc at google.com> wrote: > On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org> > wrote: > >> At this point, what we really want is for identical thunks to have >> identical names — just like we do for builtins and other stuff, to avoid >> having differences between clang and GCC

Hi, Tried to build dovecot-2.3.4 on Solaris 11 x86 and it fails at configure part. I just went checked and it last version it works on is v2.3.2.1 Version 2.3.2.1 (OK) # ./configure .... checking Linux compatible mremap()... no checking whether shared mmaps get updated by write()s... yes checking whether fd passing works... yes ... Version 2.3.4 (FAIL) .... checking Linux compatible

On Tue, Feb 6, 2018 at 2:56 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Tue, 2018-02-06 at 22:08 +0000, Chandler Carruth wrote: > > So, I was waiting to hear a definitive response on whether using aliases > is hard, and didn't see one here, which is why I haven't responded further. > > However, a colleauge pointed me at an LKML thread where it seems

On 8/08/2018 5:29 pm, Thore B?decker wrote: > Hey, > > you mentioned that dovecot builds fine, but does "make check" also > complete successfully with a glibc-2.28 build on a glibc-2.28 system? > > We have been seeing segfaults during "make check" and it seems the following > patch was able to make the testsuite run successfully. > > Just out of

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

On 02/05/2018 01:33 PM, Florian Weimer wrote: > Do you have strace output going further back, at least to the proceeding > getcwd call?? It would be interesting to see which path the kernel > reports, and if it starts with "(unreachable)". I got the strace output now, but it very difficult to read (chdir in a multi-threaded process ?). My current inclination is to blame