From owner-freebsd-arch@FreeBSD.ORG Tue Jul 16 15:33:40 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2DDBAE58; Tue, 16 Jul 2013 15:33:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 08C46E94; Tue, 16 Jul 2013 15:33:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 56976B995; Tue, 16 Jul 2013 11:33:39 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: Extending MADV_PROTECT Date: Tue, 16 Jul 2013 11:30:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <201307121748.57778.jhb@freebsd.org> <20130713175835.GN91021@kib.kiev.ua> In-Reply-To: <20130713175835.GN91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307161130.40737.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Jul 2013 11:33:39 -0400 (EDT) Cc: arch@freebsd.org, "Robert N. M. Watson" , Jilles Tjoelker , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:33:40 -0000 On Saturday, July 13, 2013 1:58:35 pm Konstantin Belousov wrote: > On Fri, Jul 12, 2013 at 05:48:57PM -0400, John Baldwin wrote: > > On Friday, June 28, 2013 2:46:01 pm John Baldwin wrote: > > > Ok, there isn't really a clear consensus here, but I need a system call to let > > > me toggle this flag on existing processes. > > > > > > One reason I don't like the procctl() approach is I am uneasy about forcing > > > a certain behavior for how commands treat pgid (first-fail vs best-effort). > > > I guess it can always change in the future so that isn't completely unsolvable. > > > > > > I guess I am fine just making it use hardcoded sizes instead of full-blown > > > ioctl encoding. > > > > Ok, I have updated patches for this for HEAD. I have not yet implemented the > > inheritance bits because I'm loathe to add the first bit to a p_flag2. :-P > > However, if that's the best course of action I suppose we can do that. > > > > The kernel patch is at www.freebsd.org/~jhb/patches/procctl.patch > > > > The patch for the protect binary is at www.freebsd.org/~jhb/patches/protect.patch > > > > It seems that p_cansee() is called twice, once in kern_procctl(), and > then in protect_setchild(). Yes, this is because protect_setchild() can descend to child processes, and you might not be able to "see" a child process if it exec'd a suid binary, etc. > Is AUE_WAIT6 the correct audit event id for procctl ? Nope. (It probably needs a new one?) > I thought proposing to use pget() for P_PID case in kern_procctl(), but > indeed open coding of the process lookup is easier, since otherwise > you would need to move proctree_lock acquisition to P_PGID. > > Why do you need PPROT_CLEAR ? If you do need the flag, would it be better > to assign a non-zero value to it ? I need it for 'protect -c' which is similar to 'ktrace -C'. That is, to allow protection to be removed from existing processes. I added a constant for it to make the code clear as the caller should pick one of PPROT_SET or PPROT_CLEAR (kind of like MAP_PRIVATE vs MAP_SHARED for mmap(2)). Otherwise you would have 'procctl(..., PROC_SPROTECT, 0)' which is not as obvious to me as ', PPROT_CLEAR)'. Also, you can do 'PPROT_CLEAR | PPROT_DESCEND' to clear it for all descendants. Having 'PPROT_SET | PPROT_DESCEND' to set it for descendenats and just 'PPROT_DESCEND' to clear for descendants doesn't seem as readable. Do you have any thoughts on p_flag2 (vs some other approach, possibly I should create a new field for oom-specific flags instead since we may eventually store a priority there?) -- John Baldwin