From owner-freebsd-questions@FreeBSD.ORG Sun May 1 18:03:23 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0746106564A for ; Sun, 1 May 2011 18:03:23 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B38498FC0A for ; Sun, 1 May 2011 18:03:23 +0000 (UTC) Received: by vxc34 with SMTP id 34so5094890vxc.13 for ; Sun, 01 May 2011 11:03:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.66.66 with SMTP id d2mr1613763vdt.25.1304273002557; Sun, 01 May 2011 11:03:22 -0700 (PDT) Received: by 10.52.163.39 with HTTP; Sun, 1 May 2011 11:03:22 -0700 (PDT) X-Originating-IP: [93.221.190.76] In-Reply-To: References: <20110425151846.0a5359fd@gumby.homeunix.com> Date: Sun, 1 May 2011 20:03:22 +0200 Message-ID: From: "C. P. Ghost" To: Modulok Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-questions@freebsd.org Subject: Re: Password theft from memory? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 18:03:24 -0000 On Wed, Apr 27, 2011 at 9:24 PM, Modulok wrote: > I know that each process has its own private memory segment, but after a > process exits, it nolonger owns that memory. What happens to it? If it's not > zeroed out by my process, and it doesn't turn into pixie food, and it's not > zeroed out by malloc... it still exists somewhere. If I understand this correctly, when a process exits, the kernel reclaims its address space and inserts it into its own address space (i.e. in a free list). At this point, the pages are NOT (yet) zeroed out, they're merely detached from the exiting process and attached to the kernel's free list. Optionally, they may be zeroed in some time in the future, when a special kernel thread pre-zeroes some pages there for faster allocation later. In any case, when a new process starts and tries to mmap(2) those pages, the kernel VM will lazily zero them out one by one upon first access by the process. So, unless you access /dev/kmem to read virtual kernel memory directly, you have NO way of getting access to the old data, even when it is not yet zeroed. And as long as the permissions on /dev/kmem are sensibly set, only privileged processes could access kernel virtual memory. Coming to think of it, there's another exception besides /dev/kmem: a kernel module runs with kernel privileges, and has access to the pages (of all processes, and of the kernel including those on the free list). But this is to be expected: a KLD becomes a part of the kernel when loaded. > Maybe this would be best on hackers? > -Modulok- -cpghost. -- Cordula's Web. http://www.cordula.ws/