From owner-freebsd-arch@FreeBSD.ORG Fri Sep 6 21:21:30 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22D8620E; Fri, 6 Sep 2013 21:21:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9A28266F; Fri, 6 Sep 2013 21:21:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1580AB958; Fri, 6 Sep 2013 17:21:29 -0400 (EDT) From: John Baldwin To: Konstantin Belousov , "Robert N. M. Watson" Subject: Re: Extending MADV_PROTECT Date: Fri, 6 Sep 2013 17:21:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <201307161130.40737.jhb@freebsd.org> <20130716171648.GI5991@kib.kiev.ua> In-Reply-To: <20130716171648.GI5991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201309061721.28175.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 06 Sep 2013 17:21:29 -0400 (EDT) Cc: 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: Fri, 06 Sep 2013 21:21:30 -0000 On Tuesday, July 16, 2013 1:16:48 pm Konstantin Belousov wrote: > On Tue, Jul 16, 2013 at 11:30:40AM -0400, John Baldwin wrote: > > 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?) > Yes, probably needs a new id. I punted on this for now. > > > 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. > Well, I think that assigning non-zero value is justified. I went with a non-zero value. > > 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?) > > p_flag2 is inevitable, it seems. It would be added now, or, even if you > could avoid this, in the nearest future. I do not like mixing a flag > and a priority-like field. Ok, I've added p_flag2. The updated patch (kernel bits) is at http://people.freebsd.org/~jhb/patches/procctl2.patch -- John Baldwin