Upload
christophevg
View
61
Download
1
Tags:
Embed Size (px)
Citation preview
NES - Status Update June 2015 What have I silently been up to?
reactive-c roseFCF
reactive-c
detailed story on http://github.com/christophevg/reactive-c
see also PL@NES
reactive-c
detailed story on http://github.com/christophevg/reactive-c
see also PL@NES
reactive-c
glitch-free
pure Cinner DSL
integration of primitivesscriptingfunction liftingmap, filter, fold
detailed story on http://github.com/christophevg/reactive-c
see also PL@NES
reactive-c
detailed story on http://github.com/christophevg/reactive-c
a = b + c
see also PL@NES
reactive-c
dependency graph APIsupport for interrupts
more functions
“What is the overhead ?”vs manual observer pattern implementation
detailed story on http://github.com/christophevg/reactive-c
reactive-c
Relative Throughput
25%
50%
75%
100%
observer.c reactive-cchain fan
chain fan
…source observer source observers…
Intel 2,4 GHz Intel Core 2 Duo 2530Mhz operating frequency
level-based priority queuedynamic functionalityclean implementation
“What is the overhead ?”
9% 2%
detailed story on http://github.com/christophevg/reactive-c
rose
+ OTAP
reactive-c
+ VM-ish
detailed story on http://github.com/christophevg/rose
rose
implement OTAPport to embedded platform
“What is the overhead ?”
create VM management tool
finalize VM
vs manual observer pattern implementation and classic full-flash
detailed story on http://github.com/christophevg/rose
FCF
Verlagen van de impact van inbraakdetectiein draadloze sensornetwerken door middelvan een domeinspecifieke taal encodegeneratietechnieken
Christophe Van Ginneken
Thesis voorgedragen tot het behalenvan de graad van Master of Sciencein de ingenieurswetenschappen:computerwetenschappen,hoofdspecialisatie Gedistribueerdesystemen
P
r
o
m
o
t
o
r
e
n
:Prof. dr. ir. Wouter JoosenProf. dr. ir. Christophe HuygensA
s
s
e
s
s
o
r
e
n
:Dr. Benjamin NegrevergneDr. Nelson MatthysB
e
g
e
l
e
i
d
e
r
:
Drs. ir. Jef Maerien
Academiejaar 2013 – 2014
master thesisid-foo (foo-lang)event-drivenreact
ive
optimising executionfunctional level
JTAG
RS-232XBee ZigBee module
ATMEGA 1284p
light sensor
power, reset, indicators
FCF
FCF
manualbase heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%# frames 20 51 255% 32 160% 63 315%bytes 476 1933 406% 860 181% 2317 487%event loop (microseconds) 48 94 196% 88 183% 149 310%
generatedbase heartbeat reputation both
size (bytes) 10496 18352 175% 16376 156% 20998 200%# frames 20 49 245% 32 160% 55 275%bytes 476 1897 399% 884 186% 2161 454%event loop (microseconds) 48 121 252% 121 252% 138 288%
heartbe
at
reputation
FCF
manualbase heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%# frames 20 51 255% 32 160% 63 315%bytes 476 1933 406% 860 181% 2317 487%event loop (microseconds) 48 94 196% 88 183% 149 310%
generatedbase heartbeat reputation both
size (bytes) 10496 18352 175% 16376 156% 20998 200%# frames 20 49 245% 32 160% 55 275%bytes 476 1897 399% 884 186% 2161 454%event loop (microseconds) 48 121 252% 121 252% 138 288%
heartbe
at
reputation
FCF
manualbase heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%# frames 20 51 255% 32 160% 63 315%bytes 476 1933 406% 860 181% 2317 487%event loop (microseconds) 48 94 196% 88 183% 149 310%
generatedbase heartbeat reputation both
size (bytes) 10496 18352 175% 16376 156% 20998 200%# frames 20 49 245% 32 160% 55 275%bytes 476 1897 399% 884 186% 2161 454%event loop (microseconds) 48 121 252% 121 252% 138 288%
heartbe
at
reputation
FCF
1) loop jamming
2) message aggregation
3) centralised common functionality (scheduling, nodes,…)
FCF loop jamming
FCF message aggregation
heartbeat
reputation
Goal: reduce wireless radio usage
FCF message aggregation
heartbeat
reputation
Goal: reduce wireless radio usagethrough piggy bagging.
FCF centralised common functionality
one node and nodes scope
one implementation
one scheduler
one parser
FCF
foo-lang
scheduling
one parser
one node
nodes scope
1 implementation
FCF
id-foo: A framework for
Efficient Intrusion Detection
in the Internet of Things
Christophe Van Ginneken, Jef Maerien, Christophe Huygens, Wouter Joosen, Danny Hughes
iMinds-DistriNet, KU Leuven
3001 Leuven, Belgium
{firstname.lastname}@cs.kuleuven.be
Abstract—When intrusion prevention fails, intrusion detection
serves as a second layer of defense. It looks for patterns
and anomalies that can indicate malicious behavior. However,
supporting an adequate set of intrusion detection algorithms
imposes significant overhead on resource-constrained devices
such as those in the Internet of Things. Manual fusion of the
algorithms reduces resource consumption by optimizing resource
sharing, yet, proves to be time-consuming, repetitive and error-
prone. To address this problem we propose id-foo, a framework
for the development of efficient intrusion detection systems. It
consists of a domain specific language and a code generator.
The language allows formally describing the intent of intrusion
detection algorithms and supports the generator in organizing
the source code. A side-by-side comparison shows that id-foo-
generated code reduces message passing overhead, execution time
and memory footprint in comparison to sequential calls into
individual implementations of the algorithms.
I. INTRODUCTION
In wired networks, firewalls focus on the outer perimeter
of the network, filtering unwanted packets and protecting the
entire internal network. Still, attacks on flaws in services can
pass unnoticed. This is where intrusion detection (ID) comes
into play: an intrusion detection system (IDS) monitors all
traffic that passes through the firewall, looking for patterns of
malicious activity, and optionally, after detecting such pattern,
alerts the firewall, allowing it to take corrective actions [?].
The internet of things (IoT) holds great potential to po-
sitively influence our daily work and life through domotics,
assisted living, e-health, enhanced learning, etc. [?]. With
this potential the IoT also presents a significant threat: by
opening our smart homes and personal data to all of these
interconnected devices, we also open them to everyone who is
able to break the virtual locks that protect them (i.e. passwords
& encryption keys). Implementation of security measures by
itself is hindered by the fact that IoT devices typically have
limited batteries, processing power and memory.
In wireless networks of resource-constrained devices, which
make up a significant part of the IoT, it is not possible for a
single point in the network to oversee all traffic [?]. Every
device has to implement its own lines of defense. However
making the IDS a local service on each device requires local
resources, which are a scarce commodity for IoT devices.
Attackers have access to a large set of possible attack
vectors [?], ranging from the physical layer, through the access
and routing layers, up to the application layer. Each layer
presents different opportunities to manipulate data, eavesdrop
or perform a form of denial of service. For each of these
attacks an algorithm needs to look for patterns or anomalies.
An IDS for IoT devices therefore requires a large number of
algorithms to achieve adequate coverage.
Current developments in ID on resource-constrained devices
focus on programming frameworks that structure the imple-
mentation of algorithms [?] and offer the required basic func-
tional components to implement them [?]. A key shortcoming
of prior ID frameworks is that they do not offer a way to
optimize the usage of resources. A solution that supports the
integration of multiple algorithms on IoT devices needs to
avoid accumulating their impact on the available resources.
A second omission is support for systematic reuse to create
different configurations. Addressing this in a transparent and
automated way offers the potential to significantly reduce the
effort of developing an IDS.
The first contribution of this paper consists in the formula-
tion of a design pattern for ID algorithms, based on properties
identified from a classification.
The second contribution is a framework called id-foo. It
enables the formal description of ID algorithms on a functional
level and provides a code generator producing source code for
a given platform and configuration. This way, id-foo addresses
the heterogeneous nature of both IoT and ID algorithms.
The third contribution introduces functional code fusion
(FCF) as a source code generation paradigm to address hard
to combine ID algorithms. FCF identifies common data and
functions, and organizes code to eliminate redundant iterations,
tests and computations. Results show reduced usage of the
wireless radio, execution time and memory usage.
The remainder of this paper proceeds as follows: section
II describes the inherent problems in the combination of ID
algorithms. Section III analyses and classifies ID algorithms.
Section IV looks for patterns in the implementation of these
classes. Section V describes the design we applied to construct
id-foo, its domain specific language (DSL) and code generator.
Section VI discusses and evaluates an implementation. Section
VII explores related work in the field of DSLs and code
generation. Finally, section VIII summarizes our findings,
draws conclusions and identifies topics for future work.
A
v
a
i
l
a
b
l
e
o
n
l
i
n
e
a
t
w
w
w
.
s
c
i
e
n
c
e
d
i
r
e
c
t
.
c
o
m
Procedia Computer Science 00 (2015) 000–000
www.elsevier.com/locate/procedia6th International Conference on Emerging Ubiquitous Systems and Pervasive Networks,
EUSPN-2015 and the 5th International Conference on Current and Future Trends of Information
and Communication Technologies in Healthcare, ICTH 2015,foo-lang: A framework for e�cient source code generation
of detection algorithms for the Internet of ThingsChristophe Van Ginneken, Jef Maerien, Christophe Huygens, Wouter Joosen, Danny Hughes
iMinds-DistriNet, KU Leuven, 3001 Leuven, Belgium{firstname.lastname}@cs.kuleuven.be
A
b
s
t
r
a
c
t
The ability to detect patterns in its application context is what makes things smart. The more patterns it can detect, the more
accurate its operational results will be. However, supporting an adequate set of pattern detection algorithms imposes significant
overhead on resource-constrained devices such as those in the Internet of Things. Manual fusion of the algorithms reduces resource
consumption by optimizing resource sharing, yet, proves to be time-consuming, repetitive and error-prone. To address this problem
we propose foo-lang, a framework for the generation of e�cient combinations of detection algorithms. It consists of a domain
specific language and a code generator. The language allows formally describing the intent of detection algorithms and supports
the generator in organizing the source code. As a case study, we apply foo-lang to the generation of an intrusion detection system for
wireless sensor nodes. A side-by-side comparison shows that foo-lang-generated source code reduces message passing overhead,
execution time and memory footprint in comparison to sequential calls into standalone implementations of the algorithms.
c� 2015 The Authors. Published by Elsevier B.V.Peer-review under responsibility of the Program Chairs.Keywords:
Internet of Things, Domain Specific Languages, Source Code Generation, Source Code Optimization, Intrusion Detection, Context Awareness1
.
I
n
t
r
o
d
u
c
t
i
o
n
The Internet of Things (IoT), the mother of all ubiquitous and pervasive networks, populates our daily lives with
millions of internet-connected smart things: from smart watches that assist visually impaired persons ? to monitoring
systems for waste management in smart cities ? . Their applications cannot be more diverse, however they share
one common concern: each of these things is resource-constrained, relying on a battery and operating with limited
processing power and memory.Although their applications at first seem unrelated, under the hood they share a common paradigm: pattern recog-
nition. With the introduction of smart things, we want to augment our lives with information that is hard, or at least
time and resource consuming, to obtain otherwise. The ability to detect patterns in its usage or its applied context, is
what makes these things smart. A watch that recognizes gestures can perform certain actions on behalf of its wearer.
That same watch can also detect a wet floor and notify this hazard ? .Monitoring human activities is an active research field for more than a decade ? , but with the advent of the IoT it
now moves into the real world at an increased pace. Equipped with wearables, hosting numerous sensors, the possi-
1877-0509 c� 2015 The Authors. Published by Elsevier B.V.Peer-review under responsibility of the Program Chairs.
WoWMoM15 EUSPN15
FCF
FCF
manualbase heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%# frames 20 51 255% 32 160% 63 315%bytes 476 1933 406% 860 181% 2317 487%event loop (microseconds) 48 94 196% 88 183% 149 310%
generatedbase heartbeat reputation both
size (bytes) 10496 18352 175% 16376 156% 20998 200%# frames 20 49 245% 32 160% 55 275%bytes 476 1897 399% 884 186% 2161 454%event loop (microseconds) 48 121 252% 121 252% 138 288%
nesCbase heartbeat reputation both
size (bytes) 11628 16198 139% 14306 123% 18676 161%# frames 19 52 274% 35 184% 73 384%bytes 452 1922 425% 916 203% 2486 550%event loop (microseconds) 95 103 108% 101 106% 116 122%
FCF
manualbase heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%# frames 20 51 255% 32 160% 63 315%bytes 476 1933 406% 860 181% 2317 487%event loop (microseconds) 48 94 196% 88 183% 149 310%
nesCbase heartbeat reputation both
size (bytes) 11628 16198 139% 14306 123% 18676 161%# frames 19 52 274% 35 184% 73 384%bytes 452 1922 425% 916 203% 2486 550%event loop (microseconds) 95 103 108% 101 106% 116 122%
+56us
+8us
static inline void taskLoop(void) { for(;;) { uint8_t nextTask; while((nextTask = popTask()) == NO_TASK) { cycles++; sleep(); } runTask(nextTask); cycles++; } }
FCFI could use some sleep !
DUH! :-(
static inline void taskLoop(void) { for(;;) { uint8_t nextTask; if((nextTask = popTask()) != NO_TASK) { runTask(nextTask); } cycles++; } }
FCF
manualbase heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%# frames 20 51 255% 32 160% 63 315%bytes 476 1933 406% 860 181% 2317 487%event loop (microseconds) 48 94 196% 88 183% 149 310%
nesCbase heartbeat reputation both
size (bytes) 11628 16198 139% 14306 123% 18676 161%# frames 19 52 274% 35 184% 73 384%bytes 452 1922 425% 916 203% 2486 550%event loop (microseconds) 95 103 108% 101 106% 14 15%
FCF
Koksijde
De Panne
FCF
while(TRUE) { application_step(); !#ifdef WITH_HEARTBEAT xbee_receive(); measure(heartbeat_step();); #endif !#ifdef WITH_REPUTATION xbee_receive(); measure(reputation_step();); #endif ! xbee_receive(); ! report_metrics(); } ! return(0); }
module XBeeC { ... uses interface Boot; uses interface Timer<TMilli> as Timer0; } !implementation { ... event void Boot.booted() { ... call Timer0.startPeriodic(100); ... } ... task void receive() { xbee_receive(); } ! event void Timer0.fired() { post receive(); } }
3x / event loop cycle 1x / 100ms
149us 14us
detailed story on http://github.com/christophevg/tinymoose
= 1x / 6666 loops
FCF
module XBeeC { ... uses interface Boot; uses interface Timer<TMilli> as Timer0; } !implementation { ... event void Boot.booted() { ... call Timer0.startPeriodic(100); ... } ... task void receive() { xbee_receive(); } ! event void Timer0.fired() { post receive(); } }
1x / 100ms
101us 14us time_t now = clock_get_millis(); time_t next_receive = now; ! while(TRUE) { now = clock_get_millis(); ... // process incoming packets if( now >= next_receive ) { xbee_receive(); next_receive += RECEIVE_INTERVAL; } ... }
1x / 100ms
detailed story on http://github.com/christophevg/tinymoose
FCF
detailed story on http://github.com/christophevg/tinymoose
// something.c void do_something_step() { static time_t next = 0; if(next == 0) { next = clock_get_millis(); } if(clock_get_millis() >= next) { // do something ... } } !// main.c while(TRUE) { ... do_something_step(); ... }
// something.c void do_something_step() { // do something ... } !// main.c time_t next = clock_get_millis(); !while(TRUE) { ... if( clock_get_millis() >= next ) { do_something_step(); next += STEP_INTERVAL; } ... }
event looppart event
loop (μs) %
base case 149receive 101 32%reporting 80 46%heartbeat 51 66%reputation 28 81%light reading 18 88%continue 17 89%
nesC: app.cfunction calls are expensive
modules prohibit inlining
FCF
FCF
Good coding practices can produce bad binary code.
function calls are expensivemodules prohibit inlining
#define
.hstatic inline in
(code generation should employ every trick in the book to generate source code to help compilers produces efficient binary code)
FCF
Compilers can’t optimise functionally related code.
function jamming
event-driven/reactive algorithms can expose intent
!raising the level of abstraction allows for
Functional Code Fusion
loops are evil
FCF
A good implementation of reactive-c might provide an inner-DSL
to use to generate good event-driven code.
reactive-c rose
If FCF can be applied in the context of rose it allows for optimised micro-updates.
http://www.slideshare.net/christophevg/what-have-i-silently-been-up-to