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:	Fri, 20 May 2011 09:56:22 +0100
From:	Pedro Alves <pedro@...esourcery.com>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	Tejun Heo <tj@...nel.org>, oleg@...hat.com,
	jan.kratochvil@...hat.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	indan@....nu, bdonlan@...il.com
Subject: Re: [PATCH 03/10] ptrace: implement PTRACE_SEIZE

On Friday 20 May 2011 02:44:44, Denys Vlasenko wrote:
> > > > In GDBs case, GDB will want to poke at memory
> > > > right after attaching
> > > 
> > > ...where "right after attaching" is defined as "when the first ptrace-stop
> > > is reported". Which will happen very soon.
> > 
> > Hmm?  Why would it happen very soon?
> > Isn't the point of SEIZE not 
> > interrupting that you'd not get any INTERRUPT or stop at all?
> > Where is the ptrace-stop coming from?
> 
> From PTRACE_INTERRUPT. Without it, tracee is running. 

> Ptrace API never allowed poking of running tracees.

Which is a bit lame.

> You need to stop it first.

That was my point...  I was just pointing out that GDB will end
up PTRACE_INTERRUPTing the target anyway.  Maybe we could extend
GDB's "observer" mode to be even more observer-only, and delay
reading the DSO list and whatever else GDB does on attach until
the first stop, or to user request.  Some archs need reading
registers as soon as possible in order to actually know which
arch variant we've attached to.  Anyway, this is GDBs business.
SEIZE not interrupting won't hurt GDB, and is obviously useful for
some use cases and tracers, _provided the race with SETOPTS is fixed_.

-- 
Pedro Alves
--
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