> > how about:
> > 
> > kauth_authorize_device(cred, KAUTH_DEVICE_RAWIO_DISK, dev, vp);
> > 
> > kauth_authorize_device(cred, KAUTH_DEVICE_RAWIO_MEMORY, dev, vp);
> > 
> > kauth_authorize_device(cred, KAUTH_DEVICE_RAWIO_PASSTHRU, dev, some_data);
> 
> my concern is that we're losing the access (r/w/rw) with that, which is
> important for policy decisions.
> 
> > or, unify KAUTH_DEVICE_RAWIO_DISK and KAUTH_DEVICE_RAWIO_MEMORY and
> > export an iskmemdev() equivalent so that listeners can check if
> > it's a kmem access or not by themselves.
> 
> that's actually something I've been wanting to do. I like it.
> 
> > i'm not sure why RAWIO_DISK needs both of dev and vp.
> > isn't it simpler just to have listers use vfinddev or vp->v_rdev if necessary?
> 
> can we guarantee that we will have, in most cases, either dev or vp for
> the disk device? if yes, choosing one of them should be enough. ideally
> the vp would be best, imho, but either works (as you say, vfinddev() can
> be used).

then, how about:

kauth_authorize_device(cred, KAUTH_DEVICE_RAWIO, r/w/passthru, vp, some_data);

i wonder what's the status of devvp branch.

> > btw, your last changes to spec_open seems incomplete.
> > 	- it does vfinddev but don't use the result (bvp) unless NVERIEXEC > 1.
> 
> is attached diff okay?

i thought KAUTH_REQ_SYSTEM_RAWIO_DISK excepts vp, not bvp.
i'm not sure the veriexec part.

YAMAMOTO Takashi