Abstract: By not only enabling a component-oriented, service-driven model of software development but also going a long way towards _enforcing_ this, OSGi opens up a new world of possibilities and a new marketplace for innovative products based on synergies with and between other software which is installed on the user's execution platform. However some fundamental issues remain unresolved. Because OSGi only offers application segregation based on class loaders, it cannot protect the execution platform from (deliberate or accidental) "denial of service" attacks in which one service consumes so much CPU time, heap space, or other resources such as OS threads that other services are unable to do their job. In this paper we look at the possibilities for monitoring resource sage on a per-bundle basis and at the issued this raises. Speaker Bio: Chris Gray has been working with embedded and real-time software for over 30 years, and with OSGi since the beginning of this century. He is also the principal maintainer of the Mika embedded VM. Christer Larsson CEO and Co-founder Makewave AB Chruster has been involved in the development of the OSGi technology since 1998, taking part in the design of Ericsson's e-box concept which influenced the first releases of the OSGi specification to a large degree. He is currently the CEO of Makewave and the VP EMEA of the OSGi Alliance. Christer is also deeply involved in the open source OSGi project Knopflerfish

1. Challenges of Resource Management
in an OSGi Environment
Chris Gray, /K/ Embedded Java Solutions
Christer Larsson, Makewave
20 September 2011
/K/ Embedded Java Solutions
OSGi Alliance Marketing © 2008-2010 . All1
Page
COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved
Rights Reserved
onsdag den 21 september 2011

2. The Problem
• OSGi is a fine dynamic modular system which
allows many independent modules to co-exist
within a single JVM
• Supports the business objective of offering
3rd-party services on top of supplier-
provided services
• BUT: there is a need to protect the platform
against badly-written / malicious bundles
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

3. Types of Misbehavior
Other OS Process
Bundle Bundle
Bundle
Other OS Process
Bundle Bundle Bundle
OSGi Framework
Other OS Process
JVM Process
Operating System
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

4. Types of Misbehavior
Excessive Memory
Allocation
Other OS Process
Bundle Bundle
Bundle
Other OS Process
Bundle Bundle Bundle
OSGi Framework
Other OS Process
JVM Process
Operating System
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

5. Types of Misbehavior
Excessive CPU usage, or Excessive Memory
using too many Threads Allocation
Other OS Process
Bundle
Bundle
Bundle
Other OS Process
Bundle Bundle Bundle
OSGi Framework
Other OS Process
JVM Process
Operating System
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

6. Types of Misbehavior
Other OS Process
Other OS Process
Other OS Process
JVM / OSGi Rebooting. Please Wait.....
Operating System
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

7. Potential solutions to the
problem
• Use Resource Management inside the VM
• Run multiple VM instances to isolate critical
OSGi applications from user application
• Careful and rigorous testing of all bundles
before the are installed
• These three items can of course be
combined
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

8. A Mika / Knopflerfish solution - resource
constrain the bundles
Add a Resource Manager that can account for Bundle Resources using built-in VM features
Other OS Process
Bundle Bundle
Bundle
Other OS Process
Bundle Bundle Bundle
Resource
Knopflerfish OSGi Framework Manager Other OS Process
Mika Max
Operating System
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

9. Identifying the culprit (1)
• The first step is to associate resource allocations with
modules.
• Various systems have been devised for this, but generally
they are not transparent
• Certain APIs must be called for its resource consumption to
be monitored.
• But there is no guarantee all code is written in this way
• And legacy code, or 3rd party libs are certainly not!
• Instead we propose to gather resource usage information
by instrumenting the Java runtime itself.
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

10. Identifying the culprit - (2)
• OSGi helps us by allocating a unique classloader to each
bundle. We define the “current bundle class loader” of a
thread T as follows:
• If T is the system startup thread then the current bundle
class loader of T's base frame is the system class loader.
• Otherwise the bundle class loader of T's base frame is
inherited from the thread frame which called T.start().
• The bundle class loader of any other frame is the class
loader of the method it is executing, or if this is the system
class loader then it is inherited from the parent frame.
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

11. Identifying the culprit - (3)
• For the purpose of this paper the bootstrap class
loader, extension class loader, and system class loader
are all lumped together as “system”. Note that this
includes resources consumed by the framework itself.
• The overhead is much less than for the “stack
inspection” required by the Java2 fine-grained security
model, because we only need to follow a few pointers
(frame→method→class→loader) and test for
equality. Could be further optimised using auxiliary
data structures.
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

12. Resource Accounting
• For each class loader we maintain a data structure with
counters for each monitored resource.
• Count up when resource is allocated
• Count down when released, BUT
• Resource is often released by another thread, e.g. Garbage
collector or finalizer thread. Therefore we need to remember
which class loader allocated which resource! Furthermore the
resource may outlive the classloader which allocated it, so we
use a “handle” instead of a direct pointer to the class loader.
• CPU usage is tricky, as depends on OS and on threading model.
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

13. Bundle Resource Accounting
For each monitored bundle resources are accounted
and associated with the bundle’s Class Loader
Class Loader
Other OS Process
Bundle Bundle
Bundle
Class Loader
Other OS Process
Bundle Bundle Bundle
Knopflerfish OSGi Framework Resource
Manager Other OS Process
Mika Max
Operating System
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

14. Bundle Resource Accounting
For each monitored bundle resources are accounted
and associated with the bundle’s Class Loader
Class Loader
Other OS Process
Bundle Bundle
Bundle
Class Loader
Other OS Process
Bundle Bundle Bundle
Knopflerfish OSGi Framework Resource
Manager Other OS Process
Mika Max
Operating System
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

15. Resource Accounting (2)
• Knopflerfish Pro has a Resource Manager
• For every bundle quota can be set on CPU,
memory and number of Threads used
• When a Bundle has exceeded his quota of
some resource the Resource Manager is
notified and can take action.
• But it is not always obvious what to do!
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

16. Dealing with Resource
Overconsumption (1)
• The default action when the bundle over-
consumes is as follows
• Overconsumption of Memory
• Throw an OutOfMemoryError
• Overconsumption of Threads or CPU
• Throw an InternalError
• Alternatively a user-defined callback can be
invoked at that point
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

17. Dealing with Resource
Overconsumption (2)
• The Resource Manager can supply information on over-
consuming bundles to a Management Agent.
• The Management Agent can also query the Resource
Manager for current bundle resources use and take
action before quota is reached
• The Management Agent can then decide to send an alarm
and / or stop the bundle.
• For a well-behaving bundle this is no problem
• But for a malicious, or badly written bundle that has gone
bananas there are new problems on the horizon...
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

18. Difficulties with Java
Threads
• Java threads are not OS processes, i.e.
• Java threads can not be destroyed, stopped or suspended.
Attempting to do that is unsafe and may lead to unpredictable
results. See javadoc for java.lang.Thread for more details.
• This means Activator start() and stop() methods that do not
return can not be stopped or killed like an OS process.
• If this happens in Knopflerfish we:
• invalidate the Bundle after a timeout period so that bundle no
longer is usable. All its services are unregistered and it can not
get new services.
• Set the threads prio to lowest possible.
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

19. Showtime!
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011

20. Thank you
Chris Gray - /K/ Embedded Java Solutions - www.k-embedded-java.com
Christer Larsson - Makewave - www.makewave.com
OSGi Community Event 2011 Darmstadt - Chris Gray / Christer Larsson
onsdag den 21 september 2011