![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
Difference between revision 8 and current revision
No diff available.very interesting slides on in-memory computation:
http://web.stanford.edu/class/ee380/Abstracts/171108-slides.pdf
looks like they are doing the O(ln(n)) in-parallel-similarity-query thing i thought of, as well as some other stuff
---
The stack cookie (also known as "canary") does not prevent the return address from being overwritten, but it increases the chances that the code notices the overwrite before fatefully following the overwritten return address.
This is heuristic: the idea is that most buffer overflows which end up with overwriting the return address proceed sequentially from a stack buffer, one the "other side" of the cookie slot, thus will also overwrite the cookie. "Keeping the cookie intact" requires that the attacker can somehow make a "jumping overflow" (it happens, but rarely) or can obtain the cookie value so that he can overwrite the cookie value with itself. Obtaining the cookie value is hard since it is normally chosen randomly at execution time (details vary depending on the OS and OS version), and not advertised; in some rare situations, the attacker can obtain the cookie value indirectly from the consequences of another exploitable vulnerability.
In practice the stack cookie makes the attacker's life a bit harder, but for a quite big bit. It is not 100% effective, as a defence mechanism, but it is not trivially worked around either. shareeditflag
answered Dec 19 '13 at 18:04 Tom Leek 140k20281416
add a comment up vote 0 down vote
A stack canary protects the return address on the stack by first checking the canary value before moving the return address from the stack to the EIP. In order to overwritten the return address on the stack with a stack based buffer overflow the canny must be over written. If it is known that the return address on the stack was overwritten then program can exit safely without passing the flow of execution to the attacker.
---
" 12.7. Access permissions
Access permissions are controlled through translation table entries. Access permissions control whether a region is readable or writeable, or both, and can be set separately to EL0 for unprivileged and to EL1, EL2, and EL3 for privileged accesses, as shown in Table 12.4.
Table 12.4. Access permissions AP Unprivileged (EL0) Privileged (EL1/2/3) 00 No access Read and write 01 Read and write Read and write 10 No access Read-only 11 Read-only Read-only
The operating system kernel runs in execution level EL1. It defines the translation table mappings, which are used by the kernel itself and by the applications that run at EL0. Distinction between unprivileged and privileged access permissions is required as the kernel specifies different permissions for its own code and for applications. The hypervisor, which runs at execution level EL2, and Secure monitor EL3 only have translation schemes for their own use and therefore there is no need for a privileged and unprivileged split in permissions.
Another kind of access permission is the executable attribute. Blocks can be marked as executable or non-executable (Execute Never (XN)). You can set the attributes Unprivileged Execute Never (UXN) and Privileged Execute Never (PXN) separately and use this to prevent, for example, application code running with kernel privilege, or attempts to execute kernel code while in an unprivileged state. Setting these attributes prevents the processor from performing speculative instruction fetches to the memory location and ensures that speculative instruction fetches do not accidentally access locations that might be perturbed by such an access, for example, a First in, First out (FIFO) page replacement queue. Therefore, device regions must always be marked as Execute Never. "
---
some types of exploit mitigations:
" A virtual-memory region that automatically grows as a result of page faults brings some inherent risks; in particular, it must be prevented from growing into another memory region placed below it. ... In a single-threaded process, the address space reserved for the stack can be large and difficult to overflow. Multi-threaded processes contain multiple stacks, though; those stacks are smaller and are likely to be placed between other virtual-memory areas of interest ... The kernel has long placed a guard page — a page that is inaccessible to the owning process — below each stack area. (Actually, it hasn't been all that long; the guard page was added in 2010). A process that wanders off the bottom of a stack into the guard page will be rewarded with a segmentation-fault signal, which is likely to bring about the process's untimely end."
" As you probably already know... memory addresses from a user-mode applications perspective are virtual. So this means that a NULL pointer can actually be a valid virtual memory address. There have been many exploits taking advantage of NULL pointer dereferences to execute code.
I believe what EMET is doing is pre-allocating memory at the virtual address 0x00000000 and probably setting the protection to PAGE_NOACCESS or PAGE_GUARD. You could then use an exception handler to detect access to this address. "
---
" Yes, Linux supports no less then 4 different scheduling methods for tasks: SCHED_BATCH, SCHED_FAIR, SCHED_FIFO and SCHED_RR.
Regardless of scheduling method, all tasks also have a fixed hard priority (which is 0 for batch and fair and from 1- 99 for the RT schedulign methods of FIFO and RR). Tasks are first and foremost picked by priority - the highest priority wins.
However, with several tasks available for running with the same priority, that is where the scheduling method kicks in: A fair task will only run for its allotted weighted (with the weight coming from a soft priority called the task nice level) share of the CPU time with regard to other fair tasks, a FIFO task will run for a fixed time slice before yielding to another task (of the same priority - higher priority tasks always wins) and RR tasks will run till it blocks disregarding other tasks with the same priority.
Please note what I wrote above is accurate but not complete, because it does not take into account advance CPU reservation features, but it give the details about different scheduling method interact with each other. "
---
" ASN.1 is a very tricky thing to pull off well ▫ Multiple vulns in OpenSSL?, NSS, ASN1C, etc • LibDER? itself actually rather solid "
---
someday need to write a simplified/subsetted YAML. There are a few of these already, must check my notes for them
also a lightweight markup language
---
"The RISC-V Foundation has launched the J extension working group today, to better support managed-language support to RISC-V."
---
ausjke 1274 days ago [-]
This is well known in IoT? field I assume, I used it a few years back, after comparing with tinyos and such. Basically you have Linux, then FreeRTOS?, then Contiki, from large system to the tiny devices.
kqr2 1274 days ago [-]
Based on this embedded systems survey [1], FreeRTOS? is actually quite popular.
[1] http://www.eetimes.com/document.asp?doc_id
---
seL4 vs FreeRTOS? vs Contiki:
" >>>> - FreeRTOS? is a generic Real Time Operating System, while Contiki is >>>> not, it has no conventional threads nor preemption. >>>> >>>> - FreeRTOS? is a generic OS, it runs uIP only. While Contiki is a >>>> 802.15.4 OS, specific tailored to bring 802.15.4 networks to life, FreeRTOS? >>>> doesn't do that by default "
"This is well known in IoT? field I assume, I used it a few years back, after comparing with tinyos and such. Basically you have Linux, then FreeRTOS?, then Contiki, from large system to the tiny devices."
others: TINY OS, RIOT
this comment says Contiki is leading tiny OS:
" It's interesting to see that Contiki is taking the lead in this space, since it was once going toe-to-toe with another open source OS for wireless embedded networked devices, TinyOS?. TinyOS? had a large following in the research community and I believe it was used in several commercial sensor network deployments by Dust Networks and Arch Rock and at least one other Korean startup company -- that i believe is still using it in their deployments. "
" Contiki and Tiny OS are not real time systems, but their presence on the market is domin ant (mainly in wireless sensor networks) and therefore they are used for reference. The same reason applies to Linux. "
" Programming models with Contiki and TinyOS? are defined by events in a way that all tasks are executed in the same context, although they offer a partial multithreading support. Contiki uses a programming language similar to C, but can’t use certain keywords. TinyOS? is written in the language called nesC, which is similar but not compatible with the C language. Linux, on the other hand, supports true multithreading, it is written in standard C, and it offers support for various programming languages
TinyOS? version 2.1 introduces TOSThreads, fully preemptable user-level applicati on threads library [4], in which programmer can use C and nesC APIs, but outside of that still has to use only nesC.
A TinyOS? has to be present in the form of source code or as a library during the compilation of user programs (static linking), providing a common binary program which is then programmed into device. This approach simplifies some things, such as better resource usage analysis, or more efficient optimization. On the other hand, changes in customer applications require a redistribution of the entire operating system. Unlike TinyOS?, Contiki has the ability to load individual applications or services during the execution of the operating system on the device, which resembles the mechanisms on general purpose computers. On top of Contiki basic event- driven kernel other execution models can be used. Instead of the simple event handlers processes can use Protothreads [5]. Protothreads are simple forms of normal threads in a multi-threaded environment. Protothreads are stackless so they save their state information in the private memory of the pr ocess. Like the event handler Protothreads can not be preempted and run until the it puts itself into a waiting state until it is scheduled again. Along with event-driven kern el, Contiki also contains a preemptive multithreading library. It is statically linked with application program only if the program explicitly calls some of its functions. However, each thread from this library must have its own stack, which is not the case in Protothreads [6 ].
"
min RAM and ROM according to Choosing the right RTOS for IoT platform (2015):
min RAM:
min ROM:
FreeRTOS?: "Typically a kernel binary image will be in the region of 4kB to 9kB [7]."
ChibiOS?/RT: "The kernel size with all the subsystems activated weighs around 5.5kB for STM32 Cortex-M3 microcontroller"
RT-Thread: "The kernel itself occupies as low as 3kB in ROM and 1kB in RAM"
Erika Enterprise: "minimal memory footprint of 2kB, up to more complete configurations"
" The greatest disadvantage of freeRTOS is that it doesn’t implement advanced mechanism for shared resources like priority ceilings to avoid priority inversion. "
so it sounds like the small ones mentioned here are FreeRTOS?, RIOT, TinyOS?, ChibiOS?/RT, RT-Thread, Erika
https://hal.inria.fr/hal-01245551/file/IoT-OS-survey.pdf classifies small devices via RFC 7228 into class 0 (<<10k RAM, <<100k ROM), class 1 (~10k RAM, ~100k ROM), class 2. Table I mentions the following prominent class 0 and 1 FOSS systems (their classification is actually a little more nuanced than this):
(they also mention other 'not as prominent' systems: class 0: nanoRK, Nut/OS, class 1: ChibiOS?/RT)
they also mention that the L4 microkernel family, including seL4, is too heavy for class 1; except for F9.
they also mention that uClinux is too heavy for class 1.
they say:
" Contiki [40], [41]: Contiki was originally developed as an OS for WSNs running on very memory-constrained 8-bit MCUs, but now also runs on 16-bit MCUs and modern IoT? devices based on the ARM 32-bit MCUs. It is based on an event-driven, cooperative scheduling approach, with support for lightweight pseudo-threading. While being written in the C programming language, some parts of the OS make use of macro-based abstractions (e.g., Protothreads [42]), and in effect require developers to consider certain restrictions as to what type of language features they can use. Contiki code is available under BSD license on GitHub? 3 and other platforms, while a large variety of forks are developed independently (including many closed source versions of the OS). Contiki features several network stacks, including the popular uIP stack, with support for IPv6, 6LoWPAN?, RPL, and CoAP?; and the Rime stack, which provides a set of distributed programming abstractions. Contiki is developed since 2002, and is so far one of the most used open source OSs for constrained nodes.
2) RIOT [43]–[45]: RIOT was developed with the partic- ular requirements of IoT? in mind and aims for a developer- friendly programing model and API, e.g. similar to what is experienced on Linux. RIOT is a microkernel-based RTOS with multi-threading support, using an architecture inherited from FireKernel? [46]. While the OS is written in C (ANSI99), applications and libraries can also be implemented in C++. The source code is available on GitHub? 4 under LGPLv2.1. RIOT features several network stacks, including its own im- plementation of the full 6LoWPAN? stack (the gnrc stack), a port of the 6TiSCH? stack OpenWSN? [47], and a port of the information centric networking stack CCN-lite [48]. RIOT is developed as such since 2012, by a growing, world-wide open source community.
3) FreeRTOS? [49]: FreeRTOS? is a popular RTOS which has been ported to many MCUs. Its preemptive microkernel has support for multi-threading. It is now developed by Real Time Engineers Ltd. and its code is available on the project page under a modified GPL that allows commercial usage
with closed source applications (only the kernel has to remain open source). Although it does not provide its own network stack, third-party network stacks can be used for Internet connectivity. FreeRTOS? is developed since 2002, and is so far one of the most used open source RTOSs for constrained nodes.
4) TinyOS? [50]: Together with Contiki, TinyOS? is the most prominent OS for WSN applications, targeting very constrained 8 bit and 16 bit platforms and is known for its sophisticated design. TinyOS? and nesC evolved language prim- itives and programming abstractions to prevent as many bugs as possible through software structure and enhance memory efficiency by reducing the actual linked code to a minimum. However, the rather complex design in combination with a customized programming language makes it hard to learn, and it is thus lacking a bigger developer community [51]. It follows an event-driven approach, where several components or modules can be virtually wired, as described by configu- rations according the requirements. It is written in a dialect of the C programming language, called nesC . Its source code is available online under the BSD license on GitHub? 5 . The included BLIP network stack implements the 6LoWPAN? stack. TinyOS? is developed since 2000, and is so far one of the most used open source OSs for constrained nodes, with Contiki.
5) OpenWSN? [47]: OpenWSN? comprises a 6TiSCH? net- work stack, a basic scheduler, and a Board Support Package (BSP) i.e., a simple hardware abstraction, making it possible to run OpenWSN? on a dozen IoT? hardware platforms. As such, OpenWSN? is more of a network stack than a full-fledged OS. OpenWSN? code is available online under the BSD license on GitHub? 6 . The main focus of OpenWSN? is the 6TiSCH? network stack, including an implementation of the IEEE 802.15.4e MAC amendment [26]. OpenWSN? is developed since 2010, by a growing, world-wide open source community.
6) nuttX [52]: The nuttX OS aims for full POSIX and ANSI compliance and supports MCUs ranging from 8 bit up to 32 bit architectures. NuttX? can be built as a microkernel as well as a monolithic version. It is highly modular and features real-time capabilities as well as a tickless scheduler. The source code is available under BSD license on Sourceforge 7 . The integrated network stack includes support for IPv4 and IPv6 with various upper layer protocols. NuttX? is developed since 2007.
7) eCos [53]: The embedded configurable operating system (eCos) supports 16, 32, and 64 bit embedded hardware. eCos code is available under a custom license based on GPL with linking exception (acknowledged by FSF). While the open source version of eCos seems rather inactive, the commercial version (eCosPro by eCosCentric) is under active develop- ment. eCos does not provide an own network stack per se, but supports third-party network stacks (lwIP and the FreeBSD? network stack). The source code is available in a Mercurial repository 8 . eCos is developed since 2002, but parts of the code-base are older.
they divide OSs into 3 categories:
Event-driven OSs:
This is the most common approach for OSs initially de- veloped to target the domain of WSNs, such as Contiki or TinyOS? for instance. The key idea of this model is that all processing on the system is triggered by an (external) event, typically signaled by an interrupt. As a consequence the kernel is roughly equivalent to an infinite loop handling all occurring events within the same context. Such an event handler typically runs to completion. While this approach is efficient in terms of memory consumption and low complexity, it imposes some substantial constraints to the programmer e.g., not all programs are easily expressed as a finite state machine [40]. OSs that fall in this category include Contiki, TinyOS?, and OpenWSN?. Because of its wider deployment and use (to the best of our knowledge), Contiki is arguably a good representative of this category of OS.
Multi-Threading OSs:
Multi-threading is the traditional approach for most modern OSs (e.g. Linux), whereby each thread runs in its own con- text and manages its own stack. With this approach, some scheduling has to perform context switching between the threads. Each process is handled in its own thread and can, in general, be interrupted at any point. Stack memory can usually not be shared between threads. Hence, a multi-threading OS usually introduces some memory overhead due to stack over- provisioning and runtime overhead due to context switching. Operating systems that fall in this category include RIOT, nuttX, eCos, or ChibiOS?. Because of its stronger focus on IoT? requirements (to the best of our knowledge), RIOT is arguably a good representative of this category of OS.
Pure RTOSs:
An RTOS focuses primarily on the goal of fulfilling real- time guarantees, in an industrial/commercial context. In this context, formal verification, certification, and standardization are usually of crucial importance. To allow model checking and formal verification, the programming model used in such OSs typically imposes strict constraints for developers. These restrictions often makes the OS rather inflexible and porting to other hardware platforms may become rather difficult. Oper- ating systems for IoT? devices that fall in this category include FreeRTOS?, eCos, RTEMS, ThreadX?, and a collection of other commercial products (generally closed source). FreeRTOS? is to the best of our knowledge the most prominent open source RTOS for IoT? devices, due to its wider use in various environments.
they then present detailed notes on one representative from each of these: Contiki, RIOT, FreeRTOS?.
again the link is: https://hal.inria.fr/hal-01245551/file/IoT-OS-survey.pdf
" Contiki (event-based):
At runtime, all processes share the same memory space and privileges with the core system. ... cooperative thread scheduling ... For memory allocation, Contiki is designed primarily for static allocation...third-party dynamic allocation modules for Contiki, which implement the standard C malloc API ... programming model is based on Protothreads , which is a sort of light-weight, cooperative threading concept similar to continuations [42]. The main programming language sup- ported by Contiki is C, but there exist runtime environments that enable development in languages such as Java [92] and Python [93]. ... provides features such as a shell, a file system, a database management system, runtime dynamic linking, cryptography libraries, and a fine- grained power tracing tool. ... Multiple real-world deployments are based on Contiki, and it is widely used in commercial IoT? products, as well as in academic research on WSN and other types of constrained wireless multi-hop networks. Along with TinyOS?