Subject: Re: CVS commit: src
To: None <elad@netbsd.org>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: source-changes
Date: 10/06/2005 00:40:58
> Module Name:	src
> Committed By:	elad
> Date:		Wed Oct  5 13:48:48 UTC 2005
> 
> Modified Files:
> 	src/sbin/veriexecctl: veriexecctl.8 veriexecctl.c veriexecctl_parse.y
> 	src/share/man/man4: veriexec.4
> 	src/sys/dev: verified_exec.c
> 	src/sys/kern: kern_verifiedexec.c
> 	src/sys/miscfs/genfs: genfs_vnops.c
> 	src/sys/sys: verified_exec.h
> 
> Log Message:
> Introduce per-page fingerprints in Veriexec.
> 
> This closes a hole pointed out by Thor Lancelot Simon on tech-kern ~3
> years ago.
> 
> The problem was with running binaries from remote storage, where our
> kernel (and Veriexec) has no control over any changes to files.
> 
> An attacker could, after the fingerprint has been verified and
> program loaded to memory, inject malicious code into the backing
> store on the remote storage, followed by a forced flush, causing
> a page-in of the malicious data from backing store, bypassing
> integrity checks.
> 
> Initial implementation by Brett Lymn.

- what are you trying to do in genfs_getpages?
  isn't it needed for async case?

- don't use static variables in this manner.  ("fp" and "ctx")

- who frees kva allocated in veriexec_page_verify?

- what kind of "remote storage" is expected?
  it seems that you are assuming that the size of file never be changed.
  is it ok?

- you are skipping checks on errors.  is it designed to be "best effort"?

YAMAMOTO Takashi