| 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
| ||
|
Message-ID: <CACM3HyHAKgJ2aTGjidZr5T9WFL3m+FTbUz_1QtO2gAgSFQm8fA@mail.gmail.com> Date: Thu, 8 Nov 2012 21:36:34 +0100 From: Jonas Bonn <jonas.bonn@...il.com> To: Vineet Gupta <Vineet.Gupta1@...opsys.com> Cc: "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "tglx@...utronix.de" <tglx@...utronix.de>, "arnd@...db.de" <arnd@...db.de> Subject: Re: [RFC PATCH v1 08/31] ARC: Fundamental ARCH data-types/defines On 8 November 2012 19:52, Vineet Gupta <Vineet.Gupta1@...opsys.com> wrote: > On 7 November 2012 10:47, Vineet Gupta <Vineet.Gupta1@...opsys.com> wrote: >> I'd recommend not exporting the pt_regs structure to userspace. This >> struct is used heavily within the kernel and it's nice to have the >> leeway to be able to modify it as things evolve. GDB doesn't need to >> know about this struct anymore as it should be using regset's for any >> recent architectures anyway, so it's the regset layout that should be >> ABI stable instead of pt_regs. >> >> You can check the openrisc architecture as an example of how to do this. > > Hi Jonas, > > thanks for your review comment. I completely agree that pt_regs should not be exported and very recently a change in pt_regs forced a gdbserver change too (ABI incompatibility) which goes along what you are recommending. Infact the ptrace patch for kernel (which will follow in series #2) provides a stable regset ABI - extracting information from pt_regs. > > However our current gdb/gdbserver is 6.8 based and making it switch to regset interface might not be possible for this release of tools. Since customers are already using our stuff, we can not have a broken ABI. We do have ABI versioning, so in next release we can fix gdb and remove this. For generic syscalls it was generally decided that the upstream kernel would drop support for legacy syscalls, _even though_ userspace bits like uClibc required them. For _new_ architectures, userspace would need to adapt to the _mainline_ kernel; and as a stop-gap for existing software, external patches could be carried in an external git repository where _non-mainline_ kernel patches could be carried to provide a working kernel until userspace could catch up. I'd say the same applies here: GDB 6.8 may continue work with a mainline kernel plus a patch that restores the export of pt_regs, but GDB 7.2 (or whatever version you move on to) would be the one that fully supports an unpatched mainline. > > Please note that an additional reason for exporting pt_regs is due to the fact that it is part of sigcontext. Keeping it exactly same as pt_regs helps us do batch save/restore of user context in signal handling (please look at my signal handling patch) but the flip side is that userspace SA_SIGINFO needs to be able to have access to sigcontext and hence we explicitly need pt_regs. We could arguably opencode pt_regs there - but that won't be clean IMHO. It's not really pt_regs you need here, but the userspace equivalent thereof. On OpenRISC, for example, we have user_regs_struct which is an ABI stable version of pt_regs. These may even be identical to begin with, but at least the distinction can be made now between the kernel-internal struct and the ABI stable one. /Jonas -- 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/
Powered by blists - more mailing lists