linux-kernel - Re: [RFC][PATCH] SI_ASYNCIO: should be a kernel signal ?

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] [day] [month] [year] [list]

Date:	Tue, 30 Dec 2008 15:53:26 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Cc:	oleg@...hat.com, ebiederm@...ssion.com, bastian@...di.eu.org,
	gregkh@...e.de, daniel@...ac.com, xemul@...nvz.org,
	containers@...ts.osdl.org, linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org
Subject: Re: [RFC][PATCH] SI_ASYNCIO: should be a kernel signal ?

The value of SI_ASYNCIO is part of the user ABI already, so you
can't really change it anyway.  But, there is a logic why it was
correct for it to be SI_FROMUSER (not just an old choice we are
stuck with, which it also is).

The real purpose of the SI_FROMUSER/SI_FROMKERNEL distinction is not
an abstract idea of "kernel-generated or not".  In fact, it's purely
to distinguish "forgeable" from "guaranteed exact kernel semantics".
SI_ASYNCIO is a notification about something the user asked for
specially, not one about any kernel-enforced sort of event.  If the
user wants to send himself signals with si_code=SI_ASYNCIO, then fine.
Noone's going to be fooled about who instigated such a signal.

In fact, the main use of SI_ASYNCIO signals in practice is for a user
to send them to himself.  That's what glibc (-lrt) does to implement
the POSIX aio_* calls.  The only uses in the kernel are in the USB
code related to some magic ioctls.

Those in-kernel cases call kill_pid_info_as_uid precisely for the same
issue of current vs instigating-process.  These are the only calls to
that function.  It really could be called something else like
"kill_self_from_interrupt", because its only use is this case that's
considered to be, "I'm sending it to myself, delayed."  That is, it
caches the uid/euid along with the struct pid to itself, in case of
instigating it, changing uids, and then having the interrupt deliver
the signal to the same process that is now differently-privileged.

It's not real clear you care about the old vs new pid namespace the
same way we care about the old vs new current_cred.  Since the sender
can only be "myself" or "my former self", maybe just call it "myself"
and be done with it--you just don't need any check in this path.

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/