From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934020AbcAYVgF (ORCPT ); Mon, 25 Jan 2016 16:36:05 -0500 Received: from mail.kernel.org ([198.145.29.136]:46622 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756463AbcAYVeW (ORCPT ); Mon, 25 Jan 2016 16:34:22 -0500 From: Andy Lutomirski To: X86 ML Cc: "linux-kernel@vger.kernel.org" , Brian Gerst , Denys Vlasenko , Borislav Petkov , Stas Sergeev , Cyrill Gorcunov , Pavel Emelyanov , Andy Lutomirski Subject: [PATCH v3 1/4] x86/signal/64: Add a comment about sigcontext->fs and gs Date: Mon, 25 Jan 2016 13:34:12 -0800 Message-Id: X-Mailer: git-send-email 2.5.0 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org These fields have a strange history. This tries to document it. This borrows from 9a036b93a344 ("x86/signal/64: Remove 'fs' and 'gs' from sigcontext"), which was reverted by ed596cde9425 ("Revert x86 sigcontext cleanups"). Signed-off-by: Andy Lutomirski --- arch/x86/include/uapi/asm/sigcontext.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/arch/x86/include/uapi/asm/sigcontext.h b/arch/x86/include/uapi/asm/sigcontext.h index d485232f1e9f..47dae8150520 100644 --- a/arch/x86/include/uapi/asm/sigcontext.h +++ b/arch/x86/include/uapi/asm/sigcontext.h @@ -341,6 +341,25 @@ struct sigcontext { __u64 rip; __u64 eflags; /* RFLAGS */ __u16 cs; + + /* + * Prior to 2.5.64 ("[PATCH] x86-64 updates for 2.5.64-bk3"), + * Linux saved and restored fs and gs in these slots. This + * was counterproductive, as fsbase and gsbase were never + * saved, so arch_prctl was presumably unreliable. + * + * If these slots are ever needed for any other purpose, there + * is some risk that very old 64-bit binaries could get + * confused. I doubt that many such binaries still work, + * though, since the same patch in 2.5.64 also removed the + * 64-bit set_thread_area syscall, so it appears that there is + * no TLS API beyond modify_ldt that works in both pre- and + * post-2.5.64 kernels. + * + * There is at least one additional concern if these slots are + * recycled for another purpose: some DOSEMU versions stash fs + * and gs in these slots manually. + */ __u16 gs; __u16 fs; __u16 __pad0; -- 2.5.0