linux-kernel - Re: [PATCH -mm] utrace: nommu fixup support utrace

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:	Thu,  8 Mar 2007 23:37:11 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	David Howells <dhowells@...hat.com>
Cc:	bryan.wu@...log.com, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm] utrace: nommu fixup support utrace 

I understand the NOMMU situation, and you are already screwed by
PTRACE_ATTACH.  What I meant to suggest is that I would start from a
safety point of view with get_user_pages/access_process_vm refusing to
do force&&write to MAP_PRIVATE pages that are in fact being shared
(ETXTBSY or something).  (When it's not being shared, it should do
whatever is necessary to make sure that page is known dirty and not
hand it out for later mappings.)  Then you can go about trying to make
the safe (no sharing) case come about when you want it.  You still
won't win with PTRACE_ATTACH and the like unless you happen not to
have sharing in the places you insert your breakpoints at the time.
But at least the debugger will just lose, instead of breaking
unsuspecting processes.  With the utrace patches, you can approximate
the ptrace check you had with something like:

	if (tracehook_consider_fatal_signal(current, SIGTRAP))

or whatever signal you think poking text might result in that the
debugger will be looking for (atm it doesn't actually matter what
signo you pass).  This returns true when ptrace is in use, and
probably also for later utrace-based ways a debugger attaches if it is
expecting ahead of time to be debugging heavily as with breakpoints.
(And that's about the best you can do for a single address space system.)

Thanks,
Roland
-
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/