O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
Christophe.VanGinneken@cs.kuleuven.be
NES - Status Update June 2015
What have I silently been up to?
reactive-c
rose
FCF
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 C
inner DSL
integration of primitives
scripting
function lifting
map, filter, fold
detailed sto...
reactive-c
detailed story on http://github.com/christophevg/reactive-c
a = b + c
see also PL@NES
reactive-c
dependency graph API
support for interrupts
more functions
“What is the overhead ?”
vs manual observer pattern ...
reactive-c
Relative Throughput
25%
50%
75%
100%
observer.c reactive-c
chain fan
chain fan
…source observer source observer...
rose
+ OTAP
reactive-c
+ VM-ish
detailed story on http://github.com/christophevg/rose
rose
implement OTAP
port to embedded platform
“What is the overhead ?”
create VM management tool
finalize VM
vs manual obse...
FCF
Verlagen van de impact van inbraakdetectiein draadloze sensornetwerken door middelvan een domeinspecifieke taal encodeg...
JTAG
RS-232
XBee ZigBee
module
ATMEGA
1284p
light
sensor
power, reset,
indicators
FCF
FCF
manual
base heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%
# frames 20 51 255% 32 160% ...
FCF
manual
base heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%
# frames 20 51 255% 32 160% ...
FCF
manual
base heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%
# frames 20 51 255% 32 160% ...
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 usage
through piggy bagging.
FCF
centralisedcommonfunctionality
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, C...
FCF
FCF
manual
base heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%
# frames 20 51 255% 32 160% ...
FCF
manual
base heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%
# frames 20 51 255% 32 160% ...
static inline void taskLoop(void) {
for(;;) {
uint8_t nextTask;
while((nextTask = popTask()) == NO_TASK) {
cycles++;
sleep...
FCF
manual
base heartbeat reputation both
size (bytes) 10500 15530 148% 13306 127% 18334 175%
# frames 20 51 255% 32 160% ...
FCF
Koksijde
De Panne
FCF
while(TRUE) {
application_step();
!
#ifdef WITH_HEARTBEAT
xbee_receive();
measure(heartbeat_step(););
#endif
!
#ifdef ...
FCF
module XBeeC {
...
uses interface Boot;
uses interface Timer<TMilli> as Timer0;
}
!
implementation {
...
event void Bo...
FCF
detailed story on http://github.com/christophevg/tinymoose
// something.c
void do_something_step() {
static time_t nex...
FCF
FCF
Good coding practices
can produce bad binary code.
function calls are expensive
modules prohibit inlining
#define
.hst...
FCF
Compilers can’t optimise
functionally related code.
function jamming
event-driven/reactive algorithms
can expose inten...
FCF
A good implementation of reactive-c
might provide an inner-DSL

to use to generate good event-driven code.
reactive-c ...
http://www.slideshare.net/christophevg/what-have-i-silently-been-up-to
Christophe.VanGinneken@cs.kuleuven.be
What have I silently been up to?
What have I silently been up to?
What have I silently been up to?
What have I silently been up to?
What have I silently been up to?
What have I silently been up to?
What have I silently been up to?
What have I silently been up to?
Próximos SlideShares
Carregando em…5
×

What have I silently been up to?

290 visualizações

Publicada em

A brief summary/overview of the things I've been working on for the past 9 months.

Publicada em: Software
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

What have I silently been up to?

  1. 1. Christophe.VanGinneken@cs.kuleuven.be NES - Status Update June 2015 What have I silently been up to?
  2. 2. reactive-c rose FCF
  3. 3. reactive-c detailed story on http://github.com/christophevg/reactive-c see also PL@NES
  4. 4. reactive-c detailed story on http://github.com/christophevg/reactive-c see also PL@NES
  5. 5. reactive-c glitch-free pure C inner DSL integration of primitives scripting function lifting map, filter, fold detailed story on http://github.com/christophevg/reactive-c see also PL@NES
  6. 6. reactive-c detailed story on http://github.com/christophevg/reactive-c a = b + c see also PL@NES
  7. 7. reactive-c dependency graph API support for interrupts more functions “What is the overhead ?” vs manual observer pattern implementation detailed story on http://github.com/christophevg/reactive-c
  8. 8. reactive-c Relative Throughput 25% 50% 75% 100% observer.c reactive-c chain fan chain fan …source observer source observers … Intel 2,4 GHz Intel Core 2 Duo 2530Mhz operating frequency level-based priority queue dynamic functionality clean implementation “What is the overhead ?” 9% 2% detailed story on http://github.com/christophevg/reactive-c
  9. 9. rose + OTAP reactive-c + VM-ish detailed story on http://github.com/christophevg/rose
  10. 10. rose implement OTAP port 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
  11. 11. 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 Gedistribueerde systemen Promotoren:Prof. dr. ir. Wouter JoosenProf. dr. ir. Christophe Huygens Assessoren:Dr. Benjamin Negrevergne Dr. Nelson Matthys Begeleider: Drs. ir. Jef Maerien Academiejaar 2013 – 2014 master thesis id-foo (foo-lang) event-driven reactive optimising execution functional level
  12. 12. JTAG RS-232 XBee ZigBee module ATMEGA 1284p light sensor power, reset, indicators FCF
  13. 13. FCF manual base 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% generated base 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% heartbeat reputation
  14. 14. FCF manual base 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% generated base 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% heartbeat reputation
  15. 15. FCF manual base 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% generated base 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% heartbeat reputation
  16. 16. FCF 1) loop
 jamming 2) message aggregation 3) centralised
 common
 functionality
 
(scheduling, nodes,…)
  17. 17. FCF loop
 jamming
  18. 18. FCF message aggregation heartbeat reputation Goal: reduce wireless radio usage
  19. 19. FCF message aggregation heartbeat reputation Goal: reduce wireless radio usage through piggy bagging.
  20. 20. FCF centralisedcommonfunctionality one node and nodes scope one implementation one scheduler one parser
  21. 21. FCF foo-lang scheduling one parser one node nodes scope 1 implementation
  22. 22. 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. Available online at www.sciencedirect.com Procedia Computer Science 00 (2015) 000–000 www.elsevier.com/locate/procedia 6th 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 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 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 Awareness 1. Introduction 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
  23. 23. FCF
  24. 24. FCF manual base 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% generated base 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% nesC base 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%
  25. 25. FCF manual base 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% nesC base 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
  26. 26. static inline void taskLoop(void) { for(;;) { uint8_t nextTask; while((nextTask = popTask()) == NO_TASK) { cycles++; sleep(); } runTask(nextTask); cycles++; } } FCF I could use some sleep ! DUH! :-( static inline void taskLoop(void) { for(;;) { uint8_t nextTask; if((nextTask = popTask()) != NO_TASK) { runTask(nextTask); } cycles++; } }
  27. 27. FCF manual base 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% nesC base 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%
  28. 28. FCF
  29. 29. Koksijde De Panne
  30. 30. 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
  31. 31. 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
  32. 32. 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 loop part event loop (μs) % base case 149 receive 101 32% reporting 80 46% heartbeat 51 66% reputation 28 81% light reading 18 88% continue 17 89% nesC: app.c function calls are expensive modules prohibit inlining
  33. 33. FCF
  34. 34. FCF Good coding practices can produce bad binary code. function calls are expensive modules 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)
  35. 35. 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
  36. 36. 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.
  37. 37. http://www.slideshare.net/christophevg/what-have-i-silently-been-up-to Christophe.VanGinneken@cs.kuleuven.be

×