NetBSD Problem Report #45830

From www@NetBSD.org  Fri Jan 13 09:05:50 2012
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id C2C4B63BE07
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 13 Jan 2012 09:05:50 +0000 (UTC)
Message-Id: <20120113090549.C69E763B84C@www.NetBSD.org>
Date: Fri, 13 Jan 2012 09:05:49 +0000 (UTC)
From: manu@netbsd.org
Reply-To: manu@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: reading :dev/mem panics an i386 domU
X-Send-Pr-Version: www-1.0

>Number:         45830
>Category:       port-xen
>Synopsis:       reading :dev/mem panics an i386 domU
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-xen-maintainer
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 13 09:10:00 +0000 2012
>Closed-Date:    
>Last-Modified:  Wed Jan 18 21:28:02 +0000 2012
>Originator:     Emmanuel Dreyfus
>Release:        NetBSD-5.1
>Organization:
NetBSD
>Environment:
NetBSD bacasable.net.espci.fr 5.1_STABLE NetBSD 5.1_STABLE (XEN3_DOMU_PUFFS) #352: Fri Jan 13 10:00:13 CET 2012  root@mai.net.espci.fr:/usr/src-5/sys/arch/i386/compile/obj/XEN3_DOMU_PUFFS i386

>Description:
Reading /dev/mem crashes the kernel
>How-To-Repeat:
As root:
cat /dev/mem > /dev/null
>Fix:

>Release-Note:

>Audit-Trail:
From: Wolfgang Solfrank <Wolfgang@Solfrank.net>
To: gnats-bugs@NetBSD.org
Cc: manu@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org, 
 netbsd-bugs@netbsd.org
Subject: Re: kern/45830: reading :dev/mem panics an i386 domU
Date: Fri, 13 Jan 2012 14:09:33 +0100

 Hi,

 (Forwarding my reply to your question on tech-kern to place it
 into the PR:)

 No, this is not a bug, especially not, if this is run by root.

 /dev/mem is by definition the possibility to access the physical
 address space of the machine.  That is, apart from allowing access
 to the physical memory, it also allows access to memory mapped I/O
 etc.  Reading sequentially through this may or may not stumble upon
 one of these addresses before getting some error result (depending
 on the machine in question and the access rights).

 Access to /dev/mem requires specially crafted tools that know what
 they are doing.

 Regarding the mentioning of root in my first sentence, what I meant
 was that in (most of) our ports, there is code in the kernel that
 (depending on the secmodel in place) allows non-root users access
 only to real memory and returns an error otherwise (which happens to
 be wrong anyway, as it returns KAUTH_RESULT_* values as errno values,
 as I just found out when looking into this).

  From a security POV, access to /dev/mem should be restricted to
 root anyway (ok, based on the secmodel in place.  However, the
 current restriction of non-root access to memory only doesn't make
 too much sense; maybe a relict from some early frame buffer access?)

 Ciao,
 Wolfgang
 -- 
 Wolfgang@Solfrank.net				Wolfgang Solfrank

From: manu@netbsd.org (Emmanuel Dreyfus)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/45830: reading :dev/mem panics an i386 domU
Date: Fri, 13 Jan 2012 14:53:52 +0100

 Wolfgang Solfrank <Wolfgang@Solfrank.net> wrote:

 >  No, this is not a bug, especially not, if this is run by root.

 Then I guess that PR should be closed.

 -- 
 Emmanuel Dreyfus
 http://hcpnet.free.fr/pubz
 manu@netbsd.org

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Wolfgang Solfrank <Wolfgang@Solfrank.net>
Cc: gnats-bugs@NetBSD.org, manu@NetBSD.org, kern-bug-people@NetBSD.org,
        gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/45830: reading :dev/mem panics an i386 domU
Date: Fri, 13 Jan 2012 21:20:41 +0100

 On Fri, Jan 13, 2012 at 02:09:33PM +0100, Wolfgang Solfrank wrote:
 > Hi,
 > 
 > (Forwarding my reply to your question on tech-kern to place it
 > into the PR:)
 > 
 > No, this is not a bug, especially not, if this is run by root.

 It is a bug, the NetBSD kernel should not ask the hypervisor to
 map memory it's not allowed to map.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
        manu@NetBSD.org
Subject: Re: kern/45830: reading :dev/mem panics an i386 domU
Date: Fri, 13 Jan 2012 21:21:19 +0100

 On Fri, Jan 13, 2012 at 01:40:05PM +0000, Emmanuel Dreyfus wrote:
 >  Then I guess that PR should be closed.

 No please leave it open. There's really something wrong here.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/45830: reading :dev/mem panics an i386 domU
Date: Sun, 15 Jan 2012 07:45:05 +0000

 On Fri, Jan 13, 2012 at 08:25:02PM +0000, Manuel Bouyer wrote:
  >  > No, this is not a bug, especially not, if this is run by root.
  >  
  >  It is a bug, the NetBSD kernel should not ask the hypervisor to
  >  map memory it's not allowed to map.

 In what way?

 The same as you can (carefully) use /dev/mem to access objects present
 in physical memory that the kernel doesn't know about, you should be
 able to use /dev/mem to access objects present in "physical" memory
 that the hypervisor puts there but that the kernel nonetheless doesn't
 know about. If you do it wrong, the hypervisor punts you off, same as
 real hardware would (except less messily).

 Unless I suppose there's some guarantee that no such things can or
 will ever appear, but that seems implausible.

 (Also, don't some of the domU devices have memory-mapped parts?
 Randomly touching such things can break the kernel just as readily as
 touching hardware registers. Or am I thinking of some other VMM?)

 -- 
 David A. Holland
 dholland@netbsd.org

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
        manu@NetBSD.org
Subject: Re: kern/45830: reading :dev/mem panics an i386 domU
Date: Mon, 16 Jan 2012 13:11:53 +0100

 On Sun, Jan 15, 2012 at 07:50:05AM +0000, David Holland wrote:
 >  In what way?
 >  
 >  The same as you can (carefully) use /dev/mem to access objects present
 >  in physical memory that the kernel doesn't know about, you should be
 >  able to use /dev/mem to access objects present in "physical" memory
 >  that the hypervisor puts there but that the kernel nonetheless doesn't
 >  know about. If you do it wrong, the hypervisor punts you off, same as

 Because of the way Xen works, if the kernel doesn't know about it
 it doesn't have enough data to ask the hypervisor to map it (this is
 the phys->machine address map). Xen has other ways to map objects the
 kernel doesn't know about (there are some specific hypercalls, and some
 specific files/devices in /kern and /dev for this).

 What's happening here is that we're accessing an object that the kernel
 thinks it knows, but the kernel is wrong. I've seen a similar panic
 in other circunstances (not associated with /dev/mem abitrary reads) and
 it may be the same root cause.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

Responsible-Changed-From-To: kern-bug-people->port-xen-maintainer
Responsible-Changed-By: bouyer@NetBSD.org
Responsible-Changed-When: Wed, 18 Jan 2012 20:56:28 +0000
Responsible-Changed-Why:
This is xen-specific


State-Changed-From-To: open->analyzed
State-Changed-By: bouyer@NetBSD.org
State-Changed-When: Wed, 18 Jan 2012 21:28:02 +0000
State-Changed-Why:
The problem is in mm_md_physacc(), which checks if the requested PA is in
memory range, and then relies on kauth_authorize_machdep(KAUTH_MACHDEP_UNMANAGEDMEM)
which always allows access for root.
I guess that, at last for Xen, there should be extra checks here.


>Unformatted:

Home	PR Database Search