Accessing sysctls from kernel

[Robert Watson]

On Thu, 26 Feb 2004, Bruce M Simpson wrote:

> On Thu, Feb 26, 2004 at 02:10:40PM +0100, Ivan Voras wrote:
> > In sys/sys/sysctl.h I see function kernel_sysctlbyname() that looks (to 
> > me) to be intended for accessing sysctl values from kernel, but for it's 
> > first parameter it requires a struct thread *td.
> > 
> > What should I pass to it? (I'm calling it from inside a screensaver module)
> 
> You could try lying about which thread you are, when you aren't in a
> userland thread: 
> 
> Cscope tag: kernel_sysctlbyname
>    #   line  filename / context / line
>    1    728  /sys/dev/vinum/vinumio.c <<vinum_scandisk>>
>              error = kernel_sysctlbyname(&thread0, "kern.disks", NULL,
>    2    741  /sys/dev/vinum/vinumio.c <<vinum_scandisk>>
>              kernel_sysctlbyname(&thread0, "kern.disks", devicename,
>    3    305  /sys/i386/i386/elan-mmcr.c <<init_AMD_Elan_sc520>>
>              i = kernel_sysctlbyname(&thread0, "machdep.i8254_freq",

FWIW, the thread exists in the context of a sysctl for several reasons --
one is to provide access to the requesting process's address space,
another is the credential authorizing the change.  While there are calls
kernel_sysctl() and kernel_sysctlbyname(), those are generally intended
for consumption "on behalf" of a user process.  My general preference
would be to offer an in-kernel API to manage whatever service is being
accessed if it's being done in the kernel "on behalf" of the kernel,
rather than trying to force the access through the current sysctl MIB.
That way you don't find unnecessary references to thread0, etc, which have
some dubious locking properties, as well as abuse of credentials, etc,
that may have unexpected side effects with less traditional security
models. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research