linux-kernel - Re: perf: overflow signal survives an exec call starting in 3.0

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, 25 Aug 2011 16:37:45 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Vince Weaver <vweaver1@...s.utk.edu>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, paulus@...ba.org,
	acme@...stprotocols.net, Stephane Eranian <eranian@...il.com>,
	krentel@...rice.edu
Subject: Re: perf: overflow signal survives an exec call starting in 3.0

On Tue, 2011-08-23 at 11:36 -0400, Vince Weaver wrote:
> I'm guessing this was an unintended change, although what to do in
> this situation is a bit vague.

> 
> commit f506b3dc0ec454a16d40cab9ee5d75435b39dc50
> Author: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Date:   Thu May 26 17:02:53 2011 +0200
> 
>     perf: Fix SIGIO handling 

Ah, quite... its a combination of way too many weird things.

So that change made it possible (as requested) to receive a signal
without having to mmap() the buffer, which seems like a perfectly sane
thing.

Now, looking at fs/exec.c:setup_new_exec() we see that we only call
perf_event_exit_task() when we cross a security domain. 

Previously the exec() would have wiped out the mmap, and hence the
counter would have stopped sending signals (but not stopped counting).

Now exec() doesn't normally close fds, so the counter stays around and
with the new scheme continues sending signals.

I think the message is, don't do that then.. and use fcntl(fd, F_SETFD,
FD_CLOEXEC) or so.

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