From owner-doc-jp-work@jp.FreeBSD.org Tue Sep 17 13:10:26 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g8H4AQl58386;
	Tue, 17 Sep 2002 13:10:26 +0900 (JST)
	(envelope-from owner-doc-jp-work@jp.FreeBSD.org)
Received: from mail4.nec.com (dns4.nec.com [131.241.15.4])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g8H4AO358381
	for <doc-jp-work@jp.FreeBSD.org>; Tue, 17 Sep 2002 13:10:24 +0900 (JST)
	(envelope-from hino@ccrl.sj.nec.com)
Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2])
	by mail4.nec.com (/) with ESMTP id g8H48wa06502;
	Mon, 16 Sep 2002 21:08:59 -0700 (PDT)
Received: from renoir.ccrl.sj.nec.com (localhost [127.0.0.1])
	by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id VAA17993;
	Mon, 16 Sep 2002 21:08:53 -0700 (PDT)
Received: from localhost (alfa.ccrl.sj.nec.com [131.241.79.205])
	by renoir.ccrl.sj.nec.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20051;
	Mon, 16 Sep 2002 21:08:50 -0700 (PDT)
Message-Id: <20020916.210853.99257044.hino@ccrl.sj.nec.com>
To: doc-jp-work@jp.FreeBSD.org, hrs@eos.ocn.ne.jp
From: Koji Hino <hino@ccrl.sj.nec.com>
In-Reply-To: <20020917.122430.78729875.hrs@eos.ocn.ne.jp>
References: <200209161615.g8GGFk0g073000@freefall.freebsd.org>
	<20020917.122430.78729875.hrs@eos.ocn.ne.jp>
Organization: C&C Research Laboratories (CCRL), NEC USA, Inc.
X-Mailer: Mew version 2.2 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Reply-To: doc-jp-work@jp.FreeBSD.org
Precedence: list
Date: Mon, 16 Sep 2002 21:08:53 -0700
X-Sequence: doc-jp-work 491
Subject: [doc-jp-work 491] Re: ANNOUNCE: FreeBSD Security Advisory
 FreeBSD-SA-02:39.libkvm
Errors-To: owner-doc-jp-work@jp.FreeBSD.org
Sender: owner-doc-jp-work@jp.FreeBSD.org
X-Originator: hino@ccrl.sj.nec.com
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+020902

$B$46lO+MM$G$9!D(B

From: Hiroki Sato <hrs@eos.ocn.ne.jp>
 Date: Tue, 17 Sep 2002 12:24:30 +0900

:> I.   $BGX7J(B - Background
:> 
:> The kvm(3) library provides a uniform interface for accessing kernel
:> virtual memory images, including live systems and crash dumps.  Access
:> to live systems is via /dev/mem and /dev/kmem.  Memory can be read and
:> written, kernel symbol addresses can be looked up efficiently, and
:> information about user processes can be gathered.
:> 
:> kvm(3) $B%i%$%V%i%j$O!"2TF/Cf$N%7%9%F%`$d%/%i%C%7%e%@%s%W$K4^$^$l$k(B
:> $B%+!<%M%k$N2>A[%a%b%j%$%a!<%8$X%"%/%;%9$9$k$?$a$N!"E}0l$5$l$?(B

$B$A$g$C$H>iD9$K$J$j$^$9$,!"(B

kvm(3) $B%i%$%V%i%j$O!"2TF/Cf$N%7%9%F%`$N%+!<%M%k2>A[%a%b%j%$%a!<%8$d!"(B
$B%/%i%C%7%e%@%s%W$K4^$^$l$k%+!<%M%k2>A[%a%b%j%$%a!<%8$r%"%/%;%9$9$k$?$a(B
$B$N!"(B

$B$H$7$?$[$&$,$o$+$j$d$9$$$+$J$!!"$H;W$$$^$9!#(B

:> The kvm_openfiles(3) function opens the special device files /dev/mem
:> and /dev/kmem, and returns an opaque handle that must be passed
:> to the other library functions.
:> 
:> kvm_openfiles(3) $B4X?t$O(B /dev/mem $B$*$h$S(B /dev/kmem $B$H$$$&FC<l$J(B
:> $B%G%P%$%9%U%!%$%k$r%*!<%W%s$7!"B>$N(B kvm(3) $B4XO"$N%i%$%V%i%j4X?t$G(B
:> $B;H$&$?$a$NFH<+7A<0$N%O%s%I%k$rJV$7$^$9!#(B

$B!D%*!<%W%s$7!"B>$N(B kvm(3) $B4XO"$N%i%$%V%i%j4X?t72$,$"$H$+$i$=$l$r;2>H$G(B
$B$-$k$h$&$K!"%*!<%W%s$7$?%U%!%$%k5-=R;R$r(B ($BLuCm(B: kvm(3) $B%i%$%V%i%j72$N(B
$BFbIt$+$i$7$+Cf?H$,$o$+$i$J$$$h$&$K(B) $B>\:Y$,1#JC$5$l$?!V%O%s%I%k!W$H$7$F(B
$BJV$7$^$9!#(B

$B!t(B $B0ULu$7$9$.$+$J!)(B

:> 
:> 
:> II.  $BLdBj$N>\:Y(B - Problem Description
:> 
:> Applications that wish to present system information such as swap
:> utilization, virtual memory utilization, CPU utilization, and
:> so on may use the kvm(3) library to read kernel memory directly
:> and gather this information.  Such applications typically must
:> be run set-group-ID kmem so that the call to kvm_openfiles(3)
:> can access /dev/mem and /dev/kmem.
:> 
:> $B%9%o%C%W$d2>A[%a%b%j!"(BCPU $B$NMxMQ>u67$J$I$N%7%9%F%`>pJs$rI=<($9$k(B
:> $B%"%W%j%1!<%7%g%s$O!">pJs$rF@$k$?$a$KD>@\%+!<%M%k%a%b%j$r;2>H$7$^$9!#(B
                                       ^ kvm(3) $B%i%$%V%i%j$rMxMQ$7$F(B
$B!D;2>H$9$k$b$N$,$"$j$^$9!#(B

:> $B$=$N$h$&$J%"%W%j%1!<%7%g%s$O(B kvm_openfiles(3) $B$r8F$S=P$7$F(B
:> /dev/mem $B$*$h$S(B /dev/kmem $B$K%"%/%;%9$G$-$k$h$&$K!"DL>o$O(B
:> kmem $B%0%k!<%W$G(B set-group-ID $B$7$F<B9T$5$l$F$$$kI,MW$,$"$j$^$9!#(B
                ~~$B$K(B
$B!t(B $B;d$N8l46$G$O!V$K!W$J$s$G$9$,!"<B9T$J$N$G!J(Bstatic$B$J@_Dj$H$7$F$G$O$J(B
$B!t(B $B$$$N$G(B) $B!V$G!W$,@5$7$$$N$+$J!D(B

:> If the application then uses exec(2) to start another application,
:> the new application will continue to have open file descriptors to
:> /dev/mem and /dev/kmem.  This is usually avoided by marking file
:> descriptors as close-on-exec, but since the handle returned by
:> kvm_openfiles(3) is opaque, there is no direct way for the application
:> to determine what file descriptors have been opened by the library.
:> As a result, application writers may neglect to take these file
:> descriptors into account.
:> 
:> $B$=$N$h$&$J%"%W%j%1!<%7%g%s$,<B9TCf$K(B exec(2) $B$r;H$C$FB>$N(B
:> $B%"%W%j%1!<%7%g%s$r8F$S=P$9$H!"?7$7$/5/F0$7$?%"%W%j%1!<%7%g%s$K$O(B
:> /dev/mem $B$*$h$S(B /dev/kmem $B$KBP1~$9$k%U%!%$%k5-=R;R$,%*!<%W%s$5$l$?$^$^(B
:> $B0z$-7Q$,$l$^$9!#DL>o$O%U%!%$%k5-=R;R$r(B ($BLuCm(B: fcntl(2) $B$r;H$C$F(B)
:> close-on-exec $B$K;XDj$9$k$3$H$G$3$&$$$C$?>u67$r2sHr$9$k$N$G$9$,!"(B
:> kvm_openfiles(3) $B$NJV$9%O%s%I%k$O(B ($BLuCm(B: $B%U%!%$%k5-=R;R$=$N$b$N(B
:> $B$G$O$J$$(B)  $BFH<+7A<0$G$"$j!"%"%W%j%1!<%7%g%sB&$+$i$O(B kvm(3) $B%i%$%V%i%j$,(B
   ~~~~~~~~
   $B$rCj=P$9$kJ}K!$,5,Dj$5$l$F$$$J$$(B

$B$"$?$j$G$7$g$&$+!D(B


:> $B%*!<%W%s$7$?%U%!%$%k5-=R;R$,!"6qBNE*$K$I$l$J$N$+$rD>@\D4$Y$k<jCJ$,(B
:> $B$"$j$^$;$s!#$=$N$?$a%"%W%j%1!<%7%g%s:n@.<T$O!"$3$l$i$N%U%!%$%k5-=R;R$N(B
:> $B=hM}$rBU$C$F$7$^$&2DG=@-$,$"$j$^$9!#(B


$BF|Ln(B
