headers
Juan RP | 1 Oct 2006 08:07

Re: Status report: sysmon_cpufreq(9) + powerctl(8)

On Fri, 29 Sep 2006 20:53:38 +0100 (BST)
Iain Hibbert <plunky <at> rya-online.net> wrote:

> On Fri, 29 Sep 2006, Juan RP wrote:
> 
> > Patch updated... I think I fixed all the things you said, please
> > correct me if I'm missing something.
> 
> When you create an object, you must release it when you dont want
> it.. In sysmon_cpufreq_recv_data() there are some memory leaks. If
> you add it to a dictionary (or array), the dictionary retains it but
> you must also release it in any case.

Ok... I still don't understand what functions retain the objects but I
fixed most of them.

> the sdict you return from sysmon_cpufreq_return_smcfdict() does also
> not get released - maybe you dont really need to copy it? In fact,
> I'm not sure why this function exists, you look for a key matching
> drvn then do a prop_dictionary_get(dict, drvn) and return that object.

Indeed! I removed the function and I search for the key in device_t
properties dictionary.

> in powerctl.c I dont think you need to make a copy of the dictionary
> - it only exists in your process space, nobody else will touch it.
> Also, you are releasing objects that you did not retain and not
> releasing objects you created.

True... I removed prop_dictionary_copy and now I use the object as
(Continue reading)

Permalink | Reply | 12 comments |
headers
Juan RP | 1 Oct 2006 08:53

Re: Status report: sysmon_cpufreq(9) + powerctl(8)

On Sun, 1 Oct 2006 08:07:14 +0200
Juan RP <juan <at> xtrarom.org> wrote:

> Code updated... anyway I can't test because the uvm_mmap call in
> prop_dictionary_copyout_ioctl() from prop_kern.c returns ENOMEM.
> 
> drvctl -p cpu0 works...
> 
> Any idea?

Interesting... if I use prop_dictionary_sendrecv_ioctl in powerctl.c it
works but not with prop_dictionary_recv_ioctl that always returns
ENOMEM. 

> http://www.netbsd.org/~xtraeme/cpufreq.diff
> http://www.netbsd.org/~xtraeme/powerctl.c
Permalink | Reply | 9 comments |
headers
Iain Hibbert | 1 Oct 2006 10:52

Re: Status report: sysmon_cpufreq(9) + powerctl(8)

On Sun, 1 Oct 2006, Juan RP wrote:

> On Sun, 1 Oct 2006 08:07:14 +0200
> Juan RP <juan <at> xtrarom.org> wrote:
>
> > Code updated... anyway I can't test because the uvm_mmap call in
> > prop_dictionary_copyout_ioctl() from prop_kern.c returns ENOMEM.
> >
> > drvctl -p cpu0 works...
> >
> > Any idea?
>
> Interesting... if I use prop_dictionary_sendrecv_ioctl in powerctl.c it
> works but not with prop_dictionary_recv_ioctl that always returns
> ENOMEM.

I think when you use _IOWR then you also must use _sendrecv_ (will look
properly in a bit, but I think both ioctls you have are IOWR?)

iain
Permalink | Reply | 8 comments |
headers
Juan RP | 1 Oct 2006 11:03

Re: Status report: sysmon_cpufreq(9) + powerctl(8)

On Sun, 1 Oct 2006 09:52:42 +0100 (BST)
Iain Hibbert <plunky <at> rya-online.net> wrote:

> I think when you use _IOWR then you also must use _sendrecv_ (will
> look properly in a bit, but I think both ioctls you have are IOWR?)

This is what I suspected when I changed it to _sendrecv_.

Yes, I'm using IOWR in the two ioctls. I think I had IOW for
SMCPUFREQ_GDICT in the past.

But I remember someone told me that I have always to use IOWR 
for proplib...
Permalink | Reply | 3 comments |
headers
Pavel Cahyna | 1 Oct 2006 11:16
Picon

Re: Tackling more kauth(9) stuff

On Wed, Sep 20, 2006 at 02:43:12PM +0200, Elad Efrat wrote:
>   1. Adding a KAUTH_NETWORK_INTERFACE action to the network scope, with
>      a set of "generic" sub-actions as follows:
> 
>        - KAUTH_REQ_NETWORK_INTERFACE_SET
>        - KAUTH_REQ_NETWORK_INTERFACE_GET
>        - KAUTH_REQ_NETWORK_INTERFACE_SETPRIV
>        - KAUTH_REQ_NETWORK_INTERFACE_GETPRIV
> 
>      Where the first two are requests to set/get non-privileged data
>      that (usually) all users can do, and the last two are those that
>      (again, usually) are restricted to the super-user.

Could you please give some examples?

Pavel
Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 1 Oct 2006 11:30
Picon

Re: veriexec (Re: CVS commit: src)

> YAMAMOTO Takashi wrote:
> 
> > are there examples?
> 
> You execute an interpreter and feed code into it manually hence
> bypassing a TPE check. You
> 
> -e.
> 
> -- 
> Elad Efrat

do you mean, if the interpreter is under a trusted path?
isn't it the same for veriexec?

YAMAMOTO Takashi
Permalink | Reply | 3 comments |
headers
Elad Efrat | 1 Oct 2006 12:40
Picon

Re: veriexec (Re: CVS commit: src)

YAMAMOTO Takashi wrote:

> do you mean, if the interpreter is under a trusted path?
> isn't it the same for veriexec?

The interpreter is probably under a trusted path. But once executed, the
input it gets (from stdin, for example) is untrusted -- because it's
typed in by a user -- but is under a trusted path because it's
/dev/stdin.

(a solution from the far past used the immutable flag to distinguish
interpreters, then marking them with a process flag meaning "can't read
from stdin", and checking that flag where needed. I believe our way is
much cleaner. :)

-e.

--

-- 
Elad Efrat
Permalink | Reply | 2 comments |
headers
YAMAMOTO Takashi | 1 Oct 2006 12:53
Picon

Re: veriexec (Re: CVS commit: src)

> > do you mean, if the interpreter is under a trusted path?
> > isn't it the same for veriexec?
> 
> The interpreter is probably under a trusted path. But once executed, the
> input it gets (from stdin, for example) is untrusted -- because it's
> typed in by a user -- but is under a trusted path because it's
> /dev/stdin.
> 
> (a solution from the far past used the immutable flag to distinguish
> interpreters, then marking them with a process flag meaning "can't read
> from stdin", and checking that flag where needed. I believe our way is
> much cleaner. :)

how does "our way" solve it?
is it related to the "direct"/"indirect" distinction?  (it was my original
question.)

YAMAMOTO Takashi
Permalink | Reply | 1 comment |
headers
Elad Efrat | 1 Oct 2006 13:56
Picon

Re: veriexec (Re: CVS commit: src)

YAMAMOTO Takashi wrote:

> how does "our way" solve it?
> is it related to the "direct"/"indirect" distinction?  (it was my original
> question.)

Yeah -- we mark entries for interpreters as "indirect", so they can only
be executed as interpreters for scripts and not invoked directly by the
user.

-e.

--

-- 
Elad Efrat
Permalink | Reply | 0 comments |
headers
Brett Lymn | 1 Oct 2006 12:58
Picon

Re: veriexec (Re: CVS commit: src)

On Sat, Sep 30, 2006 at 09:20:42PM +0900, YAMAMOTO Takashi wrote:
> 
> my questions was, why do you want to distinguish them?
> 

The original intention of indirect vs direct (and, this has not
changed) was that the indirect flag could be applied to a shell
interpreter.  If an executable is marked indirect then it cannot be
invoked directly from a shell but it may be used as a shell
interpreter for a script.  The thinking behind this is that you could,
for example, install perl on the machine and allow veriexec verified
perl scripts to run (since they have #!/usr/pkg/bin/perl as their
first line) _but_ deny someone running perl from the command line and
feeding their own perl script into it.  Hence, you could have a
powerful shell interpreter available for scripting but deny people the
ability to abuse the interpreter for unchecked code.

--

-- 
Brett Lymn
Permalink | Reply | 0 comments |

Gmane