Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src



> 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



Home | Main Index | Thread Index | Old Index