Subject: Re: kern/35278: veriexec sometimes feeds user va to log(9)
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: netbsd-bugs
Date: 12/20/2006 10:05:03
The following reply was made to PR kern/35278; it has been noted by GNATS.
From: yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
To: elad@NetBSD.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/35278: veriexec sometimes feeds user va to log(9)
Date: Wed, 20 Dec 2006 19:03:02 +0900 (JST)
> >> wouldn't that mean changes to either namei() api and/or struct nameidata
> >> abi?
>
> > yes.
>
> then I'd propose to add this to struct nameidata:
>
> char *ni_pathname;
>
> and this to NDINIT():
>
> (ndp)->ni_pathname = NULL;
>
> and namei() to store the pathname in 'ni_pathname' if it's not NULL. so
> callers that want the path can just:
>
> nd.ni_pathname = PNBUF_GET();
>
> and later free it. there's probably a better way to do this (without
> risking memory leaks) but I'm not familiar with namei() internals.
i'm not a fan of adding more functionalities to namei().
it's better to simplify namei() instead.
i'd suggest something like this.
sys_xxx()
{
pathname_t *pn;
error = pathname_get(user_pointer, &pn); /* allocate buffer and copyinstr */
NDINIT(.., pn, ..);
pathname_put(pn);
}
> for the meantime, I think we should use the patch I posted, at least for
> 4.0, until we decide how to handle this otherwise.
how about just disabling pathname logging?
YAMAMOTO Takashi