linux-kernel - Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Mar 2015 19:19:54 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Pavel Emelyanov <xemul@...allels.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrey Wagin <avagin@...il.com>,
	Andy Lutomirski <luto@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Al Viro <viro@...iv.linux.org.uk>, X86 ML <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Borislav Petkov <bp@...en8.de>,
	Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals
 delivered to 64-bit programs

On Thu, Mar 19, 2015 at 09:08:08AM -0700, Andy Lutomirski wrote:
> >> >
> >> >> So... do we introduce somewhat nasty code into the kernel to keep old
> >> >> CRIU versions working, or do we require that users who want to restore
> >> >> onto new kernels use new CRIU?
> >> >
> >> > It's OK (I think) to require newer versions of CRIU, it's easy to update
> >> > one unlike the kernel ;)
> >> >
> >> > But if "old" version of CRIU just crash the restored processes on "new"
> >> > kernels and there's no way to detect this properly -- that's the problem.
> >>
> >> Yeah, that's unfortunate.
> >>
> >> I don't have a great idea for how to work around this, unfortunately.
> >> Ideally we'd increment some kind of version counter or use an
> >> extension mechanism rather than shoving ss into a field that used to
> >> be padding.
> >
> > fwiw currently we're passing zero in this __pad0 (replying to your
> > previous email, so we can workaround in the kernel assuming zero
> > as a special case, not that good but better than nothing).
> 
> We could store ss_plus_one instead of ss.  Yuck.

Heh, sounds like ugly-dirty-hack ;)

> The only real down side I can see to special casing zero is that it
> really is possible to end up with zero in there.  For example, the
> SIGSEGV you get do to the failed sigreturn probably has sigcontext->ss
> == 0 :)

Sure we;ve failed for exactly this reason simply because we've it
zeroified manually :) So there is no simple workaround in the kernel
for programs dumped before the kernel fix and restored on new kernel
where this patch exist but criu is old enough and has no Oleg's fix.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/