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