linux-kernel - Re: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Apr 2012 13:20:02 -0700 (PDT)
From:	Roland McGrath <roland@...k.frob.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] TIF_NOTIFY_RESUME, arch/*/*/*signal*.c and all such

> 	BTW, I'm somewhat tempted to do the following: *ALL* calls of
> tracehook_signal_handler() are now immediately preceded by block_signals().
> Moreover, tracehook_signal_handler(...., 0) is currently a no-op, so
> it could be painlessly added after the remaining block_signals() instances.
> How about *folding* block_signals() (along with clear_restore_sigmask())
> into tracehook_signal_handler()?  I don't know if anyone has conflicting
> plans for that sucker; Roland?

I'm not actually doing much in the way of kernel work these days so I
certainly don't have any actual plans and it's pretty much all up to Oleg.
I'm also not really following this thread in detail, as I've dropped too
much context in the last year or two to be of a whole lot of help without
spending a lot of time recovering knowledge.  

But I will say that the intent of tracehook_signal_handler has always
been what its kerneldoc says: Call it once when handler setup is
complete (exactly once per signal delivery, so potentially multiple
times before actually returning to user mode).  Though it is indeed a
no-op today when stepping==0, we want its use to continue to conform
to that exact definition so that one day we could add e.g. a
PTRACE_EVENT_SIGNAL_HANDLED feature just by hacking tracehook.h and
not have to go back into every arch's signal code and recover
understanding of how the call is being used.  (It was more than enough
work to do that once when I broke out and documented the tracehook.h
interfaces the first time.)  You know, as if we thought modularity
were a useful notion.

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/