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]
Message-ID: <C2D7FE5348E1B147BCA15975FBA230750D9863@in01wembx1.internal.synopsys.com>
Date:	Thu, 8 Nov 2012 18:52:40 +0000
From:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:	Jonas Bonn <jonas.bonn@...il.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 7 November 2012 10:47, Vineet Gupta <Vineet.Gupta1@...opsys.com> wrote:
>> diff --git a/arch/arc/include/asm/ptrace.h b/arch/arc/include/asm/ptrace.h
>> new file mode 100644
>> index 0000000..c178357
>> --- /dev/null
>> +++ b/arch/arc/include/asm/ptrace.h
>> @@ -0,0 +1,120 @@
>> +/* THE pt_regs: Defines how regs are saved during entry into kernel */
>> +
>> +struct pt_regs {

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

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.

What do you think !

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ