From owner-freebsd-arch@FreeBSD.ORG Sun Jul 16 06:41:01 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D864916A4DA for ; Sun, 16 Jul 2006 06:41:01 +0000 (UTC) (envelope-from lengoman@gator100.hostgator.com) Received: from gator100.hostgator.com (gator100.hostgator.com [70.87.76.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 833D143D45 for ; Sun, 16 Jul 2006 06:41:01 +0000 (GMT) (envelope-from lengoman@gator100.hostgator.com) Received: from lengoman by gator100.hostgator.com with local (Exim 4.52) id 1G20JB-0002Hu-66 for freebsd-arch@freebsd.org; Sun, 16 Jul 2006 01:40:53 -0500 To: freebsd-arch@freebsd.org From: Webactivo Videos Message-Id: Date: Sun, 16 Jul 2006 01:40:53 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator100.hostgator.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [32126 628] / [47 12] X-AntiAbuse: Sender Address Domain - gator100.hostgator.com X-Source: X-Source-Args: X-Source-Dir: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Webactivo has sent a video to you! X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 06:41:02 -0000 References Visible links Hidden links: 1. http://www.webactivo.com/video/videoslidesv2.php?id=9999&file=89&mail=freebsd-arch@freebsd.org&method=mail 2. http://www.webactivo.com/video/videoslidesv2.php?id=9999&file=89&mail=freebsd-arch@freebsd.org&method=mail 3. http://www.webactivo.com/video/videoslidesv2.php?id=9999&file=89&mail=freebsd-arch@freebsd.org&method=mail 4. http://www.webactivo.com/video/videoslidesv2.php?id=9999&file=89&mail=freebsd-arch@freebsd.org&method=mail 5. http://www.webactivo.com/video/videoslidesv2.php?id=9999&file=89&mail=freebsd-arch@freebsd.org&method=mail 6. http://www.webactivo.com/video/videoslidesv2.php?id=9999&file=89&mail=freebsd-arch@freebsd.org&method=mail 7. http://www.webactivo.com/video/videoslidesv2.php?id=9999&file=89&mail=freebsd-arch@freebsd.org&method=mail From owner-freebsd-arch@FreeBSD.ORG Mon Jul 17 14:39:50 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D04E116A4E1 for ; Mon, 17 Jul 2006 14:39:50 +0000 (UTC) (envelope-from jenny@bnssc.com) Received: from smtp.xspedius.net (smtp1.xspedius.net [207.191.70.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 971E143D46 for ; Mon, 17 Jul 2006 14:39:50 +0000 (GMT) (envelope-from jenny@bnssc.com) Received: from bnssc.com (unknown [207.191.5.118]) by smtp.xspedius.net (Postfix) with SMTP id D18E233C086 for ; Mon, 17 Jul 2006 09:33:26 -0500 (CDT) Date: Mon, 17 Jul 2006 09:39:49 -0600 Mime-version: 1.0 From: To: Freebsd-arch Message-Id: <717939.EIQRYUKI@bnssc.com> Content-type: text/plain; charset="ISO-8859-1"; format=flowed Content-transfer-encoding: quoted-printable Subject: [Fwd: Poster Promotion] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 14:39:50 -0000 they're having this promotion where you can get an 18 x 24 poster printed f= rom your own files at zero cost and you don't pay for shipping either=2E the= se are THE poster guys=2E you can get 50 color 18 x 24 posters for like $175=2E thought you might be i= nterested :) its at http://www=2Exeikonprints=2Ecom -Jenny From owner-freebsd-arch@FreeBSD.ORG Mon Jul 17 23:02:19 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 518B416A4DA for ; Mon, 17 Jul 2006 23:02:19 +0000 (UTC) (envelope-from peter@wemm.org) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4DD043D45 for ; Mon, 17 Jul 2006 23:02:18 +0000 (GMT) (envelope-from peter@wemm.org) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id C751F19766; Mon, 17 Jul 2006 16:02:18 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Mon, 17 Jul 2006 16:02:18 -0700 User-Agent: KMail/1.9.3 References: <20060711191607.21197.qmail@web36512.mail.mud.yahoo.com> <20060712034832.GA33934@duncan.reilly.home> In-Reply-To: <20060712034832.GA33934@duncan.reilly.home> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607171602.18621.peter@wemm.org> Cc: Subject: Re: FreeBSD support for Mac OS X platform X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 23:02:19 -0000 On Tuesday 11 July 2006 20:48, Andrew Reilly wrote: > (a) Mac OS X has cvs installed out of > the box, in /usr/bin/cvs. It's version 1.11.20, wich is a > good bit *more* recent than the version 1.11.17 that FreeBSD > is still using (why? incompatabilities with developers' pet > scripts?) Because we have thousands of lines of changes to CVS that need careful merging. We generally apply the security patches instead unless there has been a compelling feature we need. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Wed Jul 19 19:11:49 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 726CD16A4DE for ; Wed, 19 Jul 2006 19:11:49 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ED6E43D58 for ; Wed, 19 Jul 2006 19:11:46 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 1C3012C2A72 for ; Wed, 19 Jul 2006 14:11:42 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TUFb-Nk77Iei for ; Wed, 19 Jul 2006 14:11:41 -0500 (CDT) Received: from [216.63.78.18] (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 7605E2C2A6C for ; Wed, 19 Jul 2006 14:11:41 -0500 (CDT) Message-ID: <44BE83EC.9060104@cs.rice.edu> Date: Wed, 19 Jul 2006 14:11:40 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050817 X-Accept-Language: en-us, en MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: On the coming demise of debug.mpsafevm and pmap_page_protect() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2006 19:11:49 -0000 In the coming days, I am planning on removing debug.mpsafevm and pmap_page_protect() from the virtual memory system. As for debug.mpsafevm, all of the architectures in CVS have it enabled by default, some for over two years. The only impact should be on the nascent MIPS port. As for pmap_page_protect(), the proposed commit message follows. Add pmap_clear_write() to the interface between the virtual memory system's machine-dependent and machine-independent layers. Once pmap_clear_write() is implemented on all of our supported architectures, I intend to replace all calls to pmap_page_protect() by calls to pmap_clear_write(). Why? Both the use and implementation of pmap_page_protect() in our source tree has subtle errors, specifically, the management of execute permission is broken on some architectures. The "prot" argument to pmap_page_protect() should behave differently from the "prot" argument to other pmap functions. Instead of meaning, "give the specified access rights to all of the physical page's mappings," it means "don't take away the specified access rights from all of the physical page's mappings, but do take away the ones that aren't specified." However, owing to our i386 legacy, i.e., no support for no-execute rights, all but one invocation of pmap_page_protect() specifies VM_PROT_READ only, when the intent is, in fact, to remove only write permission. Consequently, a faithful implementation of pmap_page_protect(), e.g., ia64, would remove execute permission as well as write permission. On the other hand, some architectures that support execute permission have basically ignored whether or not VM_PROT_EXECUTE is passed to pmap_page_protect(), e.g., amd64 and sparc64. This change represents the first step in replacing pmap_page_protect() by the less subtle pmap_clear_write() that is already implemented on amd64, i386, and sparc64. Discussed with: grehan@ and marcel@ From owner-freebsd-arch@FreeBSD.ORG Fri Jul 21 10:40:48 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B2EB16A4DE for ; Fri, 21 Jul 2006 10:40:48 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13C7543D45 for ; Fri, 21 Jul 2006 10:40:46 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail11.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6LAei05021798 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 21 Jul 2006 20:40:45 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6LAeiVB001613 for ; Fri, 21 Jul 2006 20:40:44 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6LAeiZQ001612 for freebsd-arch@freebsd.org; Fri, 21 Jul 2006 20:40:44 +1000 (EST) (envelope-from peter) Date: Fri, 21 Jul 2006 20:40:44 +1000 From: Peter Jeremy To: freebsd-arch@freebsd.org Message-ID: <20060721104044.GB728@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Subject: mlock(2) for ordinary users X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 10:40:48 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Currently mlock() and munlock() are restricted to the root user - which prevents an ordinary user locking their process into RAM to the detriment of the system as a whole. Whilst this is a valid concern, there are good security reasons for allowing a user to lock small amounts of memory (a few pages) to ensure that sensitive information (private keys, passwords etc) don't wind up on swap devices. There is a resource limit for locked pages (RLIMIT_MEMLOCK) and, despite the man page, a quick look at the code implies that it really is honoured. Could someone with more VM-foo please confirm whether the last line of the man page is still correct. I would like to suggest that the suser() tests in mlock() and munlock() be removed and the default RLIMIT_MEMLOCK is reduced from infinity to (say) 1. The only gotcha I can see is that lots of sysctl() functions use RLIMIT_MEMLOCK via sysctl_wire_old_buffer() and vslock(). Comments please. --=20 Peter Jeremy --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEwK8q/opHv/APuIcRAhCGAJ4+CkNN8K/bJDda3BlCLFh3gCsxcwCeNeqr a8S48ah08wOV/5k37N9o+yo= =Xaxb -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From owner-freebsd-arch@FreeBSD.ORG Sat Jul 22 14:52:42 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53BED16A4DF for ; Sat, 22 Jul 2006 14:52:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2066943D46 for ; Sat, 22 Jul 2006 14:52:40 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id DA6E546C11; Sat, 22 Jul 2006 10:52:37 -0400 (EDT) Date: Sat, 22 Jul 2006 15:52:37 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Jeremy In-Reply-To: <20060721104044.GB728@turion.vk2pj.dyndns.org> Message-ID: <20060722154606.N54846@fledge.watson.org> References: <20060721104044.GB728@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: mlock(2) for ordinary users X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 14:52:42 -0000 On Fri, 21 Jul 2006, Peter Jeremy wrote: > Currently mlock() and munlock() are restricted to the root user - which > prevents an ordinary user locking their process into RAM to the detriment of > the system as a whole. Whilst this is a valid concern, there are good > security reasons for allowing a user to lock small amounts of memory (a few > pages) to ensure that sensitive information (private keys, passwords etc) > don't wind up on swap devices. > > There is a resource limit for locked pages (RLIMIT_MEMLOCK) and, despite the > man page, a quick look at the code implies that it really is honoured. > Could someone with more VM-foo please confirm whether the last line of the > man page is still correct. > > I would like to suggest that the suser() tests in mlock() and munlock() be > removed and the default RLIMIT_MEMLOCK is reduced from infinity to (say) 1. > The only gotcha I can see is that lots of sysctl() functions use > RLIMIT_MEMLOCK via sysctl_wire_old_buffer() and vslock(). I think I'd like to see the functionality you suggest -- i.e., the ability to allocate pinned memory pages to unprivileged processes. However, I have to wonder about whether this isn't already enabled for a reason -- in particular, I have to wonder if it works at all. The whole idea of resources limits is that you bill new use to a credential, and credit reduced use to a similar credential. Probably, we're interested only in memory pinned at the request of the process, not memory pinned by the kernel on its behalf. The normal questions I'd try to answer about whether it works currently are: - When pages become locked on behalf of a credential, is it correctly billed to the credential? - When pages become unlocked (or are released), are any credentials that have requested it be locked credited? - What happens when the credential on a process changes between when memory is locked and unlocked? - What happens if more than one credential requests the same page of memory be locked and unlocked? - Is locked memory properly credited back to the credential on process exit and other non-explicit unmapping points? Note in particular that more than one credential can request that the same page be locked -- if two processes map the same page from a file, or one is a fork of the other and has inheritted a shared mapping, we need to handle that "correctly". And we need to handle cases like setuid -- as with other resource limit implementations, the right credential needs to be credited. In the case of socket limits, for example, we actually keep a reference to the allocating credential in the struct socket so that when the socket is freed, we can credit the resources back to the original credential, not to the credential of whatever process last references the socket. Presumably something similar would be required here, and a quick glance doesn't suggest this is implemented. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Sat Jul 22 15:16:38 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6BA716A4DA; Sat, 22 Jul 2006 15:16:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED93143D46; Sat, 22 Jul 2006 15:16:37 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k6MFGWc7068119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Jul 2006 18:16:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6) with ESMTP id k6MFGXVm025105; Sat, 22 Jul 2006 18:16:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k6MFGVrx025104; Sat, 22 Jul 2006 18:16:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Jul 2006 18:16:31 +0300 From: Kostik Belousov To: Robert Watson Message-ID: <20060722151631.GB1217@deviant.kiev.zoral.com.ua> References: <20060721104044.GB728@turion.vk2pj.dyndns.org> <20060722154606.N54846@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y5rl02BVI9TCfPar" Content-Disposition: inline In-Reply-To: <20060722154606.N54846@fledge.watson.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=0.4 required=5.0 tests=ALL_TRUSTED, DNS_FROM_RFC_ABUSE,SPF_NEUTRAL autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on fw.zoral.com.ua Cc: freebsd-arch@freebsd.org Subject: Re: mlock(2) for ordinary users X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 15:16:38 -0000 --Y5rl02BVI9TCfPar Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 22, 2006 at 03:52:37PM +0100, Robert Watson wrote: >=20 > On Fri, 21 Jul 2006, Peter Jeremy wrote: >=20 > >Currently mlock() and munlock() are restricted to the root user - which= =20 > >prevents an ordinary user locking their process into RAM to the detrimen= t=20 > >of the system as a whole. Whilst this is a valid concern, there are goo= d=20 > >security reasons for allowing a user to lock small amounts of memory (a= =20 > >few pages) to ensure that sensitive information (private keys, passwords= =20 > >etc) don't wind up on swap devices. > > > >There is a resource limit for locked pages (RLIMIT_MEMLOCK) and, despite= =20 > >the man page, a quick look at the code implies that it really is honoure= d.=20 > >Could someone with more VM-foo please confirm whether the last line of t= he=20 > >man page is still correct. > > > >I would like to suggest that the suser() tests in mlock() and munlock() = be=20 > >removed and the default RLIMIT_MEMLOCK is reduced from infinity to (say)= =20 > >1. The only gotcha I can see is that lots of sysctl() functions use=20 > >RLIMIT_MEMLOCK via sysctl_wire_old_buffer() and vslock(). >=20 > I think I'd like to see the functionality you suggest -- i.e., the abilit= y=20 > to allocate pinned memory pages to unprivileged processes. However, I ha= ve=20 > to wonder about whether this isn't already enabled for a reason -- in=20 > particular, I have to wonder if it works at all. The whole idea of=20 > resources limits is that you bill new use to a credential, and credit=20 > reduced use to a similar credential. Probably, we're interested only in= =20 > memory pinned at the request of the process, not memory pinned by the=20 > kernel on its behalf. The normal questions I'd try to answer about wheth= er=20 > it works currently are: >=20 > - When pages become locked on behalf of a credential, is it correctly bil= led > to the credential? >=20 > - When pages become unlocked (or are released), are any credentials that= =20 > have > requested it be locked credited? >=20 > - What happens when the credential on a process changes between when memo= ry > is locked and unlocked? >=20 > - What happens if more than one credential requests the same page of memo= ry=20 > be > locked and unlocked? >=20 > - Is locked memory properly credited back to the credential on process ex= it > and other non-explicit unmapping points? >=20 > Note in particular that more than one credential can request that the sam= e=20 > page be locked -- if two processes map the same page from a file, or one = is=20 > a fork of the other and has inheritted a shared mapping, we need to handl= e=20 > that "correctly". And we need to handle cases like setuid -- as with oth= er=20 > resource limit implementations, the right credential needs to be credited= .=20 > In the case of socket limits, for example, we actually keep a reference t= o=20 > the allocating credential in the struct socket so that when the socket is= =20 > freed, we can credit the resources back to the original credential, not t= o=20 > the credential of whatever process last references the socket. Presumabl= y=20 > something similar would be required here, and a quick glance doesn't=20 > suggest this is implemented. As far as I remember, RLIMIT_MEMLOCK is per-process instead of per-cred. As consequence, allowing mlock() for non-root users actually allow such user to allocate value-of(RLIMIT_MEMLOCK) * value-of(RLIMIT_NPROC). In fact, I had to make the answers to the asked questions when I implemented the per-user swap limits. The design I ended with was to add reference to the originating cred to vm_map_entry and vm_object (with somewhat complicated logic to move the ref from entry to object on occasion). --Y5rl02BVI9TCfPar Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEwkFPC3+MBN1Mb4gRAu4wAKC+6iWNL134WWw23h2uM7KRvoYkswCg0Iba lwwD2xrWL+fMa+9FN3vGQQE= =j3sB -----END PGP SIGNATURE----- --Y5rl02BVI9TCfPar-- From owner-freebsd-arch@FreeBSD.ORG Sat Jul 22 23:55:31 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BCBC16A4E0; Sat, 22 Jul 2006 23:55:31 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail19.syd.optusnet.com.au (mail19.syd.optusnet.com.au [211.29.132.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FB3243D53; Sat, 22 Jul 2006 23:55:30 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail19.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6MNtSom020539 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 23 Jul 2006 09:55:28 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6MNtSxW014153; Sun, 23 Jul 2006 09:55:28 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6MNtS5C014152; Sun, 23 Jul 2006 09:55:28 +1000 (EST) (envelope-from peter) Date: Sun, 23 Jul 2006 09:55:28 +1000 From: Peter Jeremy To: Robert Watson , Kostik Belousov Message-ID: <20060722235528.GI728@turion.vk2pj.dyndns.org> References: <20060721104044.GB728@turion.vk2pj.dyndns.org> <20060722154606.N54846@fledge.watson.org> <20060722151631.GB1217@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XigHxYirkHk2Kxsx" Content-Disposition: inline In-Reply-To: <20060722151631.GB1217@deviant.kiev.zoral.com.ua> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-arch@freebsd.org Subject: Re: mlock(2) for ordinary users X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 23:55:31 -0000 --XigHxYirkHk2Kxsx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2006-Jul-22 18:16:31 +0300, Kostik Belousov wrote: >On Sat, Jul 22, 2006 at 03:52:37PM +0100, Robert Watson wrote: >> particular, I have to wonder if it works at all. The whole idea of=20 >> resources limits is that you bill new use to a credential, and credit=20 >> reduced use to a similar credential. Currently, most RLIMIT_xxx parameters are per-process (the exceptions are RLIMIT_NPROC and RLIMIT_SBSIZE - which are per-user). >> Probably, we're interested only in=20 >> memory pinned at the request of the process, not memory pinned by the=20 >> kernel on its behalf. Should memory wired via sysctl_wire_old_buffer() count as "at the request of the process" or "by the kernel on its behalf"? Currently, it's treated as the former. The following takes "credential" as "process" since that's how wired memory is currently billed. >> - When pages become locked on behalf of a credential, is it correctly bi= lled >> to the credential? >> >> - When pages become unlocked (or are released), are any credentials that= =20 >> have requested it be locked credited? I believe these are true. This is the area where I'd appreciate assistance. >> - What happens when the credential on a process changes between when mem= ory >> is locked and unlocked? I don't think this is possible because the credential is a process. >> - What happens if more than one credential requests the same page of mem= ory=20 >> be locked and unlocked? This is another area that would need further examination. >> - Is locked memory properly credited back to the credential on process e= xit >> and other non-explicit unmapping points? Process exit is not relevant. I'm not sure about implicit unwiring. >As far as I remember, RLIMIT_MEMLOCK is per-process instead of per-cred. It is. >As consequence, allowing mlock() for non-root users actually allow such >user to allocate value-of(RLIMIT_MEMLOCK) * value-of(RLIMIT_NPROC). This is no different to the other per-process resource limits. On a stock FreeBSD system, I can reach the system-wide FD limit with two user processes. I can't see that having several processes each locking RLIMIT_MEMLOCK pages provides any real benefit to the user so this is really just another DoS vector. >In fact, I had to make the answers to the asked questions when I >implemented the per-user swap limits. I didn't realise this existed. How do you control per-user swap? I can't find any reference to this in either login.conf or setrlimit(2). --=20 Peter Jeremy --XigHxYirkHk2Kxsx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEwrrw/opHv/APuIcRAoswAJ9DxXZAIaXOwxd51Lq6i/KSN09U2wCgrSzn 4Z1IN7+6VwjDEFfzWNrocA0= =x7v6 -----END PGP SIGNATURE----- --XigHxYirkHk2Kxsx--