OKL4 and timer service.

[Jean-Christophe DUBOIS]

Hi,

I am just wondering if somebody could give me some rational on the decision
not to include a generic timer service inside OKL4.

The fact is that OKL4 is capturing at least one set of timer from the platform
preventing any Cell to access this one (which is a good thing) and uses it  
for its own internal need.

Now if the platform has no more other timer to offer to the Cells, it does mean
that the Cells will never be able to grab any timer in order to do some type
of timeout functions. So simple function like sleep() and such would not be
possible.

Moreover, assuming you have one timer free for use, if you have multiple Cells
in need of such services you would have to actually implement something like a
virtual timer server to serve the need of your multiple Cells.

Meanwhile the OKL4 kernel has its own timer with which it does its own tick
stuff without any intention to share it.

So why is it a bad thing (or at least not considered) to offer one central an
easily accessible timer service in OKL4 lib using the OKL4 timer under the
cover? Why is it preferable to force the user to implement its own virtual
timer server to be used by its application (possibly composed of multiple
cells each running a program or an OS in need of a time interrupt source)

Thanks

JC



_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer

[Jean-Christophe DUBOIS]

No opinion either?

JC

On Friday 28 August 2009 00:52:51 Jean-Christophe Dubois wrote:

> Hi,
>
> I am just wondering if somebody could give me some rational on the decision
> not to include a generic timer service inside OKL4.
>
> The fact is that OKL4 is capturing at least one set of timer from the
> platform preventing any Cell to access this one (which is a good thing) and
> uses it for its own internal need.
>
> Now if the platform has no more other timer to offer to the Cells, it does
> mean that the Cells will never be able to grab any timer in order to do
> some type of timeout functions. So simple function like sleep() and such
> would not be possible.
>
> Moreover, assuming you have one timer free for use, if you have multiple
> Cells in need of such services you would have to actually implement
> something like a virtual timer server to serve the need of your multiple
> Cells.
>
> Meanwhile the OKL4 kernel has its own timer with which it does its own tick
> stuff without any intention to share it.
>
> So why is it a bad thing (or at least not considered) to offer one central
> an easily accessible timer service in OKL4 lib using the OKL4 timer under
> the cover? Why is it preferable to force the user to implement its own
> virtual timer server to be used by its application (possibly composed of
> multiple cells each running a program or an OS in need of a time interrupt
> source)
>
> Thanks
>
> JC
>
>
>
> _______________________________________________
> Developer mailing list
> [hidden email]
> https://lists.okl4.org/mailman/listinfo/developer

_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer

[Josh Matthews]

Hi JC,

There are a couple of reasons for OKL4 not externally exposing the timer it uses:

a) Minimality: a guiding principle of microkernel design. Why should the kernel provide a timer service when the same can be done at user level (this assumes that platforms tend to have multiple timer sources, which they generally do nowdays). Additionally, the functionality required by the kernel of the timer is quite minimal: just a repeating hardcoded timeout; for it to provide a useful external service the internal driver would need to be significantly extended beyond the needs of the kernel, also violating the minimality principle.

b) Security: if the kernel provides a time source, then you cannot virtualize time. This not only limits what you can do with virtualization, it makes it much easier to exploit covert timing channels, and makes it impossible to employ some standard approaches to reducing CTC bandwidth. (Note CTC are in general impossible to prevent, but steps can be taken to reduce their bandwidth.)

Of course, the user is free to extend the OKL4 provided functionality (easiest is to use the provided PlatControl system call, extensible via the SDK) if their design dictates compelling reasons to provide a timer source.

Kind regards,

Josh

On Thu, Aug 27, 2009 at 6:52 PM, Jean-Christophe Dubois <[hidden email]> wrote:

Hi,

I am just wondering if somebody could give me some rational on the decision
not to include a generic timer service inside OKL4.

The fact is that OKL4 is capturing at least one set of timer from the platform
preventing any Cell to access this one (which is a good thing) and uses it
for its own internal need.

Now if the platform has no more other timer to offer to the Cells, it does mean
that the Cells will never be able to grab any timer in order to do some type
of timeout functions. So simple function like sleep() and such would not be
possible.

Moreover, assuming you have one timer free for use, if you have multiple Cells
in need of such services you would have to actually implement something like a
virtual timer server to serve the need of your multiple Cells.

Meanwhile the OKL4 kernel has its own timer with which it does its own tick
stuff without any intention to share it.

So why is it a bad thing (or at least not considered) to offer one central an
easily accessible timer service in OKL4 lib using the OKL4 timer under the
cover? Why is it preferable to force the user to implement its own virtual
timer server to be used by its application (possibly composed of multiple
cells each running a program or an OS in need of a time interrupt source)

Thanks

JC



_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer

_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer

[Jean-Christophe DUBOIS]

Hi Josh,

Thanks for your answers. My comments below:

On Tuesday 08 September 2009 19:50:06 Josh Matthews wrote:

> Hi JC,
>
> There are a couple of reasons for OKL4 not externally exposing the timer it
> uses:
>
> a) Minimality: a guiding principle of microkernel design. Why should the
> kernel provide a timer service when the same can be done at user level
> (this assumes that platforms tend to have multiple timer sources, which
> they generally do nowdays). Additionally, the functionality required by the
> kernel of the timer is quite minimal: just a repeating hardcoded timeout;
> for it to provide a useful external service the internal driver would need
> to be significantly extended beyond the needs of the kernel, also violating
> the minimality principle.

OK, fair enough. Now OKL4 is capturing a full set of driver for a very minimal
use preventing all cells to use this resource. It is not given that the
platform has another set of timer available (even if this is generally the
case) and beside as  OKL4 is doing the thread scheduling it sounds like it
would be a good place to deal with sleeping threads and such.

> b) Security: if the kernel provides a time source, then you cannot
> virtualize time.

Not sure to see how this will be different from using another set of timer
resource. A timer service is not a time service ...

> This not only limits what you can do with virtualization,
> it makes it much easier to exploit covert timing channels, and makes it
> impossible to employ some standard approaches to reducing CTC bandwidth.

OK, maybe I am missing something but I am not sure to see how the fact that
OKL4 provides a timer service makes the CTC problem worst than if I manage
another timer myself in an additional Cell. Maybe you could point me to some
literature on the subject.

> (Note CTC are in general impossible to prevent, but steps can be taken to
> reduce their bandwidth.)
>
> Of course, the user is free to extend the OKL4 provided functionality
> (easiest is to use the provided PlatControl system call, extensible via the
> SDK) if their design dictates compelling reasons to provide a timer source.

OK, I'll have a look at this. Could you point me to some documentation on the
way to add platControl system call inside OKL4 (through the SDK)?

JC

>
> Kind regards,
>
> Josh
>
> On Thu, Aug 27, 2009 at 6:52 PM, Jean-Christophe Dubois
> <[hidden email]
>
> > wrote:
> >
> > Hi,
> >
> > I am just wondering if somebody could give me some rational on the
> > decision not to include a generic timer service inside OKL4.
> >
> > The fact is that OKL4 is capturing at least one set of timer from the
> > platform
> > preventing any Cell to access this one (which is a good thing) and uses
> > it for its own internal need.
> >
> > Now if the platform has no more other timer to offer to the Cells, it
> > does mean
> > that the Cells will never be able to grab any timer in order to do some
> > type
> > of timeout functions. So simple function like sleep() and such would not
> > be possible.
> >
> > Moreover, assuming you have one timer free for use, if you have multiple
> > Cells
> > in need of such services you would have to actually implement something
> > like a
> > virtual timer server to serve the need of your multiple Cells.
> >
> > Meanwhile the OKL4 kernel has its own timer with which it does its own
> > tick stuff without any intention to share it.
> >
> > So why is it a bad thing (or at least not considered) to offer one
> > central an
> > easily accessible timer service in OKL4 lib using the OKL4 timer under
> > the cover? Why is it preferable to force the user to implement its own
> > virtual timer server to be used by its application (possibly composed of
> > multiple cells each running a program or an OS in need of a time
> > interrupt source)
> >
> > Thanks
> >
> > JC
> >
> >
> >
> > _______________________________________________
> > Developer mailing list
> > [hidden email]
> > https://lists.okl4.org/mailman/listinfo/developer

_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer

[Gernot Heiser]

>> There are a couple of reasons for OKL4 not externally exposing the timer it
>> uses:
>>
>> a) Minimality: a guiding principle of microkernel design. Why should the
>> kernel provide a timer service when the same can be done at user level
>> (this assumes that platforms tend to have multiple timer sources, which
>> they generally do nowdays). Additionally, the functionality required by the
>> kernel of the timer is quite minimal: just a repeating hardcoded timeout;
>> for it to provide a useful external service the internal driver would need
>> to be significantly extended beyond the needs of the kernel, also violating
>> the minimality principle.

JD> OK, fair enough. Now OKL4 is capturing a full set of driver for a very minimal
JD> use preventing all cells to use this resource. It is not given that the
JD> platform has another set of timer available (even if this is generally the
JD> case) and beside as  OKL4 is doing the thread scheduling it sounds like it
JD> would be a good place to deal with sleeping threads and such.

A lot of things fall into the category of "it sounds like the kernel
would be a good place for this". That's the general design approach
for a monolithic kernel. The microkernel approach is: "if it doesn't
have to be in the kernel it shouldn't be in the kernel".

>> b) Security: if the kernel provides a time source, then you cannot
>> virtualize time.

JD> Not sure to see how this will be different from using another set of timer
JD> resource.

The difference is that if you put it into the kernel API, it is there
to use. As Josh explained, we don't stop you from adding this
functionality if you think it's useful in your system, but that
doesn't force it to be there in places where it would undermine security.

JD> A timer service is not a time service ...

Anything that gives you information of the passage of real time is a
time source.

>> This not only limits what you can do with virtualization,
>> it makes it much easier to exploit covert timing channels, and makes it
>> impossible to employ some standard approaches to reducing CTC bandwidth.

JD> OK, maybe I am missing something but I am not sure to see how the fact that
JD> OKL4 provides a timer service makes the CTC problem worst than if I manage
JD> another timer myself in an additional Cell. Maybe you could point me to some
JD> literature on the subject.

If you use your platform code to build an insecure system, that's your
choice. If our API makes the system insecure then that's no longer
your choice, and no workaround is possible for such insecurity-by-design.

Gernot

_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer

[Christophe Augier]

Hi Gernot,

I see, you're still talking about this principle of minimality in
microkernel in general and in okl4 in particular. I would like to take
the opportunity to ask you why did you introduce mutexes, capabilities
and finally cells in the "microkernel" as it goes against this
principle of minimality ; as such is okl4 still a microkernel? or is
it why you introduced the microvisor term.
As you may have understood it's more of a "conceptual" question than a
technical one (I understand capabilities and cells were introduced to
replace the priviledged root task and that mutexes were introduced for
performance reasons.)

- Christophe



On Wed, Sep 9, 2009 at 3:37 AM, Gernot Heiser<[hidden email]> wrote:

>
>>> There are a couple of reasons for OKL4 not externally exposing the timer it
>>> uses:
>>>
>>> a) Minimality: a guiding principle of microkernel design. Why should the
>>> kernel provide a timer service when the same can be done at user level
>>> (this assumes that platforms tend to have multiple timer sources, which
>>> they generally do nowdays). Additionally, the functionality required by the
>>> kernel of the timer is quite minimal: just a repeating hardcoded timeout;
>>> for it to provide a useful external service the internal driver would need
>>> to be significantly extended beyond the needs of the kernel, also violating
>>> the minimality principle.
>
> JD> OK, fair enough. Now OKL4 is capturing a full set of driver for a very minimal
> JD> use preventing all cells to use this resource. It is not given that the
> JD> platform has another set of timer available (even if this is generally the
> JD> case) and beside as  OKL4 is doing the thread scheduling it sounds like it
> JD> would be a good place to deal with sleeping threads and such.
>
> A lot of things fall into the category of "it sounds like the kernel
> would be a good place for this". That's the general design approach
> for a monolithic kernel. The microkernel approach is: "if it doesn't
> have to be in the kernel it shouldn't be in the kernel".
>
>>> b) Security: if the kernel provides a time source, then you cannot
>>> virtualize time.
>
> JD> Not sure to see how this will be different from using another set of timer
> JD> resource.
>
> The difference is that if you put it into the kernel API, it is there
> to use. As Josh explained, we don't stop you from adding this
> functionality if you think it's useful in your system, but that
> doesn't force it to be there in places where it would undermine security.
>
> JD> A timer service is not a time service ...
>
> Anything that gives you information of the passage of real time is a
> time source.
>
>>> This not only limits what you can do with virtualization,
>>> it makes it much easier to exploit covert timing channels, and makes it
>>> impossible to employ some standard approaches to reducing CTC bandwidth.
>
> JD> OK, maybe I am missing something but I am not sure to see how the fact that
> JD> OKL4 provides a timer service makes the CTC problem worst than if I manage
> JD> another timer myself in an additional Cell. Maybe you could point me to some
> JD> literature on the subject.
>
> If you use your platform code to build an insecure system, that's your
> choice. If our API makes the system insecure then that's no longer
> your choice, and no workaround is possible for such insecurity-by-design.
>
> Gernot
>
> _______________________________________________
> Developer mailing list
> [hidden email]
> https://lists.okl4.org/mailman/listinfo/developer
>

_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer

[Gernot Heiser]

>>>>> On Wed, 9 Sep 2009 10:13:34 +0200, Christophe Augier <[hidden email]> said:
CA> Hi Gernot,
CA> I see, you're still talking about this principle of minimality in
CA> microkernel in general and in okl4 in particular. I would like to take
CA> the opportunity to ask you why did you introduce mutexes, capabilities
CA> and finally cells in the "microkernel" as it goes against this
CA> principle of minimality ; as such is okl4 still a microkernel? or is
CA> it why you introduced the microvisor term.

Caps are minimal: they are object references and imply access
rights. Both are needed, and neither functionality is provided by any
other mechanism. And they are much more powerful than the mechanisms
that previously provided that functionality, as they provide
finer-grained access control, provide a clean model for privilege
delegation, and avoid the covert storage channel introduced by global
names.

Cells are in fact a higher-level construct, they don't exist in the
kernel. They are implemented by the (minimal) kernel mechanisms of
caps and clists.

Mutexes can, in principle, be implemented at user level, but with high
cost. The reason is that an efficient implementation needs to interact
with scheduling. (And I'm not sure whether prio inheritance could be
even implemented at user level, as long as the scheduler itself is in
the kernel.)

As long as we don't find a way to export scheduling completely to user
level (without significant performance degradation) this is probably
unavoidable.

Having said that, we do in fact at times compromise minimality in some
places, generally to enable a smooth transition to new
functionality. That's a legacy issue that is unavoidable with a system
used in real-world products. But we're doing our best to keep this at
a minimum, and remove redundant features as we can.

Gernot

_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer

[Christophe Augier]

> Having said that, we do in fact at times compromise minimality in some
> places, generally to enable a smooth transition to new
> functionality. That's a legacy issue that is unavoidable with a system
> used in real-world products. But we're doing our best to keep this at
> a minimum, and remove redundant features as we can.

Fair enough, these kinds of compromises are unavoidable when moving
from research to real-world.

- Christophe


>
> Gernot
>
> _______________________________________________
> Developer mailing list
> [hidden email]
> https://lists.okl4.org/mailman/listinfo/developer
>

_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer

[Josh Matthews]

Hi JC,

On Tue, Sep 8, 2009 at 5:13 PM, Jean-Christophe Dubois <[hidden email]> wrote:
<...>

> Of course, the user is free to extend the OKL4 provided functionality
> (easiest is to use the provided PlatControl system call, extensible via the
> SDK) if their design dictates compelling reasons to provide a timer source.

OK, I'll have a look at this. Could you point me to some documentation on the
way to add platControl system call inside OKL4 (through the SDK)?

Check out section 3.1.8 ("Platform Control") in the OKL4 SoC Developers Manual, available at:
http://wiki.ok-labs.com/downloads/release-3.0/soc-dev-manual-3.0.pdf

Cheers,
Josh

_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer