| VERIEXEC(9) | Kernel Developer's Manual | VERIEXEC(9) | 
veriexec —
#include <sys/verified_exec.h>
void
  
  veriexec_init(void);
bool
  
  veriexec_lookup(struct
    vnode *vp);
int
  
  veriexec_verify(struct
    lwp *l, struct vnode
    *vp, const u_char
    *name, int flag,
    bool *found);
void
  
  veriexec_purge(struct
    vnode *vp);
int
  
  veriexec_fpops_add(const
    char *fp_type, size_t
    hash_len, size_t
    ctx_size,
    veriexec_fpop_init_t
    init,
    veriexec_fpop_update_t
    update,
    veriexec_fpop_final_t
    final);
int
  
  veriexec_file_add(struct
    lwp *l, prop_dictionary_t
    dict);
int
  
  veriexec_file_delete(struct
    lwp *l, struct vnode
    *vp);
int
  
  veriexec_table_delete(struct
    lwp *l, struct mount
    *mp);
int
  
  veriexec_flush(struct
    lwp *l);
int
  
  veriexec_openchk(struct
    lwp *l, struct vnode
    *vp, const char
    *path, int
  fmode);
int
  
  veriexec_renamechk(struct
    lwp *l, struct vnode
    *fromvp, const char
    *fromname, struct vnode
    *tovp, const char
    *toname);
int
  
  veriexec_removechk(struct
    lwp *l, struct vnode
    *vp, const char
    *name);
int
  
  veriexec_unmountchk(struct
    mount *mp);
int
  
  veriexec_convert(struct
    vnode *vp,
    prop_dictionary_t
  rdict);
int
  
  veriexec_dump(struct
    lwp *l, prop_array_t
    rarray);
veriexec is the KPI for Veriexec, the
  NetBSD in-kernel file integrity subsystem. It is
  responsible for managing the supported hashing algorithms, fingerprint
  calculation and comparison, file monitoring tables, and relevant hooks to
  enforce the Veriexec policy.
veriexec_init(void)veriexec_lookup(vp)true if it is,
      or false otherwise.veriexec_verify(l,
    vp, name,
    flag, found)VERIEXEC_DIRECTVERIEXEC_INDIRECTVERIEXEC_FILEl is the LWP for the request context.
An optional argument, found, is a pointer to a boolean indicating whether an entry for the file was found in the Veriexec tables.
veriexec_purge(vp)veriexec_fpops_add(fp_type,
    hash_len, ctx_size,
    init, update,
    final)veriexec_file_add(l,
    dict)dict is expected to have the following:
| Name | Type | Purpose | 
| file | string | filename | 
| entry-type | uint8 | entry type flags (see veriexec(4)) | 
| fp-type | string | fingerprint hashing algorithm | 
| fp | data | the fingerprint | 
veriexec_file_delete(l,
    vp)veriexec_table_delete(l,
    mp)veriexec_flush(l)veriexec_openchk(l,
    vp, path,
    fmode)l is the LWP opening the file,
        vp is a vnode for the file being opened as
        returned from namei(9). If
        NULL, the file is being created.
        path is the pathname for the file (not necessarily
        a full path), and fmode are the mode bits with
        which the file was opened.
veriexec_renamechk(l,
    fromvp, fromname,
    tovp, toname)fromvp and fromname are the vnode and filename of the file being renamed. tovp and toname are the vnode and filename of the target file. l is the LWP renaming the file.
Depending on the strict level,
        veriexec will either track changes appropriately
        or prevent the rename.
veriexec_removechk(l,
    vp, name)vp is the vnode of the file being removed, and name is the filename. l is the LWP removing the file,
Depending on the strict level,
        veriexec will either clean-up after the file or
        prevent its removal.
veriexec_unmountchk(mp)veriexec_convert(vp,
    rdict)| Name | Type | Purpose | 
| entry-type | uint8 | entry type flags (see veriexec(4)) | 
| status | uint8 | entry status (see below) | 
| fp-type | string | fingerprint hashing algorithm | 
| fp | data | the fingerprint | 
The “status” can be one of the following:
| Status | Meaning | 
| FINGERPRINT_NOTEVAL | not evaluated | 
| FINGERPRINT_VALID | fingerprint match | 
| FINGERPRINT_MISMATCH | fingerprint mismatch | 
If no entry was found, ENOENT is
        returned. Otherwise, zero.
veriexec_dump(l,
    rarray)Each element in rarray is a dictionary
        with the same elements as filled by
        veriexec_convert(), with an additional field,
        “file”, containing the filename.
| Path | Purpose | 
| src/sys/dev/veriexec.c | driver for userland communication | 
| src/sys/sys/verified_exec.h | shared (userland/kernel) header file | 
| src/sys/kern/kern_veriexec.c | subsystem code | 
| src/sys/kern/vfs_syscalls.c | rename, remove, and unmount policies | 
| src/sys/kern/vfs_vnops.c | regular file access policy | 
veriexec, there is no way to track on-disk changes.
  While it is possible to minimize the effect by evaluating the file's
  fingerprint on each access without caching the result, a problem arises when a
  file is overwritten after its fingerprint has been evaluated and it is running
  on the local host.
An attacker could potentially overwrite the file contents in the remote host at that point, and force a flush on the local host, resulting in paging in of the files from the disk, introducing malicious code into a supposedly safe address space.
There is a fix for this issue, however due to dependencies on other work that is still in progress it has not been committed yet.
veriexec cannot track the same
  on-disk file across multiple layers of overlay file-systems. Therefore, you
  cannot expect changes to files on overlay mounts will be detected simply
  because the underlying mount is monitored by veriexec.
A workaround for this issue is listing all files, under all mounts, you want monitored in the signature file.
| December 9, 2015 | NetBSD 9.3 |