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
| ||
|
Date: Wed, 24 Mar 2010 00:57:46 -0400 (EDT) From: Oren Laadan <orenl@...columbia.edu> To: Matt Helsley <matthltc@...ibm.com> cc: Russell King - ARM Linux <linux@....linux.org.uk>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, containers <containers@...ts.linux-foundation.org>, Christoffer Dall <christofferdall@...istofferdall.dk>, linux-kernel <linux-kernel@...r.kernel.org>, Roland McGrath <roland@...hat.com> Subject: Re: [C/R ARM][PATCH 1/3] ARM: Rudimentary syscall interfaces On Tue, 23 Mar 2010, Matt Helsley wrote: > On Tue, Mar 23, 2010 at 08:53:42PM +0000, Russell King - ARM Linux wrote: > > On Sun, Mar 21, 2010 at 09:06:03PM -0400, Christoffer Dall wrote: > > > This small commit introduces a global state of system calls for ARM > > > making it possible for a debugger or checkpointing to gain information > > > about another process' state with respect to system calls. > > > > I don't particularly like the idea that we always store the syscall > > number to memory for every system call, whether the stored version is > > used or not. > > > > Since ARM caches are generally not write allocate, this means mostly > > write-only variables can have a higher than expected expense. > > > > Is there not some thread flag which can be checked to see if we need to > > store the syscall number? > > Perhaps before we freeze the task we can save the syscall number on ARM. > The patches suggest that the signal delivery path -- which the freezer > utilizes -- has the syscall number already. > > Should work since the threads must be frozen first anyway. I like the idea. However, would it also work for those cases when the freezing does not occur from the signal delivery path - e.g. for vfork and ptraced tasks ? Oren. -- 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