Compare commits
No commits in common. "package-centric-containers" and "static-code-analysis-kernel-task-memory-safety" have entirely different histories.
package-ce
...
static-cod
49 changed files with 5232 additions and 922 deletions
11
.gitignore
vendored
11
.gitignore
vendored
|
|
@ -5,10 +5,10 @@
|
||||||
*.fls
|
*.fls
|
||||||
*.lof
|
*.lof
|
||||||
*.log
|
*.log
|
||||||
|
*.lol
|
||||||
*.lot
|
*.lot
|
||||||
*.synctex.gz
|
*.synctex.gz
|
||||||
*.toc
|
*.toc
|
||||||
src/docs/*.pdf
|
|
||||||
*.dvi
|
*.dvi
|
||||||
*.glo
|
*.glo
|
||||||
*.ist
|
*.ist
|
||||||
|
|
@ -16,4 +16,13 @@ src/docs/*.pdf
|
||||||
.dot/*
|
.dot/*
|
||||||
*.out
|
*.out
|
||||||
*.bbl
|
*.bbl
|
||||||
|
*-blx.bib
|
||||||
|
*.bcf
|
||||||
*.blg
|
*.blg
|
||||||
|
*.run.xml
|
||||||
|
|
||||||
|
.vscode/
|
||||||
|
|
||||||
|
/src/docs/thesis.pdf
|
||||||
|
/docs/
|
||||||
|
_minted*/
|
||||||
|
|
|
||||||
120
.vimrc
Normal file
120
.vimrc
Normal file
|
|
@ -0,0 +1,120 @@
|
||||||
|
set nocompatible
|
||||||
|
|
||||||
|
" leader
|
||||||
|
let mapleader = '\'
|
||||||
|
|
||||||
|
" save on ctrl-s
|
||||||
|
nnoremap <c-s> :w<CR>
|
||||||
|
inoremap <c-s> <Esc>:w<CR>
|
||||||
|
|
||||||
|
set hidden
|
||||||
|
syntax on
|
||||||
|
set hlsearch
|
||||||
|
set number
|
||||||
|
set relativenumber
|
||||||
|
|
||||||
|
" mappings to stop insert mode
|
||||||
|
imap jjj <ESC>
|
||||||
|
imap kkk <ESC>
|
||||||
|
imap lll <ESC>
|
||||||
|
imap hhh <ESC>
|
||||||
|
set scroll=11
|
||||||
|
|
||||||
|
" new scroll mappings
|
||||||
|
noremap <C-j> <C-f>
|
||||||
|
noremap <C-k> <C-u>
|
||||||
|
|
||||||
|
noremap <C-n> :tabn<CR>
|
||||||
|
noremap <C-p> :tabp<CR>
|
||||||
|
" TODO: get tab movement working with ctrl-alt-{n,p}
|
||||||
|
noremap <C-A-n> :tabm +1<CR>
|
||||||
|
noremap <C-A-p> :tabm -1<CR>
|
||||||
|
let g:ctrlp_map = '<tab>'
|
||||||
|
let g:ctrlp_custom_ignore = {
|
||||||
|
\ 'dir': '\v[\/]\.(git|hg|svn|)$$',
|
||||||
|
\ 'file': '\v\.(exe|so|dll|so|swp|zip|aux|log|fdb_latexmk|fdb|dvi|lof|lot|pdf|fls|toc|gz|latexmain)$$',
|
||||||
|
\ }
|
||||||
|
|
||||||
|
" allways show status line
|
||||||
|
set ls=2
|
||||||
|
set tabstop=4
|
||||||
|
set shiftwidth=4
|
||||||
|
set softtabstop=4
|
||||||
|
set expandtab
|
||||||
|
"set textwidth=80
|
||||||
|
|
||||||
|
" sync default register to clipboard {
|
||||||
|
if has('unnamedplus')
|
||||||
|
set clipboard=unnamedplus
|
||||||
|
else
|
||||||
|
set clipboard=unnamed
|
||||||
|
endif
|
||||||
|
" }
|
||||||
|
|
||||||
|
" colored brackets {
|
||||||
|
let g:rbpt_colorpairs = [
|
||||||
|
\ ['brown', 'RoyalBlue3'],
|
||||||
|
\ ['Darkblue', 'SeaGreen3'],
|
||||||
|
\ ['darkgray', 'DarkOrchid3'],
|
||||||
|
\ ['darkgreen', 'firebrick3'],
|
||||||
|
\ ['darkcyan', 'RoyalBlue3'],
|
||||||
|
\ ['darkred', 'SeaGreen3'],
|
||||||
|
\ ['darkmagenta', 'DarkOrchid3'],
|
||||||
|
\ ['brown', 'firebrick3'],
|
||||||
|
\ ['gray', 'RoyalBlue3'],
|
||||||
|
\ ['black', 'SeaGreen3'],
|
||||||
|
\ ['darkmagenta', 'DarkOrchid3'],
|
||||||
|
\ ['Darkblue', 'firebrick3'],
|
||||||
|
\ ['darkgreen', 'RoyalBlue3'],
|
||||||
|
\ ['darkcyan', 'SeaGreen3'],
|
||||||
|
\ ['darkred', 'DarkOrchid3'],
|
||||||
|
\ ['red', 'firebrick3'],
|
||||||
|
\ ]
|
||||||
|
let g:rbpt_max = 16
|
||||||
|
let g:rbpt_loadcmd_toggle = 0
|
||||||
|
|
||||||
|
au VimEnter * RainbowParenthesesToggle
|
||||||
|
au Syntax * RainbowParenthesesLoadRound
|
||||||
|
au Syntax * RainbowParenthesesLoadSquare
|
||||||
|
au Syntax * RainbowParenthesesLoadBraces
|
||||||
|
" }
|
||||||
|
set backspace=indent,eol,start
|
||||||
|
colorscheme PaperColor
|
||||||
|
|
||||||
|
" Latex Related {{{
|
||||||
|
au BufRead,BufNewFile *.tex,*.md,*.markdown setlocal spell spelllang=en_us
|
||||||
|
|
||||||
|
let g:vimtex_view_method = 'zathura'
|
||||||
|
let g:vimtex_complete_enabled = 1
|
||||||
|
let g:vimtex_complete_close_braces = 1
|
||||||
|
let g:vimtex_complete_recursive_bib = 1
|
||||||
|
let g:vimtex_indent_enabled = 1
|
||||||
|
let g:vimtex_indent_bib_enabled = 1
|
||||||
|
let g:vimtex_fold_enabled = 1
|
||||||
|
let g:vimtex_fold_comments = 1
|
||||||
|
let g:vimtex_fold_preamble = 1
|
||||||
|
|
||||||
|
let g:vimtex_latexmk_options = '-verbose -pdf -shell-escape -file-line-error -synctex=1 -interaction=nonstopmode'
|
||||||
|
|
||||||
|
if !exists('g:ycm_semantic_triggers')
|
||||||
|
let g:ycm_semantic_triggers = {}
|
||||||
|
endif
|
||||||
|
let g:ycm_semantic_triggers.tex = [
|
||||||
|
\ 're!\\[A-Za-z]*cite[A-Za-z]*(\[[^]]*\]){0,2}{[^}]*',
|
||||||
|
\ 're!\\[A-Za-z]*ref({[^}]*|range{([^,{}]*(}{)?))',
|
||||||
|
\ 're!\\hyperref\[[^]]*',
|
||||||
|
\ 're!\\includegraphics\*?(\[[^]]*\]){0,2}{[^}]*',
|
||||||
|
\ 're!\\(include(only)?|input){[^}]*',
|
||||||
|
\ 're!\\\a*(gls|Gls|GLS)(pl)?\a*(\s*\[[^]]*\]){0,2}\s*\{[^}]*',
|
||||||
|
\ 're!\\includepdf(\s*\[[^]]*\])?\s*\{[^}]*',
|
||||||
|
\ 're!\\includestandalone(\s*\[[^]]*\])?\s*\{[^}]*',
|
||||||
|
\ ]
|
||||||
|
|
||||||
|
function! ViewerCallback() dict
|
||||||
|
call self.forward_search(self.out)
|
||||||
|
endfunction
|
||||||
|
let g:vimtex_view_zathura_hook_callback = 'ViewerCallback'
|
||||||
|
" }}}
|
||||||
|
|
||||||
|
" hack to copy mendeley bibliography
|
||||||
|
autocmd BufWritePost * execute ':silent ! cp /home/steveej/src/mendeley/Static-Code-Analysis-Kernel-Memory-Saftey.bib /home/steveej/src/steveej/msc-thesis/src/docs/thesis.bib >/dev/null 2>&1'
|
||||||
184
README.md
184
README.md
|
|
@ -1,168 +1,26 @@
|
||||||
# Package-Centric Source-Based Container Build System
|
# Using Static Code Analysis To Improve Kernel-Task Memory-Safety
|
||||||
|
|
||||||
## Motivation
|
# Simple Motivational Golden Circle
|
||||||
* There's no standardized way to create container images that include
|
* Describes what this project is about very briefly
|
||||||
applications built from upstream sources.
|
* Helps to keep track of the goals
|
||||||
* No standardized way to share artifacts for containers instead of whole
|
|
||||||
containers
|
|
||||||
* Application dependencies, which are mostly libraries, are typically
|
|
||||||
neglected when calculating container dependencies. This causes not knowing
|
|
||||||
what libraries are installed
|
|
||||||
|
|
||||||
## Features
|
## Who?
|
||||||
### Package-based container builds
|
* Primariliy: OS Software Developers
|
||||||
This project aims to find a solution for creating and managing containers in a package-centric manner.
|
* Secondary: End Users
|
||||||
In this context a package is both a definition of how to build (e.g. a Gentoo ebuild or Debian control file)
|
|
||||||
Every container will be able to specify their dependencies, which can be self-built packages or exact versions of already existing packages.
|
|
||||||
Like this the user will always exactly know what libraries, files, etc. is available to their container at runtime.
|
|
||||||
The specified container will have its dependencies on packages which themselves can be packaged separately into one container per package.
|
|
||||||
|
|
||||||
### Source-based builds
|
## Why?
|
||||||
To allow maximum flexibility for users, the package files must be able to describe source builds, which allows the user to make changes to the source before the package is built and integrated into the target container image.
|
* The Linux/C/C++ software is full of vulnerabilities
|
||||||
|
* A human solution is not reliable:
|
||||||
|
- Developers make mistakes anyway!
|
||||||
|
* C/C++ Compilers allow too many mistakes
|
||||||
|
* Hardware-supported memory-management with stack/heap is hard to implement safely
|
||||||
|
* Rust is a promising language
|
||||||
|
|
||||||
### Reproducibility
|
## How?
|
||||||
Builds of packages, as well as builds of container images, must be reproducible in a way that the same input always yields the same output.
|
* Look for a *technical* solution for these issues by first analyzing the status quo:
|
||||||
Because every change of a package yields in a different identity, the system allows to have multiple versions of one software application.
|
- Which popular systems are most vulnerable?
|
||||||
These can differ in properties like source code patches, build configuration options, target architecture, etc..
|
- What exact software situations cause these vulnerabilities?
|
||||||
|
* Look through CVE database
|
||||||
|
|
||||||
### Portability of the whole system
|
## What?
|
||||||
As a portable system, builds can be processed locally on a user's workstation or distributed to a bunch of servers.
|
* Find out if Rust can help with memory safety within the OS
|
||||||
|
|
||||||
### Shareable source and binary files
|
|
||||||
The build system will ship tools that make it easy to discover and share source and binary files that are respectively consumed and produced by the build system.
|
|
||||||
This will allow for very fast setups of containers that involve only downloading from trusted repositories.
|
|
||||||
|
|
||||||
# Usage
|
|
||||||
## Buildit configuration
|
|
||||||
**.buildit-config.yaml**
|
|
||||||
```
|
|
||||||
---
|
|
||||||
repository:
|
|
||||||
name: mysuperbinhost
|
|
||||||
upload-type: ssh
|
|
||||||
upload-path: containers@mysuperbinhost.org/containers
|
|
||||||
download-type: https
|
|
||||||
download-path: mysuperbinhost.org/containers
|
|
||||||
```
|
|
||||||
|
|
||||||
## Sysadmin needs patched nginx
|
|
||||||
|
|
||||||
### Sysadmin
|
|
||||||
In case a sysadmin needs a patched and specifically configured version of its favorite webserver nginx.
|
|
||||||
|
|
||||||
1. Put directories and files in place
|
|
||||||
|
|
||||||
---
|
|
||||||
Directory layout
|
|
||||||
```
|
|
||||||
├── nginx-prod
|
|
||||||
│ ├── container.yaml
|
|
||||||
│ ├── files
|
|
||||||
│ │ └── nginx.conf
|
|
||||||
│ └── pkgs
|
|
||||||
│ └── nginx
|
|
||||||
│ ├── patches
|
|
||||||
│ │ └── https-only.patch
|
|
||||||
│ └── pkg.yaml
|
|
||||||
```
|
|
||||||
---
|
|
||||||
**pkg.yaml**
|
|
||||||
```
|
|
||||||
---
|
|
||||||
base: www-servers/nginx-1.7.6
|
|
||||||
author: Sysadmin42 <sys@admin42.org>
|
|
||||||
patches:
|
|
||||||
patches/https-only.patch: "This patch denies all plain http requests"
|
|
||||||
https://github.com/nginx/nginx/commit/52e4dc2f74fd032dace01acbe5eb29ddf7c1ad96.patch:
|
|
||||||
"Fix buffer overruns"
|
|
||||||
use:
|
|
||||||
with:
|
|
||||||
- ipv6
|
|
||||||
- selinux
|
|
||||||
|
|
||||||
```
|
|
||||||
---
|
|
||||||
**container.yaml**
|
|
||||||
```
|
|
||||||
---
|
|
||||||
- vars:
|
|
||||||
author: Sysadmin42
|
|
||||||
name: nginx-production
|
|
||||||
version: 1.7.6-p1
|
|
||||||
os: linux
|
|
||||||
arch: amd64
|
|
||||||
|
|
||||||
- package:
|
|
||||||
type: embedded
|
|
||||||
path: ./pkgs/nginx
|
|
||||||
|
|
||||||
- sync:
|
|
||||||
src: ./files/nginx.conf
|
|
||||||
dest: /etc/nginx/nginx.conf
|
|
||||||
recursive: True
|
|
||||||
chmod: 0644
|
|
||||||
|
|
||||||
- image:
|
|
||||||
type: aci
|
|
||||||
content: |
|
|
||||||
{
|
|
||||||
"acKind": "ImageManifest",
|
|
||||||
"acVersion": "0.6.1",
|
|
||||||
"name": "{{ name }}-{{ version }}",
|
|
||||||
"labels": [
|
|
||||||
{"name": "os", "value": "{{ os }}"},
|
|
||||||
{"name": "arch", "value": "{{ arch }}"}
|
|
||||||
],
|
|
||||||
"app": {
|
|
||||||
"exec": [
|
|
||||||
"/sbin/nginx"
|
|
||||||
],
|
|
||||||
"user": "0",
|
|
||||||
"group": "0"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
2. Build the container
|
|
||||||
```
|
|
||||||
$ buildit nginx-prod/ --discover=github.com/sysadmin42/containers,push=True
|
|
||||||
Building Sysadmin42/nginx-production-1.7.6-p1
|
|
||||||
Processing package from './pkgs/nginx' for linux/amd64.
|
|
||||||
HASH: 86c8ef43-f4a4-49ba-a0ee-92900211c7b6
|
|
||||||
Can't find HASH in any known location...
|
|
||||||
Defaulting to local build... [OK]
|
|
||||||
Uploading packages to 'mysuperbinhost' [OK]
|
|
||||||
Packaging Sysadmin42/nginx-production-1.7.6-p1 as ACI... [OK]
|
|
||||||
Uploading container spec and image(s) to 'mysuperbinhost' [OK]
|
|
||||||
```
|
|
||||||
|
|
||||||
# Implementation
|
|
||||||
## Resources
|
|
||||||
### CoreOS related tools
|
|
||||||
* https://github.com/derekchiang/acbuild
|
|
||||||
* https://github.com/coreos/manifest
|
|
||||||
|
|
||||||
### Similar Projects
|
|
||||||
* Previous work of mine: https://embedux.github.io/documentation/usage/rootfs/configuration.yml/index.html
|
|
||||||
|
|
||||||
### Operating Systems and Package managers
|
|
||||||
* http://nixos.org/nixos/about.html
|
|
||||||
* https://gitweb.gentoo.org/proj/releng.git/tree/releases/weekly/specs/amd64?id=HEAD
|
|
||||||
* https://github.com/zefhemel/nix-docker
|
|
||||||
* [nix build farm
|
|
||||||
paper](http://www.researchgate.net/publication/228629017_The_Nix_Build_Farm_A_declarative_approach_to_continuous_integration)
|
|
||||||
* https://blogs.gentoo.org/zmedico/2015/07/06/tardelta-generate-a-tarball-of-differences-between-two-tarballs/
|
|
||||||
* https://github.com/jordansissel/fpm/wiki
|
|
||||||
|
|
||||||
## Outlook
|
|
||||||
The completion of the described container build system will benefit greatly to how container images can be shared and deployed.
|
|
||||||
|
|
||||||
### Trusted Containers by reproducibility
|
|
||||||
Trusting container images has been hard. Being able to reproduce and verify the builds improves this.
|
|
||||||
|
|
||||||
### Obsolete Container-Vulnerabilities Scans
|
|
||||||
Vulnerabilities scans are only necessary if it's unknown what the container image contains. With the new build system the build specification allows to inspect the included container images much more efficiently. Image vendors can directly track contained packages and their CVEs instead of relying on posteriori scans.
|
|
||||||
|
|
||||||
### Automatic Container Updates
|
|
||||||
When identified, regular and security updates to 3rd party packages can trigger rebuilds as well as changed source files of 1st party applications. The update circle can be closed by automatically deploying new containers triggered by the updated images.
|
|
||||||
Complete automation might be difficult in real-world deployments because software updates sometimes require configuration changes.
|
|
||||||
|
|
|
||||||
27
build/texlive-url-mirror.patch
Normal file
27
build/texlive-url-mirror.patch
Normal file
|
|
@ -0,0 +1,27 @@
|
||||||
|
diff --git a/pkgs/tools/typesetting/tex/texlive/bin.nix b/pkgs/tools/typesetting/tex/texlive/bin.nix
|
||||||
|
index 5591f64cee..2bdbfd50a7 100644
|
||||||
|
--- a/pkgs/tools/typesetting/tex/texlive/bin.nix
|
||||||
|
+++ b/pkgs/tools/typesetting/tex/texlive/bin.nix
|
||||||
|
@@ -20,7 +20,7 @@ let
|
||||||
|
common = rec {
|
||||||
|
src = fetchurl {
|
||||||
|
url = # "ftp://tug.org/historic/systems/texlive/${year}/"
|
||||||
|
- "http://lipa.ms.mff.cuni.cz/~cunav5am/nix/texlive-2016" # FIXME: a proper mirror
|
||||||
|
+ "http://146.185.144.154/texlive-2016/"
|
||||||
|
+ "/texlive-${year}0523b-source.tar.xz";
|
||||||
|
sha256 = "1v91vahxlxkdra0qz3f132vvx5d9cx2jy84yl1hkch0agyj2rcx8";
|
||||||
|
};
|
||||||
|
diff --git a/pkgs/tools/typesetting/tex/texlive/default.nix b/pkgs/tools/typesetting/tex/texlive/default.nix
|
||||||
|
index 692f6b1772..21463dc367 100644
|
||||||
|
--- a/pkgs/tools/typesetting/tex/texlive/default.nix
|
||||||
|
+++ b/pkgs/tools/typesetting/tex/texlive/default.nix
|
||||||
|
@@ -109,8 +109,7 @@ let
|
||||||
|
fixedHash = fixedHashes.${tlName} or null; # be graceful about missing hashes
|
||||||
|
|
||||||
|
url = args.url or "${urlPrefix}/${urlName}.tar.xz";
|
||||||
|
- urlPrefix = args.urlPrefix or
|
||||||
|
- http://lipa.ms.mff.cuni.cz/~cunav5am/nix/texlive-2016;
|
||||||
|
+ urlPrefix = http://146.185.144.154/texlive-2016;
|
||||||
|
# XXX XXX XXX FIXME: mirror the snapshot XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX XXX
|
||||||
|
# ("${mirror}/pub/tex/historic/systems/texlive/${bin.texliveYear}/tlnet-final/archive");
|
||||||
|
#mirror = "http://ftp.math.utah.edu";
|
||||||
41
build/update-minted-2.5.patch
Normal file
41
build/update-minted-2.5.patch
Normal file
|
|
@ -0,0 +1,41 @@
|
||||||
|
diff --git a/pkgs/tools/typesetting/tex/texlive/pkgs.nix b/pkgs/tools/typesetting/tex/texlive/pkgs.nix
|
||||||
|
index 4d891c0758..09c413559f 100644
|
||||||
|
--- a/pkgs/tools/typesetting/tex/texlive/pkgs.nix
|
||||||
|
+++ b/pkgs/tools/typesetting/tex/texlive/pkgs.nix
|
||||||
|
@@ -5713,6 +5713,7 @@ tl: { # no indentation
|
||||||
|
deps."fundus-calligra" = tl."fundus-calligra";
|
||||||
|
deps."fundus-cyr" = tl."fundus-cyr";
|
||||||
|
deps."fundus-sueterlin" = tl."fundus-sueterlin";
|
||||||
|
+ deps."fvextra" = tl."fvextra";
|
||||||
|
deps."fwlw" = tl."fwlw";
|
||||||
|
deps."g-brief" = tl."g-brief";
|
||||||
|
deps."gauss" = tl."gauss";
|
||||||
|
@@ -16203,13 +16204,24 @@ tl: { # no indentation
|
||||||
|
hasRunfiles = true;
|
||||||
|
version = "1.1";
|
||||||
|
};
|
||||||
|
+"fvextra" = {
|
||||||
|
+ stripPrefix = 0;
|
||||||
|
+ sha512.run = "3526c3656124b15217161792f14f914dad2ec84af7ffd85f95654701c82e3be6bde304df0ca1ba8b4eb943122e731fe7c059a0d8ba7554f49a5401be6b709d8a";
|
||||||
|
+ sha512.doc = "919cff94f930cb624723fdca66033df39fee4dfe391df4ec592ded2a5c9ae59a9f29594ebdb09c9d9e54b5afc9dd77591258155530aa7c8fc45361b8dc31e8c3";
|
||||||
|
+ sha512.source = "934d419ca8e4c748f0d7d41f520abd07df4682295c6eef3390b9d2d628469d0d84ff7ffb707f1ee70b83b0fdf42b16ad9ad350c4b5166b28117543dde9d7d049";
|
||||||
|
+ urlPrefix = "http://213.136.89.14/texlive-mirror";
|
||||||
|
+ hasRunfiles = true;
|
||||||
|
+ version = "1.3.1";
|
||||||
|
+};
|
||||||
|
"minted" = {
|
||||||
|
+ deps."fvextra" = tl."fvextra";
|
||||||
|
stripPrefix = 0;
|
||||||
|
- sha512.run = "";
|
||||||
|
- sha512.doc = "";
|
||||||
|
- sha512.source = "";
|
||||||
|
+ sha512.run = "6bfff77120a70214f492f34b31bc7354f75173e742b0d40b76116e78f18d471946175e7cae1d51d0f2b948bf566c8e44c755f1d98a338b8a0b1b0cfb6b77f462";
|
||||||
|
+ sha512.doc = "013bab6a7abfff35d5316ec335ddb13e8c91e918ef78d9e49bc393be3cc6e71f22c740ff862045a5d20bbfc1a508bbc272f0dbc668db3ffc657dafb0ddfbc45c";
|
||||||
|
+ sha512.source = "3ae1e00adeff4ff117be3c35120d0c94569f62c7e4b6c8640236fbd52a9ceb20fce24b87faf0d5cc2b9295fd5a3689cda5eb01dc2c3897e8a2f228326ae6cdb6";
|
||||||
|
+ urlPrefix = "http://213.136.89.14/texlive-mirror";
|
||||||
|
hasRunfiles = true;
|
||||||
|
- version = "2.2.1";
|
||||||
|
+ version = "2.5";
|
||||||
|
};
|
||||||
|
"mintspirit" = {
|
||||||
|
stripPrefix = 0;
|
||||||
|
|
@ -1,35 +0,0 @@
|
||||||
---
|
|
||||||
- vars:
|
|
||||||
author: Sysadmin42
|
|
||||||
name: nginx-production
|
|
||||||
version: 1.7.6-p1
|
|
||||||
|
|
||||||
- package:
|
|
||||||
type: embedded
|
|
||||||
path: ./pkgs/nginx
|
|
||||||
|
|
||||||
- sync:
|
|
||||||
src: ./files/nginx.conf
|
|
||||||
dest: /etc/nginx/nginx.conf
|
|
||||||
recursive: True
|
|
||||||
chmod: 0644
|
|
||||||
|
|
||||||
- image:
|
|
||||||
type: aci
|
|
||||||
content: |
|
|
||||||
{
|
|
||||||
"acKind": "ImageManifest",
|
|
||||||
"acVersion": "0.6.1",
|
|
||||||
"name": "{{ name }}-{{ version }}",
|
|
||||||
"labels": [
|
|
||||||
{"name": "os", "value": "linux"},
|
|
||||||
{"name": "arch", "value": "amd64"}
|
|
||||||
],
|
|
||||||
"app": {
|
|
||||||
"exec": [
|
|
||||||
"/sbin/nginx"
|
|
||||||
],
|
|
||||||
"user": "0",
|
|
||||||
"group": "0"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
DUMMY
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
DUMMY
|
|
||||||
|
|
@ -1,10 +0,0 @@
|
||||||
---
|
|
||||||
base: www-servers/nginx-1.7.6
|
|
||||||
author: Sysadmin42 <sys@admin42.org>
|
|
||||||
patches:
|
|
||||||
patches/https-only.patch: "This patch denies all plain http requests"
|
|
||||||
https://github.com/nginx/nginx/commit/52e4dc2f74fd032dace01acbe5eb29ddf7c1ad96.patch: "Fix buffer overruns"
|
|
||||||
use:
|
|
||||||
with:
|
|
||||||
- ipv6
|
|
||||||
- selinux
|
|
||||||
170
shell.nix
170
shell.nix
|
|
@ -1,49 +1,30 @@
|
||||||
let
|
let
|
||||||
nixpkgs = import <nixpkgs> {};
|
nixpkgs = import <nixpkgs> {};
|
||||||
pkgsSrc = nixpkgs.pkgs.fetchFromGitHub {
|
patchedPkgsSrc = nixpkgs.stdenv.mkDerivation {
|
||||||
|
name = "patchedPkgsSrc";
|
||||||
|
src = nixpkgs.pkgs.fetchFromGitHub {
|
||||||
owner = "nixos";
|
owner = "nixos";
|
||||||
repo = "nixpkgs-channels";
|
repo = "nixpkgs-channels";
|
||||||
rev = "adfcc2d9531e78bf6a9e3b56e2f4fc873cb3d87b";
|
rev = "81fceb255448415e70b9e7775d590b6def45f861";
|
||||||
sha256 = "101mh6gb9wlx0lq5pw2m0n1fi3h2pag3ndg184rrqzvn9ynp28iw";
|
sha256 = "0sfx21b9rb6qxjm7li3krk6ik0xxph1il7r5l69n8b9agp72yjfx";
|
||||||
|
# rev = "1b1fc6550559f9d73ddf7cea611c387a847bf03b";
|
||||||
|
# sha256 = "0gipwxghvwnv2n7csp8ks3l2g1z7hwqn96bljikkm7p8jjpfb5ds";
|
||||||
};
|
};
|
||||||
pkgs = import pkgsSrc {};
|
patches = [
|
||||||
|
#./build/texlive-url-mirror.patch
|
||||||
eqexam.pkgs = [
|
./build/update-minted-2.5.patch
|
||||||
(pkgs.stdenv.mkDerivation rec {
|
|
||||||
version = "2012-05-17";
|
|
||||||
pname = "eqexam";
|
|
||||||
name = "${pname}-${version}";
|
|
||||||
tlType = "run";
|
|
||||||
|
|
||||||
src = pkgs.fetchurl {
|
|
||||||
url = "http://www.math.uakron.edu/~dpstory/eqexam/eqexam_pack.zip";
|
|
||||||
sha256 = "0g4w9ma6cr277li5b8dps9fm9jkjlwzwjc6ix01mw4kva4h5fdrj";
|
|
||||||
};
|
|
||||||
|
|
||||||
buildInputs = [ pkgs.unzip pkgs.texlive.combined.scheme-basic ];
|
|
||||||
|
|
||||||
buildPhase = "
|
|
||||||
latex eqexam.ins
|
|
||||||
";
|
|
||||||
|
|
||||||
installPhase = "
|
|
||||||
mkdir -p $out/tex/latex/eqexam
|
|
||||||
cp -va *.sty *.cfg *.def $out/tex/latex/eqexam
|
|
||||||
|
|
||||||
mkdir -p $out/doc/latex/eqexam
|
|
||||||
cp -va doc/* $out/doc/latex/eqexam
|
|
||||||
";
|
|
||||||
|
|
||||||
meta = {
|
|
||||||
branch = "3";
|
|
||||||
platforms = pkgs.stdenv.lib.platforms.unix;
|
|
||||||
};
|
|
||||||
})
|
|
||||||
];
|
];
|
||||||
|
buildPhase = "";
|
||||||
|
installPhase = ''
|
||||||
|
cp -a . $out
|
||||||
|
'';
|
||||||
|
fixupPhase = "true";
|
||||||
|
postFixup = "true";
|
||||||
|
};
|
||||||
|
pkgs = import patchedPkgsSrc {};
|
||||||
|
|
||||||
mytexlive = (pkgs.texlive.combine {
|
mytexlive = (pkgs.texlive.combine {
|
||||||
inherit (pkgs.texlive) scheme-full;
|
inherit (pkgs.texlive) scheme-full minted pygmentex fvextra;
|
||||||
inherit eqexam;
|
|
||||||
});
|
});
|
||||||
|
|
||||||
in pkgs.stdenv.mkDerivation {
|
in pkgs.stdenv.mkDerivation {
|
||||||
|
|
@ -53,7 +34,8 @@ in pkgs.stdenv.mkDerivation {
|
||||||
$PWD/src/docs/thesis.tex \
|
$PWD/src/docs/thesis.tex \
|
||||||
$PWD/src/docs/glossary.tex \
|
$PWD/src/docs/glossary.tex \
|
||||||
$PWD/src/docs/parts/context/context.tex \
|
$PWD/src/docs/parts/context/context.tex \
|
||||||
$PWD/src/docs/parts/research/research.tex \
|
$PWD/src/docs/parts/research_and_development/research_and_development.tex \
|
||||||
|
$PWD/src/docs/parts/eval_and_conclusion/eval_and_conclusion.tex \
|
||||||
"
|
"
|
||||||
'';
|
'';
|
||||||
buildInputs = [
|
buildInputs = [
|
||||||
|
|
@ -61,109 +43,9 @@ in pkgs.stdenv.mkDerivation {
|
||||||
(pkgs.vim_configurable.customize {
|
(pkgs.vim_configurable.customize {
|
||||||
name = "vim";
|
name = "vim";
|
||||||
vimrcConfig = {
|
vimrcConfig = {
|
||||||
# add custom .vimrc lines like this:
|
|
||||||
customRC = ''
|
customRC = ''
|
||||||
set nocompatible
|
source .vimrc
|
||||||
|
|
||||||
" leader
|
|
||||||
let mapleader = ','
|
|
||||||
|
|
||||||
set hidden
|
|
||||||
syntax on
|
|
||||||
set hlsearch
|
|
||||||
set number
|
|
||||||
|
|
||||||
" mappings to stop insert mode
|
|
||||||
imap jjj <ESC>
|
|
||||||
imap kkk <ESC>
|
|
||||||
imap lll <ESC>
|
|
||||||
imap hhh <ESC>
|
|
||||||
set scroll=11
|
|
||||||
|
|
||||||
noremap <C-n> :tabn<CR>
|
|
||||||
noremap <C-p> :tabp<CR>
|
|
||||||
let g:ctrlp_map = '<tab>'
|
|
||||||
let g:ctrlp_custom_ignore = {
|
|
||||||
\ 'dir': '\v[\/]\.(git|hg|svn|)$$',
|
|
||||||
\ 'file': '\v\.(exe|so|dll|so|swp|zip|aux|log|fdb_latexmk|fdb|dvi|lof|lot|pdf|fls|toc|gz|latexmain)$$',
|
|
||||||
\ }
|
|
||||||
|
|
||||||
" allways show status line
|
|
||||||
set ls=2
|
|
||||||
set tabstop=4
|
|
||||||
set shiftwidth=4
|
|
||||||
set softtabstop=4
|
|
||||||
set expandtab
|
|
||||||
"set textwidth=80
|
|
||||||
|
|
||||||
" sync default register to clipboard {
|
|
||||||
if has('unnamedplus')
|
|
||||||
set clipboard=unnamedplus
|
|
||||||
else
|
|
||||||
set clipboard=unnamed
|
|
||||||
endif
|
|
||||||
" }
|
|
||||||
|
|
||||||
" colored brackets {
|
|
||||||
let g:rbpt_colorpairs = [
|
|
||||||
\ ['brown', 'RoyalBlue3'],
|
|
||||||
\ ['Darkblue', 'SeaGreen3'],
|
|
||||||
\ ['darkgray', 'DarkOrchid3'],
|
|
||||||
\ ['darkgreen', 'firebrick3'],
|
|
||||||
\ ['darkcyan', 'RoyalBlue3'],
|
|
||||||
\ ['darkred', 'SeaGreen3'],
|
|
||||||
\ ['darkmagenta', 'DarkOrchid3'],
|
|
||||||
\ ['brown', 'firebrick3'],
|
|
||||||
\ ['gray', 'RoyalBlue3'],
|
|
||||||
\ ['black', 'SeaGreen3'],
|
|
||||||
\ ['darkmagenta', 'DarkOrchid3'],
|
|
||||||
\ ['Darkblue', 'firebrick3'],
|
|
||||||
\ ['darkgreen', 'RoyalBlue3'],
|
|
||||||
\ ['darkcyan', 'SeaGreen3'],
|
|
||||||
\ ['darkred', 'DarkOrchid3'],
|
|
||||||
\ ['red', 'firebrick3'],
|
|
||||||
\ ]
|
|
||||||
let g:rbpt_max = 16
|
|
||||||
let g:rbpt_loadcmd_toggle = 0
|
|
||||||
|
|
||||||
au VimEnter * RainbowParenthesesToggle
|
|
||||||
au Syntax * RainbowParenthesesLoadRound
|
|
||||||
au Syntax * RainbowParenthesesLoadSquare
|
|
||||||
au Syntax * RainbowParenthesesLoadBraces
|
|
||||||
" }
|
|
||||||
set backspace=indent,eol,start
|
|
||||||
colorscheme PaperColor
|
|
||||||
|
|
||||||
" Latex Related {{{
|
|
||||||
au BufRead,BufNewFile *.tex,*.md,*.markdown setlocal spell spelllang=en_us
|
|
||||||
|
|
||||||
let g:vimtex_view_method = 'zathura'
|
|
||||||
|
|
||||||
let g:vimtex_complete_enabled = 1
|
|
||||||
let g:vimtex_complete_close_braces = 1
|
|
||||||
let g:vimtex_complete_recursive_bib = 1
|
|
||||||
let g:vimtex_indent_enabled = 1
|
|
||||||
let g:vimtex_indent_bib_enabled = 1
|
|
||||||
|
|
||||||
if !exists('g:ycm_semantic_triggers')
|
|
||||||
let g:ycm_semantic_triggers = {}
|
|
||||||
endif
|
|
||||||
let g:ycm_semantic_triggers.tex = [
|
|
||||||
\ 're!\\[A-Za-z]*cite[A-Za-z]*(\[[^]]*\]){0,2}{[^}]*',
|
|
||||||
\ 're!\\[A-Za-z]*ref({[^}]*|range{([^,{}]*(}{)?))',
|
|
||||||
\ 're!\\hyperref\[[^]]*',
|
|
||||||
\ 're!\\includegraphics\*?(\[[^]]*\]){0,2}{[^}]*',
|
|
||||||
\ 're!\\(include(only)?|input){[^}]*',
|
|
||||||
\ 're!\\\a*(gls|Gls|GLS)(pl)?\a*(\s*\[[^]]*\]){0,2}\s*\{[^}]*',
|
|
||||||
\ 're!\\includepdf(\s*\[[^]]*\])?\s*\{[^}]*',
|
|
||||||
\ 're!\\includestandalone(\s*\[[^]]*\])?\s*\{[^}]*',
|
|
||||||
\ ]
|
|
||||||
|
|
||||||
function! ViewerCallback() dict
|
|
||||||
call self.forward_search(self.out)
|
|
||||||
endfunction
|
|
||||||
let g:vimtex_view_zathura_hook_callback = 'ViewerCallback'
|
|
||||||
" }}}
|
|
||||||
'';
|
'';
|
||||||
|
|
||||||
vam.knownPlugins = pkgs.vimPlugins;
|
vam.knownPlugins = pkgs.vimPlugins;
|
||||||
|
|
@ -179,7 +61,13 @@ in pkgs.stdenv.mkDerivation {
|
||||||
];
|
];
|
||||||
};
|
};
|
||||||
})
|
})
|
||||||
|
pkgs.bashInteractive
|
||||||
|
|
||||||
mytexlive
|
mytexlive
|
||||||
|
pkgs.biber
|
||||||
|
pkgs.pygmentex
|
||||||
|
pkgs.python27Packages.pygments-markdown-lexer
|
||||||
|
|
||||||
pkgs.zathura
|
pkgs.zathura
|
||||||
];
|
];
|
||||||
}
|
}
|
||||||
|
|
|
||||||
12
src/code/llc-arglist/arglist.cc
Normal file
12
src/code/llc-arglist/arglist.cc
Normal file
|
|
@ -0,0 +1,12 @@
|
||||||
|
#include "llvm/Support/CommandLine.h"
|
||||||
|
|
||||||
|
using namespace llvm;
|
||||||
|
|
||||||
|
/*
|
||||||
|
* Call with `--help-list-hidden` as argument to get a full list
|
||||||
|
*/
|
||||||
|
int main(int argc, char** argv) {
|
||||||
|
cl::ParseCommandLineOptions(argc, argv, "");
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
2
src/code/llc-arglist/run.sh
Executable file
2
src/code/llc-arglist/run.sh
Executable file
|
|
@ -0,0 +1,2 @@
|
||||||
|
g++ arglist.cc -o arglist -std=gnu++11 -lLLVM-4.0.1
|
||||||
|
./arglist --help-list-hidden
|
||||||
27
src/code/stack_handling.c/makefile
Normal file
27
src/code/stack_handling.c/makefile
Normal file
|
|
@ -0,0 +1,27 @@
|
||||||
|
TARGET = stack_handling
|
||||||
|
LIBS =
|
||||||
|
CC = gcc
|
||||||
|
CFLAGS = -Wall -fomit-frame-pointer -fstack-check #-fsanitize=address
|
||||||
|
|
||||||
|
.PHONY: default all clean
|
||||||
|
|
||||||
|
default: $(TARGET)
|
||||||
|
all: default objdump
|
||||||
|
|
||||||
|
OBJECTS = $(patsubst %.c, %.o, $(wildcard *.c))
|
||||||
|
HEADERS = $(wildcard *.h)GG
|
||||||
|
|
||||||
|
%.o: %.c $(HEADERS)
|
||||||
|
$(CC) $(CFLAGS) -c $< -o $@
|
||||||
|
|
||||||
|
.PRECIOUS: $(TARGET) $(OBJECTS)
|
||||||
|
|
||||||
|
$(TARGET): $(OBJECTS)
|
||||||
|
$(CC) $(OBJECTS) $(CFLAGS) $(LIBS) -o $@
|
||||||
|
|
||||||
|
clean:
|
||||||
|
-rm -f *.o
|
||||||
|
-rm -f $(TARGET)
|
||||||
|
|
||||||
|
objdump: $(TARGET)
|
||||||
|
objdump --no-show-raw-insn --disassembler-options=intel-nmemonic -d $(TARGET) > $@
|
||||||
84
src/code/stack_handling.c/stack_handling.c
Normal file
84
src/code/stack_handling.c/stack_handling.c
Normal file
|
|
@ -0,0 +1,84 @@
|
||||||
|
#include <inttypes.h>
|
||||||
|
#include <stdio.h>
|
||||||
|
|
||||||
|
static int64_t passthrough(int64_t a) { return a; }
|
||||||
|
|
||||||
|
static int64_t neg(int64_t a) { return -a; }
|
||||||
|
|
||||||
|
static int64_t neg_extravar(int64_t a) {
|
||||||
|
int64_t neg = -a;
|
||||||
|
return neg;
|
||||||
|
}
|
||||||
|
|
||||||
|
static int64_t rec_many_args(int64_t rdi, int64_t rsi, int64_t rdx, int64_t rcx,
|
||||||
|
int64_t r8, int64_t r9, int64_t s1) {
|
||||||
|
if (s1 == INT64_MIN) {
|
||||||
|
return INT64_MIN;
|
||||||
|
} else {
|
||||||
|
return rec_many_args(rdi, rsi, rdx, rcx, r8, r9, s1 - 1);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
static int64_t many_args(int64_t rdi, int64_t rsi, int64_t rdx, int64_t rcx,
|
||||||
|
int64_t r8, int64_t r9, int64_t s1) {
|
||||||
|
|
||||||
|
int64_t s2 =
|
||||||
|
rec_many_args(0xfffffffffffffff0, 0xfffffffffffffff1, 0xfffffffffffffff3,
|
||||||
|
0xfffffffffffffff4, 0xfffffffffffffff5, 0xfffffffffffffff6,
|
||||||
|
INT64_MIN + 80000);
|
||||||
|
return s2;
|
||||||
|
}
|
||||||
|
|
||||||
|
static void printer(int64_t *a, int64_t *b) {
|
||||||
|
fprintf(stdout, "%" PRId64 " = -%" PRId64 "\n", *a, *b);
|
||||||
|
}
|
||||||
|
|
||||||
|
static void caller(void) {
|
||||||
|
int64_t a = passthrough(INT64_MAX);
|
||||||
|
int64_t b = neg(a);
|
||||||
|
printer(&a, &b);
|
||||||
|
}
|
||||||
|
|
||||||
|
static int *grow_stack(int size) {
|
||||||
|
int a[size];
|
||||||
|
for (int i = 0; i < size; i++) {
|
||||||
|
a[i] = 0;
|
||||||
|
}
|
||||||
|
return a;
|
||||||
|
}
|
||||||
|
|
||||||
|
static int64_t *large_stack() {
|
||||||
|
uint64_t a[100000000];
|
||||||
|
return a;
|
||||||
|
}
|
||||||
|
|
||||||
|
static void simple_printer(void) { fprintf(stderr, "I wonder who called me?"); }
|
||||||
|
|
||||||
|
static void modifier(void) {
|
||||||
|
uint64_t *p;
|
||||||
|
// without frame-pointer
|
||||||
|
// *(&p + 1) = (uint64_t *)simple_printer;
|
||||||
|
|
||||||
|
// with frame-pointer
|
||||||
|
*(&p + 2) = (uint64_t *)simple_printer;
|
||||||
|
}
|
||||||
|
|
||||||
|
static void modifier_indexed(uint64_t *p) {
|
||||||
|
// without frame-pointer
|
||||||
|
(&p)[1] = (uint64_t *)simple_printer;
|
||||||
|
|
||||||
|
// with frame-pointer
|
||||||
|
(&p)[2] = (uint64_t *)simple_printer;
|
||||||
|
}
|
||||||
|
|
||||||
|
int main(void) {
|
||||||
|
// caller();
|
||||||
|
// many_args(0xfffffffffffffff0, 0xfffffffffffffff1, 0xfffffffffffffff3,
|
||||||
|
// 0xfffffffffffffff4, 0xfffffffffffffff5, 0xfffffffffffffff6,
|
||||||
|
// 0xfffffffffffffff7);
|
||||||
|
// modifier_indexed(NULL);
|
||||||
|
// modifier();
|
||||||
|
large_stack();
|
||||||
|
fprintf(stderr, "main exiting");
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
4
src/code/stack_handling.rs/Cargo.lock
generated
Normal file
4
src/code/stack_handling.rs/Cargo.lock
generated
Normal file
|
|
@ -0,0 +1,4 @@
|
||||||
|
[root]
|
||||||
|
name = "stack_handling"
|
||||||
|
version = "0.1.0"
|
||||||
|
|
||||||
13
src/code/stack_handling.rs/Cargo.toml
Normal file
13
src/code/stack_handling.rs/Cargo.toml
Normal file
|
|
@ -0,0 +1,13 @@
|
||||||
|
[package]
|
||||||
|
name = "stack_handling"
|
||||||
|
version = "0.1.0"
|
||||||
|
authors = ["Stefan Junker <mail@stefanjunker.de>"]
|
||||||
|
build = "build.rs"
|
||||||
|
|
||||||
|
[dependencies]
|
||||||
|
|
||||||
|
[profile.dev]
|
||||||
|
panic = "abort"
|
||||||
|
|
||||||
|
[profile.release]
|
||||||
|
panic = "abort"
|
||||||
10
src/code/stack_handling.rs/build.rs
Normal file
10
src/code/stack_handling.rs/build.rs
Normal file
|
|
@ -0,0 +1,10 @@
|
||||||
|
// build.rs
|
||||||
|
|
||||||
|
use std::env;
|
||||||
|
use std::fs::File;
|
||||||
|
use std::io::Write;
|
||||||
|
use std::path::Path;
|
||||||
|
|
||||||
|
fn main() {
|
||||||
|
println!("build.rs ran");
|
||||||
|
}
|
||||||
84
src/code/stack_handling.rs/src/main.rs
Normal file
84
src/code/stack_handling.rs/src/main.rs
Normal file
|
|
@ -0,0 +1,84 @@
|
||||||
|
#![feature(naked_functions)]
|
||||||
|
#![deny(unconditional_recursion)]
|
||||||
|
|
||||||
|
// #[derive(Debug)]
|
||||||
|
// struct Stat {
|
||||||
|
// sum: isize,
|
||||||
|
// count: isize,
|
||||||
|
// avg: isize,
|
||||||
|
// min: isize,
|
||||||
|
// max: isize,
|
||||||
|
// }
|
||||||
|
//
|
||||||
|
// macro_rules! sum {
|
||||||
|
// () => (0);
|
||||||
|
// ($e:expr) => ( $e );
|
||||||
|
// ($head:expr, $($tail:expr),*) => { $head + sum!($($tail),*)};
|
||||||
|
// }
|
||||||
|
//
|
||||||
|
// macro_rules! count {
|
||||||
|
// () => (0);
|
||||||
|
// ($e:expr) => ( 1 );
|
||||||
|
// ($head:expr, $($tail:expr),*) => { 1 + count!($($tail),*) };
|
||||||
|
// }
|
||||||
|
//
|
||||||
|
// #[inline(never)]
|
||||||
|
// fn push(a: isize, b: isize, c: isize) -> isize {
|
||||||
|
// sum!(a, b, c)
|
||||||
|
// }
|
||||||
|
//
|
||||||
|
// macro_rules! avg{
|
||||||
|
// ($($all:expr),+) => {
|
||||||
|
// sum!($($all),+) / count!($($all),+)
|
||||||
|
// };
|
||||||
|
// }
|
||||||
|
//
|
||||||
|
// macro_rules! max {
|
||||||
|
// ($x:expr) => ( $x );
|
||||||
|
// ($x:expr, $($xs:expr),+) => {
|
||||||
|
// {
|
||||||
|
// use std::cmp::max;
|
||||||
|
// max($x, max!( $($xs),+ ))
|
||||||
|
// }
|
||||||
|
// };
|
||||||
|
// }
|
||||||
|
//
|
||||||
|
// macro_rules! min {
|
||||||
|
// ($x:expr) => ( $x );
|
||||||
|
// ($x:expr, $($xs:expr),+) => {
|
||||||
|
// {
|
||||||
|
// use std::cmp::min;
|
||||||
|
// min($x, min!( $($xs),+ ))
|
||||||
|
// }
|
||||||
|
// };
|
||||||
|
// }
|
||||||
|
// #[inline(never)]
|
||||||
|
// fn stats(a: isize, b: isize, c: isize) -> Stat {
|
||||||
|
// let sum = sum(a, b, c);
|
||||||
|
// let count = count!(a, b, c);
|
||||||
|
// let avg = avg!(a, b, c);
|
||||||
|
// let min = min!(a, b, c);
|
||||||
|
// let max = max!(a, b, c);
|
||||||
|
// Stat {
|
||||||
|
// sum,
|
||||||
|
// count,
|
||||||
|
// avg,
|
||||||
|
// min,
|
||||||
|
// max,
|
||||||
|
// }
|
||||||
|
// }
|
||||||
|
//
|
||||||
|
// #[inline(never)]
|
||||||
|
// fn sum(a: isize, b: isize, c: isize) -> isize {
|
||||||
|
// sum!(a, b, c)
|
||||||
|
// }
|
||||||
|
#[inline(never)]
|
||||||
|
fn passthrough(a: isize) -> isize {
|
||||||
|
let b = a;
|
||||||
|
b
|
||||||
|
}
|
||||||
|
|
||||||
|
#[inline(never)]
|
||||||
|
fn r();
|
||||||
|
println!("main exiting")
|
||||||
|
}
|
||||||
|
|
@ -1,3 +1,4 @@
|
||||||
|
% // vim: set ft=tex:
|
||||||
\begin{center}
|
\begin{center}
|
||||||
{\Large \textbf{Abstract}}
|
{\Large \textbf{Abstract}}
|
||||||
\end{center}
|
\end{center}
|
||||||
|
|
@ -13,9 +14,9 @@
|
||||||
Supervisors: & \supervisorOne \\[.5ex]
|
Supervisors: & \supervisorOne \\[.5ex]
|
||||||
& \supervisorTwo\\
|
& \supervisorTwo\\
|
||||||
& \\
|
& \\
|
||||||
Submition: & \submitdate \\
|
Submission: & \submitdate \\
|
||||||
& \\
|
& \\
|
||||||
Buzzwords: & \buzzwords \\
|
Categories: & \buzzwords \\
|
||||||
& \\
|
& \\
|
||||||
\end{tabular}
|
\end{tabular}
|
||||||
\end{center}
|
\end{center}
|
||||||
|
|
@ -23,4 +24,4 @@
|
||||||
\bigskip
|
\bigskip
|
||||||
|
|
||||||
\noindent
|
\noindent
|
||||||
TODO: abstract goes here
|
\abstract
|
||||||
|
|
|
||||||
26
src/docs/affidavit.tex
Normal file
26
src/docs/affidavit.tex
Normal file
|
|
@ -0,0 +1,26 @@
|
||||||
|
% // vim: set ft=tex:
|
||||||
|
|
||||||
|
\chapter*{Ehrenwörtliche Erklärung}
|
||||||
|
|
||||||
|
Hiermit erkläre ich, {\authorOne}, geboren am {\authorOneBirthDate} in {\authorOneBirthCity},
|
||||||
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item{
|
||||||
|
dass ich meine Masterarbeit mit dem Titel:
|
||||||
|
|
||||||
|
{"\topic"}
|
||||||
|
|
||||||
|
in der Fakultät Informatik unter Anleitung von Professor {\supervisorOne} und ohne fremde Hilfe angefertigt habe und keine anderen als die angeführten Hilfen benutzt habe;
|
||||||
|
}
|
||||||
|
\item{
|
||||||
|
dass ich die Übernahme wörtlicher Zitate, von Tabellen, Zeichnungen, Bildern und Programmen aus der Literatur oder anderen Quellen (Internet) sowie die Verwendung der Gedanken anderer Autoren an den entsprechenden Stellen innerhalb der Arbeit gekennzeichnet habe;
|
||||||
|
}
|
||||||
|
\item{
|
||||||
|
dass die eingereichten Abgabe-Exemplare in Papierform und im PDF-Format vollständig übereinstimmen.
|
||||||
|
}
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird.
|
||||||
|
|
||||||
|
\vspace{4cm}
|
||||||
|
Konstanz, 29.9.2017\hspace{5cm} \authorOne
|
||||||
26
src/docs/cover.tex
Normal file
26
src/docs/cover.tex
Normal file
|
|
@ -0,0 +1,26 @@
|
||||||
|
\begin{titlepage}
|
||||||
|
|
||||||
|
\vspace*{-1.0cm}
|
||||||
|
|
||||||
|
\begin{centering}
|
||||||
|
\includegraphics[width=\textwidth]{gfx/htwg-logo.pdf}
|
||||||
|
\end{centering}
|
||||||
|
|
||||||
|
\vspace{1.5cm}
|
||||||
|
|
||||||
|
\begin{center}
|
||||||
|
\huge{
|
||||||
|
\textbf{\topic} \\[4cm]
|
||||||
|
}
|
||||||
|
\Large{
|
||||||
|
\textbf{\authorOne}} \\[5.5cm]
|
||||||
|
\large{
|
||||||
|
\textbf{Konstanz, \submitdate} \\[2.3cm]
|
||||||
|
}
|
||||||
|
|
||||||
|
\Huge{
|
||||||
|
\textbf{{\textsf Masterarbeit}}
|
||||||
|
}
|
||||||
|
\end{center}
|
||||||
|
|
||||||
|
\end{titlepage}
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
BIN
src/docs/gfx/Relative-Vulnerability-Type-Totals-By-Year.png
Normal file
BIN
src/docs/gfx/Relative-Vulnerability-Type-Totals-By-Year.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
BIN
src/docs/gfx/TODO-Callstacklayout.png
Normal file
BIN
src/docs/gfx/TODO-Callstacklayout.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
61
src/docs/gfx/TODO-Callstacklayout.svg
Normal file
61
src/docs/gfx/TODO-Callstacklayout.svg
Normal file
|
|
@ -0,0 +1,61 @@
|
||||||
|
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||||
|
<svg xmlns="http://www.w3.org/2000/svg" height="558px" width="684px" viewBox="0 0 21590 27940">
|
||||||
|
<defs>
|
||||||
|
<linearGradient id="a" gradientUnits="userSpaceOnUse" x2="0" y2="24400" y1="26700">
|
||||||
|
<stop stop-color="#fff" offset="0"/>
|
||||||
|
<stop stop-color="#adf" offset="1"/>
|
||||||
|
</linearGradient>
|
||||||
|
</defs>
|
||||||
|
<rect height="27940" width="34250" x="-6330" fill="#fff"/>
|
||||||
|
<g stroke="#000" stroke-width="61">
|
||||||
|
<g fill="#afc">
|
||||||
|
<path d="m6370 8620v-6430h12300v6430"/>
|
||||||
|
<path d="m6370 10400v-1760h12300v1760"/>
|
||||||
|
<path d="m6370 14500v-4090h12300v4090"/>
|
||||||
|
</g>
|
||||||
|
<path d="m6370 26700v-2340h12300v2340" fill="url(#a)"/>
|
||||||
|
<g fill="#adf">
|
||||||
|
<path d="m6370 19700v-1760h12300v1760"/>
|
||||||
|
<path d="m18670 19700v4720h-12300v-4720z"/>
|
||||||
|
<path d="m6370 17900v-3510h12300v3510"/>
|
||||||
|
</g>
|
||||||
|
<g fill="none">
|
||||||
|
<path d="m5780 24400-120-9.5-111-47-98-75.9-85-107-73-120-50.6-139-37.9-155-12.6-174v-3310l-9.5-168-34.8-161-53.7-133-66-120-88-101-95-82-111-47-123-15.8 123-9.5 111-50.6 95-69 89-111 66-123 53.7-133 34.8-158 9.5-174v-3300l12.6-171 37.9-161 50.6-133 73-120 85-98 98-85 111-47 120-12.6"/>
|
||||||
|
<path d="m19200 2190 120 22 111 63 98 85 85 133 73 145 50.6 183 37.9 180 9.5 209v4090l9.5 205 41 196 47 171 75.9 145 82 133 95 85 111 60 126 25.3-126 25.3-111 60-95 85-82 133-75.9 145-47 180-41 183-9.5 209v4080l-9.5 209-37.9 196-50.6 168-73 149-85 133-98 85-111 63-120 22"/>
|
||||||
|
</g>
|
||||||
|
<path d="m1810 2190h3470"/>
|
||||||
|
<path d="m1850 8640h3470"/>
|
||||||
|
</g>
|
||||||
|
<path d="m12400 26000h188v202h-188v-202m0-582h188v202h-188v-202m0-585h188v202h-188v-202"/>
|
||||||
|
<path d="m5030 2570 752-389-752-376 231 376-231 389"/>
|
||||||
|
<path d="m5070 9040 752-389-752-376 231 376-231 389"/>
|
||||||
|
<g style="font-family:Arial,sans-serif;text-align:center;text-anchor:middle;font-size:1200px">
|
||||||
|
<g font-size="1380px">
|
||||||
|
<text y="21607" x="12468">Parameters for</text>
|
||||||
|
<text y="23238" x="12501">DrawSquare</text>
|
||||||
|
<text y="15768" x="12455">Locals of</text>
|
||||||
|
<text y="17399" x="12501">DrawSquare</text>
|
||||||
|
<text y="19211" x="12498">Return Address</text>
|
||||||
|
<text y="11972" x="12468">Parameters for</text>
|
||||||
|
<text y="13606" x="12500">DrawLine</text>
|
||||||
|
<text y="4974" x="12455">Locals of</text>
|
||||||
|
<text y="6602" x="12500">DrawLine</text>
|
||||||
|
<text y="9870" x="12498">Return Address</text>
|
||||||
|
</g>
|
||||||
|
<text y="6464" x="27050">
|
||||||
|
<tspan y="6464" x="23984">stack frame</tspan>
|
||||||
|
<tspan y="7961" x="23984">for</tspan>
|
||||||
|
<tspan y="9458" x="23984">DrawLine</tspan>
|
||||||
|
<tspan y="10955" x="23984">subroutine</tspan>
|
||||||
|
</text>
|
||||||
|
<text y="17447" x="3865">
|
||||||
|
<tspan x="563">stack frame</tspan>
|
||||||
|
<tspan y="18944" x="563">for</tspan>
|
||||||
|
<tspan y="20440" x="563">DrawSquare</tspan>
|
||||||
|
<tspan y="21937" x="563">subroutine</tspan>
|
||||||
|
</text>
|
||||||
|
<text y="8919" x="-2242">Frame Pointer</text>
|
||||||
|
<text y="2468" x="-2081">Stack Pointer</text>
|
||||||
|
<text y="1860" x="12453">top of stack</text>
|
||||||
|
</g>
|
||||||
|
</svg>
|
||||||
|
After Width: | Height: | Size: 2.8 KiB |
BIN
src/docs/gfx/TODO-callstack-manipulation.png
Normal file
BIN
src/docs/gfx/TODO-callstack-manipulation.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 902 KiB |
BIN
src/docs/gfx/TODO-heap-stack-example-program.png
Normal file
BIN
src/docs/gfx/TODO-heap-stack-example-program.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
BIN
src/docs/gfx/TODO-nlevel-paging.jpg
Normal file
BIN
src/docs/gfx/TODO-nlevel-paging.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.5 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
BIN
src/docs/gfx/Vulnerability-Type-Change-by-Year-Legend.png
Normal file
BIN
src/docs/gfx/Vulnerability-Type-Change-by-Year-Legend.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
BIN
src/docs/gfx/Vulnerability-Type-Change-by-Year.png
Normal file
BIN
src/docs/gfx/Vulnerability-Type-Change-by-Year.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 70 KiB |
BIN
src/docs/gfx/amd64-2mb-page-translation-long-mode.png
Normal file
BIN
src/docs/gfx/amd64-2mb-page-translation-long-mode.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 89 KiB |
BIN
src/docs/gfx/amd64-4kb-page-translation-long-mode.png
Normal file
BIN
src/docs/gfx/amd64-4kb-page-translation-long-mode.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 79 KiB |
BIN
src/docs/gfx/amd64-long-mode-stack-after-interrupt.png
Normal file
BIN
src/docs/gfx/amd64-long-mode-stack-after-interrupt.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
BIN
src/docs/gfx/call-procedure-memory-content.png
Normal file
BIN
src/docs/gfx/call-procedure-memory-content.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 124 KiB |
BIN
src/docs/gfx/htwg-logo.pdf
Normal file
BIN
src/docs/gfx/htwg-logo.pdf
Normal file
Binary file not shown.
BIN
src/docs/gfx/llvm-number-paper-pa.png
Normal file
BIN
src/docs/gfx/llvm-number-paper-pa.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 8.3 KiB |
BIN
src/docs/gfx/qemu-stack-overflow.png
Normal file
BIN
src/docs/gfx/qemu-stack-overflow.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
BIN
src/docs/gfx/rust-compiler-flow.png
Normal file
BIN
src/docs/gfx/rust-compiler-flow.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
|
|
@ -1,133 +1,284 @@
|
||||||
% // vim: set ft=tex:
|
% // vim: set ft=tex:
|
||||||
|
|
||||||
\newglossaryentry{API}{
|
\newglossaryentry{bbox} {
|
||||||
name = API,
|
name = {busybox},
|
||||||
description = {
|
long = {BusyBox: The Swiss Army Knife of Embedded \gls{LX}},
|
||||||
Application Programming Interface
|
description = {%
|
||||||
|
BusyBox combines tiny versions of many common UNIX utilities into a single small executable%
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{bbox}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{Rust} {
|
||||||
|
name = {Rust},
|
||||||
|
long = {The Rust programming language},
|
||||||
|
description = {%
|
||||||
|
Statically typed programming language that uses a new concept of variable ownership and reference tracking. Largely explain in \cref{rnd::rust}.
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{Rust}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{rustc}{
|
||||||
|
name = rustc,
|
||||||
|
long = {The Rust compiler},
|
||||||
|
description = {%
|
||||||
|
This program is a compiler for the Rust language (man rustc).
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{rustc}},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{cargo} {
|
||||||
|
name = {cargo},
|
||||||
|
long = {The Rust package manager},
|
||||||
|
description = {%
|
||||||
|
This program is a package manager for the Rust language (man cargo).
|
||||||
|
It is also a wrapper for the Rust compiler.
|
||||||
|
It is also a management tool for Rust source code projects, and simplifies the initialization of project directories, the build of the source code and the run of the compiled binary.
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{Rust}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{xargo} {
|
||||||
|
name = {xcargo},
|
||||||
|
long = {The Cross-Compilation wrapper for cargo},
|
||||||
|
description = {%
|
||||||
|
Wrapper for cargo to simplify cross-compilation.
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{Rust}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{proglang} {
|
||||||
|
name = {programming language},
|
||||||
|
description = {%
|
||||||
|
A well-defined language used to write software. Hundreds of language exists, each with focus on different aspects like comfort for humans, size, speed, safety, etc.
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{OS}{
|
|
||||||
name = Operating System,
|
\newglossaryentry{compiler}{
|
||||||
description = {
|
name = compiler,
|
||||||
The software that manages the system's hardware ressources.
|
long = {source- to machine-code compiler},
|
||||||
Other \glspl{app} can access the ressources only through the interface provided by the \gls{OS}.
|
description = {%
|
||||||
|
A program that can transform software source code to executable machine code.
|
||||||
|
Typically targetted for a \glsentryname{proglang} or a family of \glspl{proglang}.
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{compiler}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{GCC}{
|
||||||
|
name = GCC,
|
||||||
|
long = {GNU Compiler Collection},
|
||||||
|
description = {%
|
||||||
|
GCC is an integrated distribution of compilers for several major programming languages.
|
||||||
|
These languages currently include C, C++, Objective-C, Objective-C++, Java, Fortran, Ada, and Go.
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{GCC}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{llvm}{
|
||||||
|
name = LLVM,
|
||||||
|
long = {Low Level Virtual Machine},
|
||||||
|
description = {%
|
||||||
|
A Virtual Instruction Set and Compilation Framework.
|
||||||
|
The key idea in LLVM is to use a rich virtual instruction set (instead of raw machine code) as the object code representation manipulated by link-time and post-link optimizers and code generators.\cite{Kowshik2002}.
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{clang}}
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
\newglossaryentry{clang}{
|
||||||
|
name = Clang,
|
||||||
|
long = {C Language frontendend for LLVM},
|
||||||
|
description = {%
|
||||||
|
The goal of the Clang project is to create a new C based language front-end: C, C++, Objective C/C++, OpenCL C and others for the LLVM compiler. You can get and build the source today.
|
||||||
|
\url{http://clang.llvm.org/}
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{clang}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{addrspace}{
|
||||||
|
name = address space,
|
||||||
|
long = bound address range in memory,
|
||||||
|
description = {%
|
||||||
|
A logical entity that represents a section of memory, specified with a start address and either by end address or length given in a standardize unit
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{addrspace}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{stack}{
|
||||||
|
name = stack,
|
||||||
|
description = {%
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{sf}{
|
||||||
|
name = stack-frame,
|
||||||
|
description = {%
|
||||||
|
Procedure data and meta-data (see \cref{lst:amd64-stack-frame-components})%
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{heap}{
|
||||||
|
name = heap,
|
||||||
|
description = {%
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{api}{
|
||||||
|
name = API,
|
||||||
|
long = {Application Programming Interface},
|
||||||
|
description = {%
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{api}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{os}{
|
||||||
|
name = OS,
|
||||||
|
long = Operating System,
|
||||||
|
description = {%
|
||||||
|
The software that manages the system's hardware ressources.
|
||||||
|
Other \glspl{app} can access the ressources only through the interface provided by the \gls{os}.
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{os}}
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
\newglossaryentry{fs}{
|
\newglossaryentry{fs}{
|
||||||
name = filesystem,
|
name = filesystem,
|
||||||
description = {
|
description = {%
|
||||||
TODO
|
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{virt}{
|
\newglossaryentry{virt}{
|
||||||
name = virtualization,
|
name = virtualization,
|
||||||
description = {
|
description = {%
|
||||||
TODO
|
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{OSS}{
|
\newglossaryentry{OSS}{
|
||||||
name = Open-Source Software,
|
name = Open-Source Software,
|
||||||
description = {
|
description = {%
|
||||||
TODO
|
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{osvirt}{
|
\newglossaryentry{osvirt}{
|
||||||
name = Operating System-Level Virtualization,
|
name = Operating System-Level Virtualization,
|
||||||
description = {
|
description = {%
|
||||||
TODO
|
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{hypervisor}{
|
\newglossaryentry{hypervisor}{
|
||||||
name = Hypervisor,
|
name = Hypervisor,
|
||||||
description = {
|
description = {%
|
||||||
TODO
|
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{VM}{
|
\newglossaryentry{VM}{
|
||||||
name = Virtual Machine,
|
name = Virtual Machine,
|
||||||
description = {
|
description = {%
|
||||||
TODO
|
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{Linux}{
|
\newglossaryentry{LX}{
|
||||||
name = Linux,
|
name = Linux,
|
||||||
description = {
|
description = {%
|
||||||
is a generic term referring to the family of Unix-like
|
is a generic term referring to the family of Unix-like
|
||||||
computer operating systems that use the Linux kernel
|
computer operating systems that use the Linux kernel
|
||||||
},
|
},
|
||||||
plural=Linuces
|
plural=Linuces
|
||||||
}
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{microkernel}{
|
||||||
|
name = microkernel,
|
||||||
|
description = {%
|
||||||
|
Kernel design that operates most drivers in userland, and only provides bare minimum functionality in kernel mode for glueing the drivers together.
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{android}{
|
||||||
|
name = Android,
|
||||||
|
description = {an open-source mobile \gls{os} based on \gls{LX}},
|
||||||
|
first = {\glsentryname{android}, \glsentrydesc{android}},
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
\newglossaryentry{imezzos}{
|
||||||
|
name = intermezzOS,
|
||||||
|
description = {%
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{redoxos}{
|
||||||
|
name = Redox OS,
|
||||||
|
description = {%
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{blogos}{
|
||||||
|
name = Blog OS,
|
||||||
|
description = {%
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{tockos}{
|
||||||
|
name = Tock OS,
|
||||||
|
description = {%
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
\newglossaryentry{rootfs}{
|
\newglossaryentry{rootfs}{
|
||||||
name = RootFS,
|
name = RootFS,
|
||||||
description = {
|
description = {%
|
||||||
% TODO
|
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{lxns}{
|
\newglossaryentry{lxns}{
|
||||||
name = Linux Namespace,
|
name = Linux Namespace,
|
||||||
description = {
|
description = {%
|
||||||
entitiy that holds a specific set of process attributes and can be set per process
|
entitiy that holds a specific set of process attributes and can be set per process
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{lxcap}{
|
\newglossaryentry{lxcap}{
|
||||||
name = Linux Capability,
|
name = Linux Capability,
|
||||||
description = {
|
description = {%
|
||||||
entitiy that holds a specific set of process attributes and can be set per process, mainly to establish a relationship between processes and \gls{OS} resources
|
entitiy that holds a specific set of process attributes and can be set per process, mainly to establish a relationship between processes and \gls{os} resources
|
||||||
},
|
},
|
||||||
plural = Linux Capabilities,
|
plural = Linux Capabilities,
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{lxvfs}{
|
\newglossaryentry{lxvfs}{
|
||||||
name = Linux VFS,
|
name = Linux VFS,
|
||||||
description = {
|
description = {%
|
||||||
Virtual Filesystem Switch, a filesystem abstraction layer in \gls{Linux}.
|
Virtual Filesystem Switch, a filesystem abstraction layer in \gls{LX}.
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{BSD}{
|
\newglossaryentry{BSD}{
|
||||||
name = BSD,
|
name = BSD,
|
||||||
description = {
|
description = {%
|
||||||
TODO
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{computer}{
|
\newglossaryentry{computer}{
|
||||||
name = Computer,
|
name = Computer,
|
||||||
description = {
|
description = {%
|
||||||
is a programmable machine that receives input,
|
is a programmable machine that receives input,
|
||||||
stores and manipulates data, and provides
|
stores and manipulates data, and provides
|
||||||
output in a useful format
|
output in a useful format
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{app}{
|
|
||||||
name=software-application,
|
|
||||||
description={
|
|
||||||
TODO
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
\newglossaryentry{pm}{
|
\newglossaryentry{pm}{
|
||||||
name = package manager,
|
name = package manager,
|
||||||
description={
|
description = {%
|
||||||
TODO
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{sac}{
|
\newglossaryentry{sac}{
|
||||||
name = Software Application Container,
|
name = Software Application Container,
|
||||||
description={
|
description = {%
|
||||||
The broad term for the technology used to build, package, distribute and run an application program in isolation from the underlying and co-existing systems, wherein the level or technique of isolation can be different depending on the \gls{sacr}.
|
The broad term for the technology used to build, package, distribute and run an application program in isolation from the underlying and co-existing systems, wherein the level or technique of isolation can be different depending on the \gls{sacr}.
|
||||||
The term is nuanced from \gls{appc} defined by the \gls{appcorg}.
|
The term is nuanced from \gls{appc} defined by the \gls{appcorg}.
|
||||||
The \gls{appcorg} is a community driven effort to create an open, standardized specification for developers and users of \gls{sac} technology.
|
The \gls{appcorg} is a community driven effort to create an open, standardized specification for developers and users of \gls{sac} technology.
|
||||||
|
|
@ -137,56 +288,241 @@
|
||||||
}
|
}
|
||||||
\newglossaryentry{saci}{
|
\newglossaryentry{saci}{
|
||||||
name = Software Application Container Image,
|
name = Software Application Container Image,
|
||||||
description={
|
description = {%
|
||||||
An archive file that contains all of the necessary binaries that are needed to execute an application and a manifest file that that contains metadata about the application. Alternatively to containing all the required binary files, the manifest file can declare dependencies to other application container images, which must then be available at runtime to execute the contained application.
|
An archive file that contains all of the necessary binaries that are needed to execute an application and a manifest file that that contains metadata about the application. Alternatively to containing all the required binary files, the manifest file can declare dependencies to other application container images, which must then be available at runtime to execute the contained application.
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{sacr}{
|
\newglossaryentry{sacr}{
|
||||||
name = Software Application Container Runtime,
|
name = Software Application Container Runtime,
|
||||||
description={
|
description = {%
|
||||||
An application program (suite) that understands how to run the software inside an \gls{saci}.
|
An application program (suite) that understands how to run the software inside an \gls{saci}.
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{LXC}{
|
\newglossaryentry{LXC}{
|
||||||
name = LXC,
|
name = LXC,
|
||||||
description={
|
description = {%
|
||||||
TODO
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{Docker}{
|
\newglossaryentry{Docker}{
|
||||||
name = Docker,
|
name = Docker,
|
||||||
description={
|
description = {%
|
||||||
A very popular \gls{sac} platform and application suite, providing functionality to build and deploy Docker specific \glspl{saci}.
|
A very popular \gls{sac} platform and application suite, providing functionality to build and deploy Docker specific \glspl{saci}.
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{systemd-nspawn}{
|
\newglossaryentry{systemd-nspawn}{
|
||||||
name = systemd-nspawn,
|
name = systemd-nspawn,
|
||||||
description={
|
description = {%
|
||||||
TODO
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{rkt}{
|
\newglossaryentry{rkt}{
|
||||||
name = rkt,
|
name = rkt,
|
||||||
description={
|
description = {%
|
||||||
TODO
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{appcorg}{
|
\newglossaryentry{appcorg}{
|
||||||
name = App Container Organisation,
|
name = App Container Organisation,
|
||||||
description={
|
description = {%
|
||||||
Organisation for the App Container specification, including the schema and associated tooling.
|
Organisation for the App Container specification, including the schema and associated tooling.
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
\newglossaryentry{appc}{
|
\newglossaryentry{appc}{
|
||||||
name = App Container,
|
name = App Container,
|
||||||
|
description = {%
|
||||||
|
Specific variant of an \glsentrytext{sac} defined by the \glsentrytext{appcorg}.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{NVD}{
|
||||||
|
name = {NVD},
|
||||||
description = {
|
description = {
|
||||||
Specific variant of an \gls{sac} defined by the \gls{appcorg}.
|
The NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes databases of security checklist references, security related software flaws, misconfigurations, product names, and impact metrics.\cite{NVD}
|
||||||
|
},
|
||||||
|
long = {\citetitle{NVD}},
|
||||||
|
first = {\glsentrylong{NVD}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{CWE}{
|
||||||
|
name = {CWE™},
|
||||||
|
long = Common Weakness Enumeration,
|
||||||
|
description = {a community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and as a baseline for weakness identification, mitigation, and prevention efforts},
|
||||||
|
first = {\glsentrylong{CWE}, "\glsentrydesc{CWE}"\cite{MITRE-CWE}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{CWE-633}{
|
||||||
|
name = CWE-633,
|
||||||
|
description = {Weaknesses in this category affect memory resources},
|
||||||
|
first = {CWE-633: \glsentrydesc{CWE-633}\cite{MITRE-CWE-633}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{CWE-119}{
|
||||||
|
name = CWE-119,
|
||||||
|
long = {CWE-119: \glsentrydesc{CWE-119}},
|
||||||
|
description = {Improper Restriction of Operations within the Bounds of a Memory Buffer},
|
||||||
|
first = {\glsentrytext{CWE-119}\cite{MITRE-CWE-119}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{CWE-635}{
|
||||||
|
name = CWE-635,
|
||||||
|
long = {\glsentrydesc{CWE-635}},
|
||||||
|
description = {\citetitle{MITRE-CWE-635}},
|
||||||
|
first = {\glsentrytext{CWE-635}\cite{MITRE-CWE-635}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{CWE-122}{
|
||||||
|
name = CWE-122,
|
||||||
|
long = {\glsentrydesc{CWE-122}},
|
||||||
|
description = {\citetitle{MITRE-CWE-122}},
|
||||||
|
first = {\glsentrytext{CWE-122}\cite{MITRE-CWE-122}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{CWE-134}{
|
||||||
|
name = CWE-134,
|
||||||
|
long = {\glsentrydesc{CWE-134}},
|
||||||
|
description = {\citetitle{MITRE-CWE-134}},
|
||||||
|
first = {\glsentrytext{CWE-134}\cite{MITRE-CWE-134}}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{C}{
|
||||||
|
name = C,
|
||||||
|
, description = {%
|
||||||
|
C programming language,
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{C++}{
|
||||||
|
name = C++,
|
||||||
|
, description = {%
|
||||||
|
A \glsentrytext {proglag} based on \glsentrytext{C}, enahnced by features like object-orientation, lambdas, and much more.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{asm}{
|
||||||
|
name = ASM,
|
||||||
|
long = Assembly programming language,
|
||||||
|
description = {%
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{amd64}{
|
||||||
|
name = AMD64,
|
||||||
|
long = AMD64,
|
||||||
|
description = {%
|
||||||
|
Contemporary Hardware Architecture\cite{AMD64Vol1,AMD64Vol2}
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{amd64}},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{cpu}{
|
||||||
|
name = CPU,
|
||||||
|
long = Central Processing Unit,
|
||||||
|
description = {%
|
||||||
|
Central Haddware Unit that executes machine code
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{cpu}},
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
\newglossaryentry{tlb}{
|
||||||
|
name = TLB,
|
||||||
|
long = Translation Lookaside Buffer,
|
||||||
|
description = {%
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{tlb}},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{mmu}{
|
||||||
|
name = MMU,
|
||||||
|
long = Memory Management Unit,
|
||||||
|
description = {%
|
||||||
|
Physical part of the \gls{cpu} equipped for managing the system's memory.
|
||||||
|
},
|
||||||
|
first = {\glsentrylong{MMU}},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{vaddr}{
|
||||||
|
name = virtual address,
|
||||||
|
plural = virtual addresses,
|
||||||
|
description = {%
|
||||||
|
Memory Addresses that does not reference physical memory directly, but is part of a memory virtualization scheme.
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{sysadmin}{
|
||||||
|
name = System Administrator
|
||||||
|
, description = {%
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{realtime}{
|
||||||
|
name = realtime
|
||||||
|
, description = {%
|
||||||
|
In computer science realtime refers to guaranateed execution within specified time boundaries.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{app}{
|
||||||
|
name = software-application,
|
||||||
|
description = {%
|
||||||
|
A bundle of one or multiple programs with a common use-case that can be run on an \gls{os}.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{task}{
|
||||||
|
name = task
|
||||||
|
, description = {%
|
||||||
|
Generic term for any unit of work to be executed on the.
|
||||||
|
In the context of this study, it may be used for any of \glsentrytext{program}, \glsentrytext{process}, \glsentrytext{thread}.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{program}{
|
||||||
|
name = program
|
||||||
|
, description = {%
|
||||||
|
A group of instructions that can be executed by the \glsentryname{cpu}.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{process}{
|
||||||
|
name = process
|
||||||
|
, description = {%
|
||||||
|
A Program in execution.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{thread}{
|
||||||
|
name = thread
|
||||||
|
, description = {%
|
||||||
|
A defined path of instructions within a process.
|
||||||
|
It can span from a part of a procedure up to the whole program of the process.
|
||||||
|
Threads can be identified in the program code by hypothetical execution paths.
|
||||||
|
The thread can only be executed by spawning a process in such a way that the specific thread in the program will be executed, e.g. by invoking specific arguments.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{procedure}{
|
||||||
|
name = procedure
|
||||||
|
, description = {%
|
||||||
|
An addressable subgroup of instructions in a program that contains specific functionality.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{function}{
|
||||||
|
name = function
|
||||||
|
, description = {%
|
||||||
|
See Procedure.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{job}{
|
||||||
|
name = job
|
||||||
|
, description = {%
|
||||||
|
A specific unit of work, specifying one or multiple programs to execute along with the arguments to be passed to them.
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
|
||||||
File diff suppressed because it is too large
Load diff
246
src/docs/parts/eval_and_conclusion/eval_and_conclusion.tex
Normal file
246
src/docs/parts/eval_and_conclusion/eval_and_conclusion.tex
Normal file
|
|
@ -0,0 +1,246 @@
|
||||||
|
% // vim: set ft=tex:
|
||||||
|
\chapter{Evaluation}
|
||||||
|
This chapter summarizes the findings of the previous parts.
|
||||||
|
The summary is then evaluated against the hypothesis, to create the foundation of a concise conclusion.
|
||||||
|
|
||||||
|
\section{Summary}
|
||||||
|
After defining an exact definition for memory-safety within the OS was found in \cref{context::introduction::memory-safety::def}, various aspects of software vulnerability origin were discussed.
|
||||||
|
The human was identified to be an error prone weak spot in the process of OS development.
|
||||||
|
It was found that technical solutions that can detect these errors are to be used as early in the development process as possible.
|
||||||
|
This point in time was declared the time of software compilation.
|
||||||
|
|
||||||
|
OS development concepts were introduced to for the AMD64 architecture, to lay out the knowledge that to allow an understanding and implementation of OS concepts on AMD64, which was set out for the development process.
|
||||||
|
|
||||||
|
Common Weaknesses in software were identified, and demonstrated how these lead to concrete vulnerabilities.
|
||||||
|
The stack clash was explained as an architectural and design issue, which requires changes in stack overflow detection in userspace software.
|
||||||
|
The origin of many of the weaknesses was identified to be based on weak languages, and Rust was verified to be a good alternative to C.
|
||||||
|
Research was conducted on these common weaknesses through other scientific studies.
|
||||||
|
This found weaknesses based on
|
||||||
|
\begin{itemize}
|
||||||
|
\item use-after-free
|
||||||
|
\item indexing out of bounds
|
||||||
|
\item iterator invalidation
|
||||||
|
\item data races
|
||||||
|
\end{itemize}
|
||||||
|
to be prevented by Rust's ownership system\cite{Beingessner2015}.
|
||||||
|
Stack protection experiments were conducted and found Rust to be less vulnerable to return address manipulation.
|
||||||
|
These were found to be effectively prevented by static analysis under normal circumstances, since it required multiple explicit features to intentionally force the manipulation to succeed.
|
||||||
|
Stack overflow could not be statically detected by trying various tweaks to the compiler.
|
||||||
|
Information that would be required for this static detection was evaluated, and was found to be not completely available in the present compiler architecture.
|
||||||
|
|
||||||
|
A practical introduction to Rust was given, overviewing the encountered language features and the ones that were explicitly investigated.
|
||||||
|
Rust was found to have extension features only limited by the complexity of its usage, demonstrated by an implementation of pure-software information flow control.
|
||||||
|
|
||||||
|
Existing OS development efforts were investigated to serve as a codebase for the development and to evaluate their usage of Rust for achieving memory-safety.
|
||||||
|
Redox OS was found to not be vulnerable to the Stack Clash due to design decisions in the OS.
|
||||||
|
Blog OS was found to demonstrate extensive usage of Rust's type system to model underlying hardware and prevent mistakes in the paging implementation.
|
||||||
|
|
||||||
|
Implementation of preemptive multitasking was chosen to be based on intermezzOS for its simplicity.
|
||||||
|
After initial problems with the build and debugging tools were solved, the development could proceed quickly.
|
||||||
|
Based on the state of intermezzOS that allowed the system to boot, a working preemptive multitasking was implemented successfully.
|
||||||
|
The implementation only supports static memory allocation and no dynamic memory management.
|
||||||
|
Writing a hardware-driver for the Programmable-Interrupt-Timer was well supported by the module and type system, which allowed an accurate modeling of the underlying hardware.
|
||||||
|
Global OS state variables can be protected by requiring Rust's unsafe keyword and disallowing the same within additional defined tasks.
|
||||||
|
Extensive usage of the unsafe keyword was required to perform raw hardware access, but could be limited to well-defined functions.
|
||||||
|
Inline machine-instructions were found to be well designed and in-line with the rest of the language.
|
||||||
|
One occurrence of a cast from an untyped pointer was necessary, within the context-switching interrupt handler, to manipulate data on the stack.
|
||||||
|
A stack overflow on user defined tasks could not be prevented by static analysis, only detected by the OS at runtime.
|
||||||
|
|
||||||
|
\subsection{Thesis Evaluation}
|
||||||
|
Rust's static analysis lacks the ability of static stack overflow detection, which is a significant counter-indication to the hypothesis.
|
||||||
|
Using Rust's static memory analysis does not fully guarantee In-Kernel memory-safe.
|
||||||
|
|
||||||
|
\chapter{Conclusions}
|
||||||
|
While hypothesis was not proven, Rust is still considered to be a significant improvement over C for OS development purposes.
|
||||||
|
|
||||||
|
\paragraph{Rust detects many errors early}
|
||||||
|
It prevents many errors at compile-time where, they are harmless.
|
||||||
|
The language is fully extendable via language extensions that allow the insertion of new language features that can be hooked into the static analysis.
|
||||||
|
The process of making Rust suitable for OS development is driven by many hobby and a few production intended projects.
|
||||||
|
|
||||||
|
\section{Hardware is still hard, but Rust is worth learning}
|
||||||
|
Even though Rust is understood as a memory-safe language, following the hardware specification is still a memory-safety critical requirement.
|
||||||
|
OS developers must use the unsafe keyword when performing raw hardware access, which is designed to make them think twice when using it.
|
||||||
|
If the chance is presented, Rust should be chosen any time over C for implementing software that is close to hardware.
|
||||||
|
This might be difficult in the first place, but should pay off long-term, as less vulnerabilities will be detected throughout the extended life-cycle of the software.
|
||||||
|
|
||||||
|
\section{Next Step}
|
||||||
|
Further investigation is required to propose a solution for the lack of static stack size estimation in \gls{Rust}.
|
||||||
|
The immediate next step is to bring this issue up for a discussion in the Rust community.
|
||||||
|
|
||||||
|
% \chapter{Scratchpad}
|
||||||
|
%
|
||||||
|
% \begin{figure}[ht!]
|
||||||
|
% \centering
|
||||||
|
% \begin{subfigure}[T]{0.50\textwidth}
|
||||||
|
% \tikzmarkcountprep{callee}
|
||||||
|
% \begin{compactminted}[
|
||||||
|
% escapeinside=??,linenos,autogobble,highlightlines={}
|
||||||
|
% ]{nasm}
|
||||||
|
% mov rax,QWORD PTR [rbp-0x48]?\tikzmarkcount?
|
||||||
|
% add rsp,0x50?\tikzmarkcount?
|
||||||
|
% pop rbp?\tikzmarkcount?
|
||||||
|
% ret?\tikzmarkcount?
|
||||||
|
% \end{compactminted}
|
||||||
|
% \tikzmarkdrawcircles
|
||||||
|
% \caption{Subfig A}
|
||||||
|
% \end{subfigure}
|
||||||
|
% \begin{subfigure}[T]{0.45\textwidth}
|
||||||
|
% \foreach \x/\xtext in {
|
||||||
|
% 1/{
|
||||||
|
% this is going to be a really long sentence with line wraps
|
||||||
|
% },
|
||||||
|
% 2/{
|
||||||
|
% second
|
||||||
|
% }
|
||||||
|
% } {\tikzmarkcircle{\x}\xtext\\}
|
||||||
|
% \caption{Subfig B}
|
||||||
|
% \end{subfigure}
|
||||||
|
% \caption{Whadup}
|
||||||
|
% \label{Whadup}
|
||||||
|
% \end{figure}
|
||||||
|
%
|
||||||
|
% \begin{listing}
|
||||||
|
% \tikzmarkcountprep{example1}
|
||||||
|
% \begin{minted}[
|
||||||
|
% label=example1,labelposition=all,escapeinside=??,linenos,autogobble,highlightlines={}
|
||||||
|
% ]{nasm}
|
||||||
|
% mov rax,QWORD PTR [rbp-0x48]?\tikzmarkcount? ?\tikzmark{brace1upper}?
|
||||||
|
% add rsp,0x50?\tikzmarkcount?
|
||||||
|
% pop rbp?\tikzmarkcount?
|
||||||
|
% ret?\tikzmarkcount? ?\tikzmark{brace1lower}?
|
||||||
|
% \end{minted}
|
||||||
|
% \begin{minted}[
|
||||||
|
% escapeinside=??,linenos,autogobble,highlightlines={}
|
||||||
|
% ]{nasm}
|
||||||
|
% mov rax,QWORD PTR [rbp-0x48]?\tikzmarkcount?
|
||||||
|
% add rsp,0x50 ?\tikzmarkcount?
|
||||||
|
% pop rbp ?\tikzmarkcount?
|
||||||
|
% ret ?\tikzmarkcount?
|
||||||
|
% \end{minted}
|
||||||
|
% \begin{tikzpicture}[remember picture,overlay]
|
||||||
|
% \draw[thick,decorate,decoration={brace,raise=1ex}]
|
||||||
|
% (pic cs:brace1upper)+(0,1.5ex) -- node[shape=coordinate][right=1.5ex] (a) {} (pic cs:brace1lower);
|
||||||
|
% \fill (a)+(2ex,0) circle[opacity=1,radius=1.1ex] node[white,font=\small]{a};
|
||||||
|
% \end{tikzpicture}
|
||||||
|
% \tikzmarkdrawcircles
|
||||||
|
% \caption{Minted Listing A}
|
||||||
|
% %
|
||||||
|
% \foreach \x/\xtext in {
|
||||||
|
% 1/{
|
||||||
|
% this is going to be a really long sentence with line wraps
|
||||||
|
% \\}
|
||||||
|
% ,2/{
|
||||||
|
% second
|
||||||
|
% \\}
|
||||||
|
% ,5/{},6/{
|
||||||
|
% hi
|
||||||
|
% \\}
|
||||||
|
% ,a/{
|
||||||
|
% hi
|
||||||
|
% \\}
|
||||||
|
% } {\tikzmarkcircle{\x}\xtext}
|
||||||
|
% %
|
||||||
|
% \end{listing}
|
||||||
|
% \FloatBarrier
|
||||||
|
%
|
||||||
|
% \begin{listing}
|
||||||
|
% \tikzset{/minted/basename=example}
|
||||||
|
% \begin{minted}[label=caller,labelposition=topline,escapeinside=??,highlightlines={},autogobble,linenos,breaklines=true]{nasm}
|
||||||
|
% mov rcx,QWORD PTR [rbp-0x40] ; copy 1st arg to rcx
|
||||||
|
% mov rsi,QWORD PTR [rbp-0x38] ; copy 2nd arg to rsi
|
||||||
|
% mov rdx,QWORD PTR [rbp-0x30] ; copy 3rd arg to rdx
|
||||||
|
% mov QWORD PTR [rbp-0x60],rdi ; save rdi to make it available
|
||||||
|
% mov rdi,rcx ; copy 1st arg to rdi
|
||||||
|
% mov QWORD PTR [rbp-0x68],rax ; save rax to make it available
|
||||||
|
% call 7490?\tikzmark{exampleprecallfrom}? <_ZN14stack_handling3sum17h8f12d2383e075691E> ; push '756e' onto the stack and jump to the first instruction of sum
|
||||||
|
% mov QWORD PTR [rbp-0x28],rax ; save return value
|
||||||
|
% \end{minted}
|
||||||
|
% \caption{Function Call with Three Arguments}
|
||||||
|
% \begin{tikzpicture}[remember picture,overlay]
|
||||||
|
% \draw[red,thick] (pic cs:exampleprecallfrom) ellipse (0.7cm and 12pt) node { \textbf{1} };
|
||||||
|
% \fill[blue] (pic cs:example1) circle (0.1cm);
|
||||||
|
% \fill[yellow] (pic cs:example2) circle (0.1cm);
|
||||||
|
% \end{tikzpicture}
|
||||||
|
% \end{listing}
|
||||||
|
%
|
||||||
|
% \begin{tikzpicture}[node distance=2cm,
|
||||||
|
% startstop/.style={rectangle, rounded corners, minimum width=3cm, minimum height=1cm,text centered, draw=black, fill=red!30},
|
||||||
|
% io/.style = {trapezium, trapezium left angle=70, trapezium right angle=110, minimum width=3cm, minimum height=1cm, text centered, draw=black, fill=blue!30},
|
||||||
|
% process/.style = {rectangle, minimum width=1cm, minimum height=1cm, text centered, text width=3cm, draw=black, fill=orange!30},
|
||||||
|
% decision/.style = {diamond, minimum width=3cm, minimum height=1cm, text centered, draw=black, fill=green!30},
|
||||||
|
% arrow/.style = {thick,->,>=stealth}
|
||||||
|
% ]
|
||||||
|
%
|
||||||
|
% %\node (start) [startstop] {Start};
|
||||||
|
% %\node (in1) [io, below of=start] {Input};
|
||||||
|
% %\node (pro1) [process, below of=in1] {Process 1};
|
||||||
|
% %\node (dec1) [decision, below of=pro1, yshift=-0.5cm] {Decision 1};
|
||||||
|
% %\node (pro2a) [process, below of=dec1, yshift=-0.5cm] {Process 2a text text text text text text text text text text};
|
||||||
|
% %\node (pro2b) [process, right of=dec1, xshift=2cm] {Process 2b};
|
||||||
|
% %\node (out1) [io, below of=pro2a] {Output};
|
||||||
|
% %\node (stop) [startstop, below of=out1] {Stop};
|
||||||
|
% %
|
||||||
|
% %\draw [arrow] (start) -- (in1);
|
||||||
|
% %\draw [arrow] (in1) -- (pro1);
|
||||||
|
% %\draw [arrow] (pro1) -- (dec1);
|
||||||
|
% %\draw [arrow] (dec1) -- node[anchor=east] {yes} (pro2a);
|
||||||
|
% %\draw [arrow] (dec1) -- node[anchor=south] {no} (pro2b);
|
||||||
|
% %\draw [arrow] (pro2b) |- (pro1);
|
||||||
|
% %\draw [arrow] (pro2a) -- (out1);
|
||||||
|
% %\draw [arrow] (out1) -- (stop);
|
||||||
|
%
|
||||||
|
% \node[process,xshift=0ex,yshift=-0ex] (ua_back) {User Applications};
|
||||||
|
% \node[process,xshift=0ex,yshift=-1ex] at (ua_back) {User Applications};
|
||||||
|
% \node[process,xshift=0ex,yshift=-2ex] (ua) at (ua_back) {User Applications};
|
||||||
|
%
|
||||||
|
% \node[process,xshift=0ex,yshift=-0ex,below of=ua] (sl_back) {System Libraries};
|
||||||
|
% \node[process,xshift=0ex,yshift=-1ex] at (sl_back) {System Libraries};
|
||||||
|
% \node[process,xshift=0ex,yshift=-2ex] (sl) at (sl_back) {System Libraries};
|
||||||
|
%
|
||||||
|
% \node[process,xshift=0ex,yshift=-0ex,below of=sl] (os_back) {OS};
|
||||||
|
% \node[process,xshift=0ex,yshift=-1ex] at (os_back) {OS API};
|
||||||
|
% \node[process,xshift=0ex,yshift=-2ex] (os) at (os_back) {OS};
|
||||||
|
%
|
||||||
|
% \node[process,xshift=0ex,yshift=-0ex,left of=mem, below of=os] (cpu) {CPU};
|
||||||
|
% \node[process,xshift=0ex,yshift=-0ex,right of=cpu] (mem) {Memory};
|
||||||
|
% \node[process,xshift=0ex,yshift=-0ex,right of=mem] (otherhw) {Other HW};
|
||||||
|
%
|
||||||
|
% \draw [arrow] (ua) -- (sl);
|
||||||
|
% \draw [arrow] (sl) -- (os);
|
||||||
|
% \draw [arrow] (os) -- (cpu);
|
||||||
|
% \draw [arrow] (os) -- (mem);
|
||||||
|
% \draw [arrow] (os) -- (otherhw);
|
||||||
|
%
|
||||||
|
% TODO: improve
|
||||||
|
%
|
||||||
|
% \end{tikzpicture}
|
||||||
|
%
|
||||||
|
% \begin{markdown}
|
||||||
|
% # Flow of Reasoning
|
||||||
|
% * How to mitigate distributed weaknesses
|
||||||
|
% - Don't distribute vulnerable software
|
||||||
|
% - Produce less vulnerabilities
|
||||||
|
% OR
|
||||||
|
% - Detect vulnerabilities
|
||||||
|
% * How to prevent vulnerabilities distribution?
|
||||||
|
% - Human to make less mistakes; NOT VIABLE, see human aspect.
|
||||||
|
% - Detect them before the \gls{app} is installed; see time aspect
|
||||||
|
% * How to detect vulnerabilities
|
||||||
|
% - Write runtime tests for the program
|
||||||
|
% - Analyze the source code
|
||||||
|
% * Runtime Tests
|
||||||
|
% - Runs on every execution, thus wastes \gls{cpu} resources
|
||||||
|
% - Program needs to handle it
|
||||||
|
% -> Slow and too late in the software life cycle!
|
||||||
|
% * Source Code Analysis
|
||||||
|
% - Difficult for low-level code, would require hardware knowledge
|
||||||
|
% - Compilers are source code analysers by nature
|
||||||
|
% - Additional tools can help, but this takes more effort
|
||||||
|
% -> chose a compiler with high analysis standards
|
||||||
|
% * Choice of Compiler: Language Dependent
|
||||||
|
% - C: Safe C, Cyclone, etc.: define sub language that is analyzable. MEH
|
||||||
|
% - Rust: designed to be analyzable. WIN!
|
||||||
|
% * Rust
|
||||||
|
% - Can the analyzes be extended to suite OS dev?
|
||||||
|
% \end{markdown}
|
||||||
|
|
@ -1,69 +0,0 @@
|
||||||
% // vim: set ft=tex:
|
|
||||||
\chapter{Topic Refinement}
|
|
||||||
|
|
||||||
\chapter{Criteria}
|
|
||||||
This chapter explains the criteria for evaluating available \glspl{pm} for their potential to be part of the developed solution.
|
|
||||||
|
|
||||||
\section{Specification Of Complete}
|
|
||||||
|
|
||||||
\section{Binary- and Source Package Support}
|
|
||||||
|
|
||||||
\section{Installation and Update Mechanism}
|
|
||||||
|
|
||||||
\subsection{Security Updates}
|
|
||||||
|
|
||||||
\section{Usability}
|
|
||||||
|
|
||||||
\section{Support}
|
|
||||||
|
|
||||||
\section{Package Repositories}
|
|
||||||
|
|
||||||
\section{Efficiency}
|
|
||||||
|
|
||||||
\chapter{Available Package Managers (and Build Managers)}
|
|
||||||
|
|
||||||
\section{Portage}
|
|
||||||
|
|
||||||
\section{Nix}
|
|
||||||
|
|
||||||
\section{Guix}
|
|
||||||
\textbf{Feature}
|
|
||||||
\begin{description}
|
|
||||||
\item [Automatic Updates of Sources] {
|
|
||||||
`guix refresh` can update package sources according to defined updaters
|
|
||||||
}
|
|
||||||
\item [Native CI] { https://notabug.org/mthl/cuirass }
|
|
||||||
\end{description}
|
|
||||||
|
|
||||||
|
|
||||||
\section{Spack}
|
|
||||||
Spack (\url{https://github.com/LLNL/spack}) is a package manager written in Python.
|
|
||||||
|
|
||||||
\begin{description}
|
|
||||||
\item [Automatic Updates of Sources] {
|
|
||||||
}
|
|
||||||
\item [Closure] {
|
|
||||||
Explained on the website \url{http://software.llnl.gov/spack/basic_usage.html\#filesystem-views}
|
|
||||||
}
|
|
||||||
\end{description}
|
|
||||||
|
|
||||||
|
|
||||||
\section{bazel}
|
|
||||||
|
|
||||||
In case the dependency tree includes different versions of the same project, only one of them can be included in the WORKSPACE.
|
|
||||||
This potentially breaks compatibility for the projects that depend on a different version of the dependency.
|
|
||||||
|
|
||||||
% TODO: cite source https://www.bazel.io/versions/master/docs/external.html#transitive-dependencies
|
|
||||||
|
|
||||||
\section{0install}
|
|
||||||
|
|
||||||
\chapter{Languages Used For Packaging}
|
|
||||||
|
|
||||||
\section{Guile Scheme}
|
|
||||||
Guile implements Scheme and extends it with new features.
|
|
||||||
|
|
||||||
\chapter{Abstraction of \gls{sacr} and \gls{saci}}
|
|
||||||
\label{chap:research-abstract-acpr-saci}
|
|
||||||
|
|
||||||
|
|
||||||
UX: \url{https://logicgrimoire.wordpress.com/2012/08/25/a-first-guile-script}
|
|
||||||
1574
src/docs/parts/research_and_development/research_and_development.tex
Normal file
1574
src/docs/parts/research_and_development/research_and_development.tex
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -1,94 +1,361 @@
|
||||||
Automatically generated by Mendeley Desktop 1.16.3
|
Automatically generated by Mendeley Desktop 1.17.8
|
||||||
Any changes to this file will be lost if it is regenerated by Mendeley.
|
Any changes to this file will be lost if it is regenerated by Mendeley.
|
||||||
|
|
||||||
BibTeX export options can be customized via Options -> BibTeX in Mendeley Desktop
|
BibTeX export options can be customized via Options -> BibTeX in Mendeley Desktop
|
||||||
|
|
||||||
@inproceedings{Hallyn2008,
|
@article{Beingessner2015,
|
||||||
author = {Hallyn, S.E. and Morgan, A.G.},
|
author = {Beingessner, Alexis},
|
||||||
booktitle = {Linux Symposium},
|
file = {:home/steveej/src/steveej/msc-thesis/docs/You can't spell trust without Rust.pdf:pdf},
|
||||||
file = {:home/steveej/src/github/steveej/msc-thesis/papers/Linux Capabilities$\backslash$: making them work.pdf:pdf},
|
title = {{YOU CAN'T SPELL TRUST WITHOUT RUST}},
|
||||||
issn = {1440-1746},
|
year = {2015}
|
||||||
keywords = {Animals,Gastroenterology,Gastrointestinal Diseases,Humans},
|
|
||||||
pmid = {21751466},
|
|
||||||
title = {{Linux Capabilities: making them work}},
|
|
||||||
url = {http://kernel.org/doc/mirror/ols2008v1.pdf{\#}page=163},
|
|
||||||
volume = {1},
|
|
||||||
year = {2008}
|
|
||||||
}
|
}
|
||||||
@book{Utrecht2006,
|
@misc{OsPhilOpp,
|
||||||
abstract = {Software deployment is the set of activities related to getting$\backslash$r$\backslash$nsoftware components to work on the machines of end users. It includes$\backslash$r$\backslash$nactivities such as installation, upgrading, uninstallation, and so on.$\backslash$r$\backslash$nMany tools have been developed to support deployment, but they all$\backslash$r$\backslash$nhave serious limitations with respect to correctness. For instance,$\backslash$r$\backslash$nthe installation of a component can lead to the failure of previously$\backslash$r$\backslash$ninstalled components; a component might require other components that$\backslash$r$\backslash$nare not present; and it is generally difficult to undo deployment$\backslash$r$\backslash$nactions. The fundamental causes of these problems are a lack of$\backslash$r$\backslash$nisolation between components, the difficulty in identifying the$\backslash$r$\backslash$ndependencies between components, and incompatibilities between$\backslash$r$\backslash$nversions and variants of components.$\backslash$r$\backslash$n $\backslash$r$\backslash$nThis thesis describes a better approach based on a purely functional$\backslash$r$\backslash$ndeployment model, implemented in a deployment system called Nix.$\backslash$r$\backslash$nComponents are stored in isolation from each other in a Nix store.$\backslash$r$\backslash$nEach component has a name that contains a cryptographic hash of all$\backslash$r$\backslash$ninputs that contributed to its build process, and the content of a$\backslash$r$\backslash$ncomponent never changes after it has been built. Hence the model is$\backslash$r$\backslash$npurely functional.$\backslash$r$\backslash$n $\backslash$r$\backslash$nThis storage scheme provides several important advantages. First, it$\backslash$r$\backslash$nensures isolation between components: if two components differ in any$\backslash$r$\backslash$nway, they will be stored in different locations and will not overwrite$\backslash$r$\backslash$neach other. Second, it allows us to identify component dependencies.$\backslash$r$\backslash$nUndeclared build time dependencies are prevented due to the absence of$\backslash$r$\backslash$n"global" component directories used in other deployment systems.$\backslash$r$\backslash$nRuntime dependencies can be found by scanning for cryptographic hashes$\backslash$r$\backslash$nin the binary contents of components, a technique analogous to$\backslash$r$\backslash$nconservative garbage collection in programming language$\backslash$r$\backslash$nimplementation. Since dependency information is complete, complete$\backslash$r$\backslash$ndeployment can be performed by copying closures of components under$\backslash$r$\backslash$nthe dependency relation.$\backslash$r$\backslash$n $\backslash$r$\backslash$nDevelopers and users are not confronted with components' cryptographic$\backslash$r$\backslash$nhashes directly. Components are built automatically from Nix$\backslash$r$\backslash$nexpressions, which describe how to build and compose arbitrary$\backslash$r$\backslash$nsoftware components; hashes are computed as part of this process.$\backslash$r$\backslash$nComponents are automatically made available to users through "user$\backslash$r$\backslash$nenvironments", which are synthesised sets of activated components.$\backslash$r$\backslash$nUser environments enable atomic upgrades and rollbacks, as well as$\backslash$r$\backslash$ndifferent sets of activated components for different users.$\backslash$r$\backslash$n $\backslash$r$\backslash$nNix expressions provide a source-based deployment model. However,$\backslash$r$\backslash$nsource-based deployment can be transparently optimised into binary$\backslash$r$\backslash$ndeployment by making pre-built binaries (keyed on their cryptographic$\backslash$r$\backslash$nhashes) available in a shared location such as a network server. This$\backslash$r$\backslash$nis referred to as transparent source/binary deployment.$\backslash$r$\backslash$n $\backslash$r$\backslash$nThe purely functional deployment model has been validated by applying$\backslash$r$\backslash$nit to the deployment of more than 278 existing Unix packages. In$\backslash$r$\backslash$naddition, this thesis shows that the model can be applied naturally to$\backslash$r$\backslash$nthe related activities of continuous integration using build farms,$\backslash$r$\backslash$nservice deployment and build management.},
|
author = {Oppermann, Philipp},
|
||||||
author = {Utrecht, Universiteit and Magnificus, Rector},
|
title = {{Writing an OS in Rust}},
|
||||||
booktitle = {Utrecht University},
|
url = {https://os.phil-opp.com/}
|
||||||
doi = {10.1007/s12630-009-9179-6},
|
|
||||||
file = {:home/steveej/src/github/steveej/msc-thesis/papers/nix-phd-thesis.pdf:pdf},
|
|
||||||
isbn = {9039341303},
|
|
||||||
issn = {14968975},
|
|
||||||
number = {12},
|
|
||||||
pages = {0--281},
|
|
||||||
pmid = {19728000},
|
|
||||||
title = {{The Purely Functional Software Deployment Model}},
|
|
||||||
url = {http://www.st.ewi.tudelft.nl/{~}dolstra/pubs/phd-thesis.pdf},
|
|
||||||
volume = {56},
|
|
||||||
year = {2006}
|
|
||||||
}
|
}
|
||||||
@article{Fink2014,
|
@article{Balasubramanian2017,
|
||||||
abstract = {Docker is a relatively new method of virtualization available natively for 64-bit Linux. Compared to more traditional virtualization techniques, Docker is lighter on system resources, offers a git-like system of commits and tags, and can be scaled from your laptop to the cloud.},
|
abstract = {Rust is a new system programming language that offers a practical and safe alternative to C. Rust is unique in that it enforces safety without runtime overhead, most importantly, without the overhead of garbage collection. While zero-cost safety is remarkable on its own, we argue that the super-powers of Rust go beyond safety. In particular, Rust's linear type system enables capabilities that cannot be implemented efficiently in traditional languages, both safe and unsafe, and that dramatically improve security and reliability of system software. We show three examples of such capabilities: zero-copy software fault isolation, efficient static information flow analysis, and automatic checkpointing. While these capabilities have been in the spotlight of systems research for a long time, their practical use is hindered by high cost and complexity. We argue that with the adoption of Rust these mechanisms will become commoditized.},
|
||||||
author = {Fink, John},
|
author = {Balasubramanian, Abhiram and Baranowski, Marek S and Burtsev, Anton and Irvine, Uc and Rakamari, Zvonimir and Ryzhyk, Leonid and Research, Vmware},
|
||||||
file = {:home/steveej/src/github/steveej/msc-thesis/papers/Docker - a Software as a Service, Operating System-Level Virtualization Framework.pdf:pdf},
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/DRAFT$\backslash$: System Programming in Rust$\backslash$: Beyond Safety.pdf:pdf},
|
||||||
journal = {Code4Lib},
|
title = {{DRAFT: System Programming in Rust: Beyond Safety}},
|
||||||
number = {25},
|
year = {2017}
|
||||||
pages = {3--5},
|
}
|
||||||
title = {{Docker: a Software as a Service, Operating System-Level Virtualization Framework}},
|
@inproceedings{Ma2013,
|
||||||
url = {http://journal.code4lib.org/articles/9669},
|
abstract = {—Aiming at the problem of higher memory consumption and lower execution efficiency during the dynamic detecting to C/C++ programs memory vulnerabilities, this paper presents a dynamic detection method called ISC. The ISC improves the Safe-C using pointer analysis technology. Firstly, the ISC defines a simple and efficient fat pointer representation instead of the safe pointer in the Safe-C. Furthermore, the ISC uses the unification-based analysis algorithm with one level flow static pointer. This identification reduces the number of pointers that need to be converted to fat pointers. Then in the process of program running, the ISC detects memory vulnerabilities through constantly inspecting the attributes of fat pointers. Experimental results indicate that the ISC could detect memory vulnerabilities such as buffer overflows and dangling pointers. Comparing with the Safe-C, the ISC dramatically reduces the memory consumption and lightly improves the execution efficiency.},
|
||||||
volume = {1},
|
author = {Ma, Rui and Chen, Lingkui and Hu, Changzhen and Xue, Jingfeng and Zhao, Xiaolin},
|
||||||
|
booktitle = {Proceedings - 2013 IEEE 11th International Conference on Dependable, Autonomic and Secure Computing, DASC 2013},
|
||||||
|
doi = {10.1109/DASC.2013.37},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/A Dynamic Detection Method to C-C++ Programs Memory Vulnerabilities Based on Pointer Analysis.pdf:pdf},
|
||||||
|
isbn = {9781479933815},
|
||||||
|
keywords = {dynamic detecting,fat pointer,improved Safe-C,memory vulnerability,pointer analysis},
|
||||||
|
pages = {52--57},
|
||||||
|
title = {{A dynamic detection method to C/C++ programs memory vulnerabilities based on pointer analysis}},
|
||||||
|
year = {2013}
|
||||||
|
}
|
||||||
|
@article{Dhurjati2003,
|
||||||
|
abstract = {Traditional approaches to enforcing memory safety of programs rely heavily on runtime checks of memory accesses and on garbage collection, both of which are unattractive for embedded applications. The long-term goal of our work is to enable 100{\%} static enforcement of memory safety for embedded programs through advanced compiler techniques and minimal semantic restrictions on programs. The key result of this paper is a compiler technique that ensures memory safety of dynamically allocated memory without programmer annotations, runtime checks, or garbage collection, and works for a large subclass of type-safe C programs. The technique is based on a fully automatic pool allocation (i.e., region-inference) algorithm for C programs we developed previously, and it ensures safety of dynamically allocated memory while retaining explicit deallocation of individual objects within regions (to avoid garbage collection). For a diverse set of embedded C programs (and using a previous technique to avoid null pointer checks), we show that we are able to statically ensure the safety of pointer and dynamic memory usage in all these programs. We also describe some improvements over our previous work in static checking of array accesses. Overall, we achieve 100{\%} static enforcement of memory safety without new language syntax for a significant subclass of embedded C programs, and the subclass is much broader if array bounds checks are ignored.},
|
||||||
|
author = {Dhurjati, D and Kowshik, S and Adve, V and Lattner, C},
|
||||||
|
doi = {10.1145/780742.780743},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/Memory Safety Without Runtime Checks or Garbage.pdf:pdf},
|
||||||
|
isbn = {0362-1340},
|
||||||
|
issn = {03621340},
|
||||||
|
journal = {Acm Sigplan Notices},
|
||||||
|
keywords = {automatic pool allocation,compilers,embedded systems,languages,programming languages,region management,security,static analysis},
|
||||||
|
number = {7},
|
||||||
|
pages = {69--80},
|
||||||
|
title = {{Memory safety without runtime checks or garbage collection}},
|
||||||
|
volume = {38},
|
||||||
|
year = {2003}
|
||||||
|
}
|
||||||
|
@article{Junker,
|
||||||
|
author = {Junker, Stefan},
|
||||||
|
file = {:home/steveej/src/steveej/msc-thesis/src/docs/thesis.pdf:pdf},
|
||||||
|
title = {{Guarantees On In-Kernel Memory-Safety Using Rust's Static Code Analysis}}
|
||||||
|
}
|
||||||
|
@misc{Endler,
|
||||||
|
author = {Endler, Matthias},
|
||||||
|
title = {{A curated list of static analysis tools, linters and code quality checkers for various programming languages}},
|
||||||
|
url = {https://github.com/mre/awesome-static-analysis}
|
||||||
|
}
|
||||||
|
@article{Corporation2011,
|
||||||
|
abstract = {The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volume 1, describes the basic architecture and programming environment of Intel 64 and IA-32 processors. The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volumes 2A {\&} 2B, describe the instruction set of the processor and the opcode struc- ture. These volumes apply to application programmers and to programmers who write operating systems or executives. The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volumes 3A {\&} 3B, describe the operating-system support environment of Intel 64 and IA-32 processors. These volumes target operating- system and BIOS designers. In addition, the Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volume 3B, addresses the programming environment for classes of software that host operating systems.},
|
||||||
|
author = {Corporation, Intel},
|
||||||
|
doi = {10.1109/MAHC.2010.22},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf:pdf},
|
||||||
|
isbn = {253665-057US},
|
||||||
|
issn = {15222594},
|
||||||
|
journal = {System},
|
||||||
|
keywords = {253665,IA-32 architecture,Intel 64},
|
||||||
|
number = {253665},
|
||||||
|
title = {{Intel {\textregistered} 64 and IA-32 Architectures Software Developer ' s Manual Volume 3}},
|
||||||
|
volume = {3},
|
||||||
|
year = {2011}
|
||||||
|
}
|
||||||
|
@article{Matz2009,
|
||||||
|
author = {Matz, M and Hubicka, J and Jaeger, a and Mitchell, M},
|
||||||
|
file = {:home/steveej/src/steveej/msc-thesis/docs/System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.7.pdf:pdf},
|
||||||
|
isbn = {013877630X},
|
||||||
|
pages = {1--128},
|
||||||
|
pmid = {2477614},
|
||||||
|
title = {{System V Application Binary Interface AMD64 Architecture Processor Supplement}},
|
||||||
|
url = {papers2://publication/uuid/CD8D5668-B1F5-4FE3-BAD8-25F1E589A9E5},
|
||||||
|
year = {2009}
|
||||||
|
}
|
||||||
|
@misc{MITRE-CWE-134,
|
||||||
|
author = {MITRE},
|
||||||
|
title = {{CWE-134: Use of Externally-Controlled Format String}},
|
||||||
|
url = {http://cwe.mitre.org/data/definitions/134.html},
|
||||||
|
urldate = {2017-09-20}
|
||||||
|
}
|
||||||
|
@article{Seri2017,
|
||||||
|
abstract = {The dangers of Bluetooth implementations: Unveiling zero day vulnerabilities and security flaws in modern Bluetooth stacks.},
|
||||||
|
author = {Seri, Ben and Vishnepolsky, Gregory},
|
||||||
|
file = {:home/steveej/src/steveej/msc-thesis/docs/BlueBorne Technical White Paper.pdf:pdf},
|
||||||
|
title = {{BlueBorne}},
|
||||||
|
url = {http://go.armis.com/blueborne-technical-paper},
|
||||||
|
year = {2017}
|
||||||
|
}
|
||||||
|
@article{Reed2015,
|
||||||
|
abstract = {Rust is a new systems language that uses some advanced type system features, specifically affine types and regions, to statically guarantee memory safety and eliminate the need for a garbage collector. While each individual addition to the type system is well understood in isolation and are known to be sound, the combined system is not known to be sound. Furthermore, Rust uses a novel checking scheme for its regions, known as the Borrow Checker, that is not known to be correct. Since Rust's goal is to be a safer alternative to C/C++, we should ensure that this safety scheme actually works. We present a formal semantics that captures the key features relevant to memory safety, unique pointers and borrowed references, specifies how they guarantee memory safety, and describes the operation of the Borrow Checker. We use this model to prove the soudness of some core operations and justify the conjecture that the model, as a whole, is sound. Additionally, our model provides a syntactic version of the Borrow Checker, which may be more understandable than the non-syntactic version in Rust.},
|
||||||
|
author = {Reed, Eric},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/Patina$\backslash$: A Formalization of the Rust Programming Language.pdf:pdf},
|
||||||
|
number = {February},
|
||||||
|
pages = {1--37},
|
||||||
|
title = {{Patina: A Formalization of the Rust Programming Language}},
|
||||||
|
year = {2015}
|
||||||
|
}
|
||||||
|
@misc{IEEEspectrum-proglangs,
|
||||||
|
author = {IEEE},
|
||||||
|
title = {{Interactive: The Top Programming Languages 2017}},
|
||||||
|
url = {https://spectrum.ieee.org/static/interactive-the-top-programming-languages-2017},
|
||||||
|
urldate = {2017-09-08},
|
||||||
|
year = {2017}
|
||||||
|
}
|
||||||
|
@article{Mailloux1969,
|
||||||
|
author = {Mailloux, B. J. and Peck, J. E L and Koster, C. H A},
|
||||||
|
doi = {10.1007/BF02163002},
|
||||||
|
file = {:home/steveej/src/steveej/msc-thesis/docs/Algol68-RevisedReport.pdf:pdf},
|
||||||
|
isbn = {978-3-662-38646-0},
|
||||||
|
issn = {0029599X},
|
||||||
|
journal = {Numerische Mathematik},
|
||||||
|
number = {2},
|
||||||
|
pages = {79--218},
|
||||||
|
title = {{Report on the Algorithmic Language ALGOL 68}},
|
||||||
|
volume = {14},
|
||||||
|
year = {1969}
|
||||||
|
}
|
||||||
|
@misc{TockOS,
|
||||||
|
title = {{Tock OS}},
|
||||||
|
url = {https://www.tockos.org/},
|
||||||
|
urldate = {2017-09-22}
|
||||||
|
}
|
||||||
|
@article{Xu2015,
|
||||||
|
abstract = {Since vulnerabilities in Linux kernel are on the increase, attackers have turned their interests into related exploitation techniques. However, compared with numerous researches on exploiting use-after-free vulnerabilities in the user applications, few efforts studied how to exploit use-after-free vulnerabilities in Linux kernel due to the difficulties that mainly come from the uncertainty of the kernel memory layout. Without specific information leakage, attackers could only conduct a blind memory overwriting strategy trying to corrupt the critical part of the kernel, for which the success rate is negligible. In this work, we present a novel memory collision strategy to exploit the use-after-free vulnerabilities in Linux kernel reliably. The insight of our exploit strategy is that a probabilistic memory collision can be constructed according to the widely deployed kernel memory reuse mechanisms, which significantly increases the success rate of the attack. Based on this insight, we present two practical memory collision attacks: An object-based attack that leverages the memory recycling mechanism of the kernel allocator to achieve freed vulnerable object covering, and a physmap-based attack that takes advantage of the overlap between the physmap and the SLAB caches to achieve a more flexible memory manipulation. Our proposed attacks are universal for various Linux kernels of different architectures and could successfully exploit systems with use-after-free vulnerabilities in kernel. Particularly, we achieve privilege escalation on various popular Android devices (kernel version{\textgreater}=4.3) including those with 64-bit processors by exploiting the CVE-2015-3636 use-after-free vulnerability in Linux kernel. To our knowledge, this is the first generic kernel exploit for the latest version of Android. Finally, to defend this kind of memory collision, we propose two corresponding mitigation schemes.},
|
||||||
|
author = {Xu, Wen and Li, Juanru and Shu, Junliang and Yang, Wenbo and Xie, Tianyi and Zhang, Yuanyuan and Gu, Dawu},
|
||||||
|
doi = {10.1145/2810103.2813637},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/From Collision To Exploitation$\backslash$: Unleashing Use-After-Free Vulnerabilities in Linux Kernel.pdf:pdf},
|
||||||
|
isbn = {978-1-4503-3832-5},
|
||||||
|
issn = {15437221},
|
||||||
|
journal = {Ccs},
|
||||||
|
keywords = {linux kernel exploit,memory collision,user-after-free vulnerability},
|
||||||
|
pages = {414--425},
|
||||||
|
title = {{From Collision To Exploitation: Unleashing Use-After-Free Vulnerabilities in Linux Kernel}},
|
||||||
|
url = {http://dl.acm.org/citation.cfm?doid=2810103.2813637},
|
||||||
|
year = {2015}
|
||||||
|
}
|
||||||
|
@misc{MITRE-CWE-635,
|
||||||
|
author = {MITRE},
|
||||||
|
title = {{CWE-635: Weaknesses Used by NVD}},
|
||||||
|
url = {http://cwe.mitre.org/data/definitions/635.html},
|
||||||
|
urldate = {2017-08-05}
|
||||||
|
}
|
||||||
|
@misc{NVD,
|
||||||
|
title = {{National Vulnerability Database}},
|
||||||
|
url = {https://nvd.nist.gov/},
|
||||||
|
urldate = {2017-08-05}
|
||||||
|
}
|
||||||
|
@article{Jim2002,
|
||||||
|
abstract = {Cyclone is a safe dialect of C. It has been designed from the ground up to prevent the buer overflows, format string attacks, and memory management errors that are common in C programs, while retaining C's syntax and semantics. This paper examines safety violations enabled by C's design, and shows how Cyclone avoids them, without giving up C's hallmark control over low-level details such as data representation and memory management.},
|
||||||
|
author = {Jim, Trevor and Morrisett, Greg and Grossman, Dan and Hicks, Michael and Cheney, James and Wang, Yanling},
|
||||||
|
isbn = {1-880446-00-6},
|
||||||
|
journal = {USENIX Annual Technical Conference},
|
||||||
|
pages = {275--288},
|
||||||
|
title = {{Cyclone: A safe dialect of C}},
|
||||||
|
url = {http://www.usenix.org/events/usenix02/full{\_}papers/jim/jim{\_}html/},
|
||||||
|
year = {2002}
|
||||||
|
}
|
||||||
|
@misc{MITRE-CWE-633,
|
||||||
|
author = {MITRE},
|
||||||
|
title = {{CWE-633: Weaknesses that Affect Memory}},
|
||||||
|
url = {http://cwe.mitre.org/data/definitions/633.html},
|
||||||
|
urldate = {2017-08-31},
|
||||||
|
year = {2017}
|
||||||
|
}
|
||||||
|
@misc{MITRE-CWE-119,
|
||||||
|
author = {MITRE},
|
||||||
|
booktitle = {2.11},
|
||||||
|
title = {{CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer}},
|
||||||
|
url = {http://cwe.mitre.org/data/definitions/119.html},
|
||||||
|
urldate = {2017-08-31},
|
||||||
|
year = {2017}
|
||||||
|
}
|
||||||
|
@misc{MITRE-CWE-122,
|
||||||
|
author = {MITRE},
|
||||||
|
title = {{CWE-122: Heap-based Buffer Overflow}},
|
||||||
|
url = {http://cwe.mitre.org/data/definitions/122.html},
|
||||||
|
urldate = {2017-09-26}
|
||||||
|
}
|
||||||
|
@inproceedings{Kuznetsov2014,
|
||||||
|
abstract = {Systems code is often written in low-level languages like C/C++, which offer many benefits but also dele- gate memory management to programmers. This invites memory safety bugs that attackers can exploit to divert control flow and compromise the system. Deployed de- fense mechanisms (e.g., ASLR, DEP) are incomplete, and stronger defense mechanisms (e.g., CFI) often have high overhead and limited guarantees [19, 15, 9]. We introduce code-pointer integrity (CPI), a new de- sign point that guarantees the integrity of all code point- ers in a program (e.g., function pointers, saved return ad- dresses) and thereby prevents all control-flow hijack at- tacks, including return-oriented programming. We also introduce code-pointer separation (CPS), a relaxation of CPI with better performance properties. CPI and CPS offer substantially better security-to-overhead ratios than the state of the art, they are practical (we protect a complete FreeBSD system and over 100 packages like apache and postgresql), effective (prevent all attacks in the RIPE benchmark), and efficient: on SPEC CPU2006, CPS averages 1.2{\%} overhead for C and 1.9{\%} for C/C++, while CPI's overhead is 2.9{\%} for C and 8.4{\%} for C/C++. A prototype implementation of CPI and CPS can be obtained from http://levee.epfl.ch. 1},
|
||||||
|
author = {Kuznetsov, Volodymyr and Szekeres, L{\'{a}}szl{\'{o}} and Payer, Mathias},
|
||||||
|
booktitle = {Proceedings of the 11th USENIX Symposium on Operating Systems Design and Implementation},
|
||||||
|
isbn = {9781931971164},
|
||||||
|
pages = {147--163},
|
||||||
|
title = {{Code-pointer integrity}},
|
||||||
|
url = {https://www.usenix.org/conference/osdi14/technical-sessions/presentation/kuznetsov{\%}5Cnhttps://www.usenix.org/system/files/conference/osdi14/osdi14-paper-kuznetsov.pdf?utm{\_}source=dlvr.it{\&}utm{\_}medium=tumblr},
|
||||||
year = {2014}
|
year = {2014}
|
||||||
}
|
}
|
||||||
@book{Sarton1975,
|
@article{Lattner2005,
|
||||||
author = {Sarton, George},
|
abstract = {The LLVM Compiler Infrastructure (http://llvm.cs. uiuc.edu) is a$\backslash$nrobust system that is well suited for a wide variety of research$\backslash$nand development work. This brief paper introduces the LLVM system$\backslash$nand provides pointers to more extensive documentation, complementing$\backslash$nthe tutorial presented at LCPC.},
|
||||||
doi = {10.1007/978-3-319-33138-6},
|
|
||||||
file = {:home/steveej/src/github/steveej/msc-thesis/papers/A Computing History Primer.pdf:pdf},
|
|
||||||
isbn = {0882751727 (o.c.)},
|
|
||||||
pages = {145},
|
|
||||||
title = {{Introduction to the history of science.}},
|
|
||||||
year = {1975}
|
|
||||||
}
|
|
||||||
@article{Menage2007,
|
|
||||||
abstract = {While Linux provides copious monitoring and control options for individual processes, it has less support for applying the same operations efficiently to related groups of processes. This has led to multiple proposals for subtly different mechanisms for process aggregation for resource control and isolation. Even though some of these efforts could conceptually operate well together, merging each of them in their current states would lead to duplication in core kernel data structures/routines. The Containers framework, based on the existing cpusets mechanism, provides the generic process group- ing features required by the various different resource controllers and other process-affecting subsystems. The result is to reduce the code (and kernel impact) required for such subsystems, and provide a common interface with greater scope for co-operation. This paper looks at the challenges in meeting the needs of all the stakeholders, which include low overhead, feature richness, completeness and flexible groupings. We demonstrate how to extend containers by writing resource control and monitoring components, we also look at how to implement namespaces and cpusets on top of the framework.},
|
|
||||||
author = {Menage, Paul B},
|
|
||||||
file = {:home/steveej/src/github/steveej/msc-thesis/papers/Adding Generic Process Containers to the Linux Kernel.pdf:pdf},
|
|
||||||
journal = {Proceedings of the Ottawa Linux Symposium},
|
|
||||||
pages = {45--58},
|
|
||||||
title = {{Adding Generic Process Containers to the Linux Kernel}},
|
|
||||||
url = {http://www.kernel.org/doc/ols/2007/ols2007v2-pages-45-58.pdf},
|
|
||||||
year = {2007}
|
|
||||||
}
|
|
||||||
@inproceedings{Reshetova2014,
|
|
||||||
abstract = {The need for flexible, low-overhead virtualization is evident on many fronts ranging from high-density cloud servers to mobile devices. During the past decade OS-level virtualization has emerged as a new, efficient approach for virtualization, with implementations in multiple different Unix-based systems. Despite its popularity, there has been no systematic study of OS-level virtualization from the point of view of security. In this report, we conduct a comparative study of several OS-level virtualization systems, discuss their security and identify some gaps in current solutions.},
|
|
||||||
archivePrefix = {arXiv},
|
archivePrefix = {arXiv},
|
||||||
arxivId = {1407.4245},
|
arxivId = {9780201398298},
|
||||||
author = {Reshetova, Elena and Karhunen, Janne and Nyman, Thomas and Asokan, N},
|
author = {Lattner, Chris and Adve, Vikram},
|
||||||
booktitle = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)},
|
doi = {10.1007/11532378_2},
|
||||||
doi = {10.1007/978-3-319-11599-3_5},
|
eprint = {9780201398298},
|
||||||
eprint = {1407.4245},
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/The LLVM Compiler Framework and Infrastructure Tutorial.pdf:pdf},
|
||||||
file = {:home/steveej/.local/share/data/Mendeley Ltd./Mendeley Desktop/Downloaded/Reshetova et al. - 2014 - Security of OS-level virtualization technologies(5).pdf:pdf},
|
isbn = {978-3-540-28009-5},
|
||||||
isbn = {9783319115986},
|
issn = {03029743},
|
||||||
issn = {16113349},
|
journal = {Languages and Compilers for High Performance Computing},
|
||||||
pages = {77--93},
|
number = {Part 1},
|
||||||
title = {{Security of OS-level virtualization technologies}},
|
pages = {15--16},
|
||||||
volume = {8788},
|
pmid = {4520227},
|
||||||
year = {2014}
|
title = {{The LLVM Compiler Framework and Infrastructure Tutorial}},
|
||||||
|
url = {http://dx.doi.org/10.1007/11532378{\_}2},
|
||||||
|
year = {2005}
|
||||||
}
|
}
|
||||||
@article{Felter2014,
|
@article{Nilsson2017,
|
||||||
abstract = {IBM Research Report Isolation and resource control for cloud applications has traditionally been achieve through the use of virtual machines. Deploying applications in a VM results in reduced performance due to the extra levels of abstraction. In a cloud environment, this results in loss efficiency for the infrastructure. Newer advances in container-based virtualization simplifies the deployment of applications while isolating them from one another. In this paper, we explore the performance of traditional virtual machine deployments, and contrast them with the use of Linux containers. We use a suite of workloads that stress the CPU, memory, storage and networking resources. Our results show that containers result in equal or better performance than VM in almost all cases. Both VMs and containers require tuning to support I/O-intensive applicaions. We also discuss the implications of our performance results for future cloud architecture.},
|
author = {Nilsson, Fredrik},
|
||||||
author = {Felter, Wes and Ferreira, Alexandre and Rajamony, Ram and Rubio, Juan},
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/A Rust-based Runtime for the Internet of Things.pdf:pdf},
|
||||||
doi = {10.1109/ISPASS.2015.7095802},
|
title = {{A Rust-based Runtime for the Internet of Things}},
|
||||||
file = {:home/steveej/.local/share/data/Mendeley Ltd./Mendeley Desktop/Downloaded/Felter et al. - 2014 - An Updated Performance Comparison of Virtual Machines and Linux Containers(3).pdf:pdf},
|
year = {2017}
|
||||||
isbn = {9781479919574},
|
}
|
||||||
journal = {Technology},
|
@misc{MITRE-CWE,
|
||||||
keywords = {cloud computing,performance,virtualization},
|
author = {MITRE},
|
||||||
pages = {171--172},
|
title = {{CWE - Common Weakness Enumeration}},
|
||||||
title = {{An Updated Performance Comparison of Virtual Machines and Linux Containers}},
|
url = {http://cwe.mitre.org},
|
||||||
url = {http://domino.research.ibm.com/library/CyberDig.nsf/papers/0929052195DD819C85257D2300681E7B/{\$}File/rc25482.pdf},
|
urldate = {2017-08-31},
|
||||||
volume = {25482},
|
year = {2017}
|
||||||
year = {2014}
|
}
|
||||||
|
@article{Szekeres2013,
|
||||||
|
abstract = {Memory corruption bugs in software written in low-level languages like C or C++ are one of the oldest problems in computer security. The lack of safety in these languages allows attackers to alter the program's behavior or take full control over it by hijacking its control flow. This problem has existed for more than 30 years and a vast number of potential solutions have been proposed, yet memory corruption attacks continue to pose a serious threat. Real world exploits show that all currently deployed protections can be defeated. This paper sheds light on the primary reasons for this by describing attacks that succeed on today's systems. We systematize the current knowledge about various protection techniques by setting up a general model for memory corrup- tion attacks. Using this model we show what policies can stop which attacks. The model identifies weaknesses of currently deployed techniques, as well as other proposed protections enforcing stricter policies. We analyze the reasons why protection mechanisms imple- menting stricter polices are not deployed. To achieve wide adoption, protection mechanisms must support a multitude of features and must satisfy a host of requirements. Especially important is performance, as experience shows that only solutions whose overhead is in reasonable bounds get deployed. A comparison of different enforceable policies helps de- signers of new protection mechanisms in finding the balance between effectiveness (security) and efficiency.We identify some open research problems, and provide suggestions on improving the adoption of newer techniques.},
|
||||||
|
author = {Szekeres, L??szl?? and Payer, Mathias and Wei, Tao and Song, Dawn},
|
||||||
|
doi = {10.1109/SP.2013.13},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/SoK$\backslash$: Eternal War in Memory.pdf:pdf},
|
||||||
|
isbn = {9780769549774},
|
||||||
|
issn = {10816011},
|
||||||
|
journal = {Proceedings - IEEE Symposium on Security and Privacy},
|
||||||
|
pages = {48--62},
|
||||||
|
title = {{SoK: Eternal war in memory}},
|
||||||
|
year = {2013}
|
||||||
|
}
|
||||||
|
@article{Arpaci-Dusseau2015,
|
||||||
|
abstract = {A book covering the fundamentals of operating systems, including virtualization of the CPU and memory, threads and concurrency, and file and storage systems. Written by professors active in the field for 20 years, this text has been developed in the classrooms of the University of Wisconsin-Madison, and has been used in the instruction of thousands of students.},
|
||||||
|
author = {{Arpaci-Dusseau Remzi}, Arpaci-Dusseau Andrea},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/operating{\_}systems{\_}{\_}three{\_}easy{\_}pieces{\_}{\_}electronic{\_}version{\_}0{\_}91{\_}.pdf:pdf},
|
||||||
|
journal = {Arpaci-Dusseau},
|
||||||
|
number = {0.91},
|
||||||
|
pages = {665},
|
||||||
|
title = {{Operating Systems: Three Easy Pieces}},
|
||||||
|
volume = {Electronic},
|
||||||
|
year = {2015}
|
||||||
|
}
|
||||||
|
@article{Kowshik2002,
|
||||||
|
abstract = {This paper considers the problem of providing safe programming support and enabling secure online software upgrades for control software in real-time control systems. In such systems, offline techniques for ensuring code safety are greatly preferable to online techniques. We propose a language called Control-C that is essentially a subset of C, but with key restrictions designed to ensure that memory safety of code can be verified entirely by static checking, under certain system assumptions. The language permits pointer-based data structures, restricted dynamic memory allocation, and restricted array operations, without requiring any runtime checks on memory operations and without garbage collection. The language restrictions have been chosen based on an understanding of both compiler technology and the needs of real-time control systems. The paper describes the language design and a compiler implementation for Control-C. We use control codes from three different experimental control systems to evaluate the suitability of the language for these codes, the effort required to port them to Control-C, and the effectiveness of the compiler in detecting a wide range of potential security violations for one of the systems.},
|
||||||
|
author = {Kowshik, Sumant and Dhurjati, Dinakar and Adve, Vikram},
|
||||||
|
doi = {10.1145/581677.581678},
|
||||||
|
file = {:home/steveej/src/steveej/msc-thesis/docs/Ensuring Code Safety Without Runtime Checks for Real-Time Control Systems.pdf:pdf},
|
||||||
|
isbn = {1581135750},
|
||||||
|
journal = {Proceedings of the international conference on Compilers, architecture, and synthesis for embedded systems - CASES '02},
|
||||||
|
keywords = {compiler,control,programming language,real-time,static analy-},
|
||||||
|
pages = {288},
|
||||||
|
title = {{Ensuring code safety without runtime checks for real-time control systems}},
|
||||||
|
url = {http://portal.acm.org/citation.cfm?doid=581630.581678},
|
||||||
|
year = {2002}
|
||||||
|
}
|
||||||
|
@misc{TheStackClash,
|
||||||
|
author = {Advisory, Qualys Security},
|
||||||
|
file = {:home/steveej/src/steveej/msc-thesis/docs/stack-clash.txt:txt},
|
||||||
|
title = {{The Stack Clash}},
|
||||||
|
url = {https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt}
|
||||||
|
}
|
||||||
|
@book{AMD64Vol1,
|
||||||
|
author = {AMD},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/AMD64 Architecture Programmer's Manual Volume 1$\backslash$: Application Programming.pdf:pdf},
|
||||||
|
keywords = {AMD64,SIMD,extended media instructions,legacy m},
|
||||||
|
number = {26568},
|
||||||
|
title = {{AMD64 Architecture Programmer's Manual Volume 1: Application Programming}},
|
||||||
|
volume = {4},
|
||||||
|
year = {2012}
|
||||||
|
}
|
||||||
|
@article{Chisnall2015,
|
||||||
|
abstract = {We propose a new memory-safe interpretation of the C ab-stract machine that provides stronger protection to benefit security and debugging. Despite ambiguities in the specifi-cation intended to provide implementation flexibility, con-temporary implementations of C have converged on a mem-ory model similar to the PDP-11, the original target for C. This model lacks support for memory safety despite well-documented impacts on security and reliability. Attempts to change this model are often hampered by as-sumptions embedded in a large body of existing C code, dat-ing back to the memory model exposed by the original C compiler for the PDP-11. Our experience with attempting to implement a memory-safe variant of C on the CHERI ex-perimental microprocessor led us to identify a number of problematic idioms. We describe these as well as their in-teraction with existing memory safety schemes and the as-sumptions that they make beyond the requirements of the C specification. Finally, we refine the CHERI ISA and abstract model for C, by combining elements of the CHERI capabil-ity model and fat pointers, and present a softcore CPU that implements a C abstract machine that can run legacy C code with strong memory protection guarantees.},
|
||||||
|
author = {Chisnall, David and Rothwell, Colin and Watson, Robert N M and Woodruff, Jonathan and Vadera, Munraj and Moore, Simon W and Roe, Michael and Davis, Brooks and Neumann, Peter G},
|
||||||
|
doi = {10.1145/2694344.2694367},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/Beyond the PDP-11$\backslash$: Architectural support for a memory-safe C abstract machine.pdf:pdf},
|
||||||
|
isbn = {9781450328357},
|
||||||
|
issn = {01635964},
|
||||||
|
journal = {Proceedings of the Twentieth International Conference on Architectural Support for Programming Languages and Operating Systems},
|
||||||
|
pages = {117--130},
|
||||||
|
title = {{Beyond the PDP-11 : Architectural support for a memory-safe C abstract machine}},
|
||||||
|
url = {http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201503-asplos2015-cheri-cmachine.pdf},
|
||||||
|
year = {2015}
|
||||||
|
}
|
||||||
|
@article{GCC540,
|
||||||
|
abstract = {This manual documents how to use the GNU compilers, as well as their features and incom- patibilities, and how to report bugs. It corresponds to the compilers (GCC) version 5.4.0. The internals of the GNU compilers, including how to port them to new targets and some information about how to write front ends for new languages, are documented in a separate manual. See Section Introduction in GNU Compiler Collection (GCC) Internals.},
|
||||||
|
author = {Stallman, Richard M},
|
||||||
|
file = {:home/steveej/src/steveej/msc-thesis/docs/gcc-5.4.0.pdf:pdf},
|
||||||
|
isbn = {188211437X},
|
||||||
|
journal = {Development},
|
||||||
|
title = {{Using the GNU Compiler Collection}},
|
||||||
|
url = {https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc.pdf}
|
||||||
|
}
|
||||||
|
@article{Getreu2016,
|
||||||
|
annote = {- runtime checkis are expensive
|
||||||
|
|
||||||
|
- critical with energy restriction on the target device},
|
||||||
|
author = {Getreu, Jens},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/Embedded System Security with Rust - Case Study of Heartbleed.pdf:pdf},
|
||||||
|
pages = {1--24},
|
||||||
|
title = {{Embedded System Security with Rust}},
|
||||||
|
year = {2016}
|
||||||
|
}
|
||||||
|
@book{AMD64Vol2,
|
||||||
|
author = {AMD},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/AMD64 Architecture Programmer's Manual Volume 2$\backslash$: System Programming.pdf:pdf},
|
||||||
|
keywords = {24593,AMD64 Architecture Programmer's Manual Volume 2: S},
|
||||||
|
number = {24592},
|
||||||
|
title = {{AMD64 Architecture Programmer's Manual Volume 2: System Programming}},
|
||||||
|
volume = {1},
|
||||||
|
year = {2012}
|
||||||
|
}
|
||||||
|
@article{Caballero2012,
|
||||||
|
abstract = {Use-after-free vulnerabilities are rapidly growing in popularity, especially for exploiting web browsers. Use-after-free (and double-free) vulnerabilities are caused by a program operating on a dangling pointer. In this work we propose early detection, a novel runtime approach for finding and diagnosing use-after-free and double-free vulnerabilities. While previous work focuses on the creation of the vulnerability (i.e., the use of a dangling pointer), early detection shifts the focus to the creation of the dangling pointer(s) at the root of the vulnerability. Early detection increases the effectiveness of testing by identifying unsafe dangling pointers in executions where they are created but not used. It also accelerates vulnerability analysis and minimizes the risk of incomplete fixes, by automatically collecting information about all dangling pointers involved in the vulnerability. We implement our early detection technique in a tool called Undangle. We evaluate Undangle for vulnerability analysis on 8 real-world vulnerabilities. The analysis uncovers that two separate vulnerabilities in Firefox had a common root cause and that their patches did not completely fix the underlying bug. We also evaluate Undangle for testing on the Firefox web browser identifying a potential vulnerability.},
|
||||||
|
author = {Caballero, Juan and Grieco, Gustavo and Marron, Mark and Nappa, Antonio},
|
||||||
|
doi = {10.1145/2338965.2336769},
|
||||||
|
isbn = {9781450314541},
|
||||||
|
issn = {1450314546},
|
||||||
|
journal = {ISSTA},
|
||||||
|
keywords = {automated testing,binary analysis,debugging,dynamic analysis},
|
||||||
|
pages = {133},
|
||||||
|
title = {{Undangle: early detection of dangling pointers in use-after-free and double-free vulnerabilities}},
|
||||||
|
url = {http://dl.acm.org/citation.cfm?doid=2338965.2336769},
|
||||||
|
year = {2012}
|
||||||
|
}
|
||||||
|
@article{Levy2015a,
|
||||||
|
abstract = {Rust, a new systems programming language, provides compile-time memory safety checks to help eliminate runtime bugs that manifest from improper memory management. This feature is advantageous for operating system development, and especially for embedded OS development, where recovery and debugging are particularly challenging. However, embedded platforms are highly event-based, and Rust's memory safety mechanisms largely presume threads. In our experience developing an operating system for embedded systems in Rust, we have found that Rust's ownership model prevents otherwise safe resource sharing common in the embedded domain, conflicts with the reality of hardware resources, and hinders using closures for programming asynchronously. We describe these experiences and how they relate to memory safety as well as illustrate our workarounds that preserve the safety guarantees to the largest extent possible. In addition, we draw from our experience to propose a new language extension to Rust that would enable it to provide better memory safety tools for event-driven platforms.},
|
||||||
|
author = {Levy, Amit and Andersen, Michael P. and Campbell, Bradford and Culler, David and Dutta, Prabal and Ghena, Branden and Levis, Philip and Pannuto, Pat},
|
||||||
|
doi = {10.1145/2818302.2818306},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/tock-plos2015.pdf:pdf},
|
||||||
|
isbn = {9781450339421},
|
||||||
|
journal = {PLOS: Workshop on Programming Languages and Operating Systems},
|
||||||
|
keywords = {embedded operating systems,linear types,ownership,rust},
|
||||||
|
pages = {21--26},
|
||||||
|
title = {{Ownership is Theft: Experiences Building an Embedded OS in Rust}},
|
||||||
|
url = {http://dl.acm.org/citation.cfm?id=2818302.2818306},
|
||||||
|
year = {2015}
|
||||||
|
}
|
||||||
|
@article{Corporation2011a,
|
||||||
|
abstract = {The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volume 1, describes the basic architecture and programming environment of Intel 64 and IA-32 processors. The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volumes 2A {\&} 2B, describe the instruction set of the processor and the opcode struc- ture. These volumes apply to application programmers and to programmers who write operating systems or executives. The Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volumes 3A {\&} 3B, describe the operating-system support environment of Intel 64 and IA-32 processors. These volumes target operating- system and BIOS designers. In addition, the Intel{\{}$\backslash$textregistered{\}} 64 and IA-32 Architectures Software Developer's Manual, Volume 3B, addresses the programming environment for classes of software that host operating systems.},
|
||||||
|
author = {Corporation, Intel},
|
||||||
|
doi = {10.1109/MAHC.2010.22},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/docs/64-ia-32-architectures-software-developer-vol-1-manual.pdf:pdf},
|
||||||
|
isbn = {253665-057US},
|
||||||
|
issn = {15222594},
|
||||||
|
journal = {System},
|
||||||
|
keywords = {253665,64,ia 32 architecture},
|
||||||
|
number = {253665},
|
||||||
|
title = {{Intel {\textregistered} 64 and IA-32 Architectures Software Developer ' s Manual Volume 1}},
|
||||||
|
volume = {1},
|
||||||
|
year = {2011}
|
||||||
}
|
}
|
||||||
|
|
|
||||||
|
|
@ -1,28 +1,72 @@
|
||||||
|
% // vim: set ft=tex:
|
||||||
\documentclass[12pt,a4paper]{report}
|
\documentclass[12pt,a4paper]{report}
|
||||||
|
|
||||||
|
%\overfullrule=1cm
|
||||||
|
|
||||||
\usepackage[utf8]{inputenc}
|
\usepackage[utf8]{inputenc}
|
||||||
|
|
||||||
\usepackage{titlesec} % titleformat
|
\usepackage{titlesec} % titleformat
|
||||||
\usepackage{blindtext,color,fancyhdr}
|
\usepackage{blindtext,color,fancyhdr}
|
||||||
|
|
||||||
\usepackage{geometry}
|
\usepackage{geometry}
|
||||||
\geometry{a4paper, top=25mm, left=30mm, right=35mm, bottom=35mm, headsep=10mm, footskip=12mm}
|
\geometry{a4paper, top=25mm, left=35mm, right=30mm, bottom=35mm, headsep=10mm, footskip=12mm}
|
||||||
|
|
||||||
%\usepackage{multirow,tabularx,tabu}
|
\usepackage{multirow,tabularx,tabu}
|
||||||
\usepackage{ctable,multirow}
|
\usepackage{booktabs}
|
||||||
|
\usepackage{spreadtab}
|
||||||
|
\usepackage{hhline}
|
||||||
|
\renewcommand{\arraystretch}{1.2}
|
||||||
|
|
||||||
\usepackage{cite}
|
\usepackage{colortbl}
|
||||||
\bibliographystyle{plain}
|
\usepackage[dvipsnames]{xcolor}
|
||||||
|
|
||||||
\usepackage[hyphens]{url}
|
\usepackage[backend=biber,style=numeric,citestyle=numeric,url=true]{biblatex}
|
||||||
|
\addbibresource{thesis.bib}
|
||||||
|
|
||||||
|
%\usepackage[hyphens]{url}
|
||||||
\Urlmuskip = 0mu plus 1mu
|
\Urlmuskip = 0mu plus 1mu
|
||||||
|
|
||||||
|
%\hyphenpenalty=1
|
||||||
|
\pretolerance=5000
|
||||||
|
\tolerance=5000
|
||||||
|
%\exhyphenpenalty=1
|
||||||
|
|
||||||
\usepackage[numberedsection,toc,numberline,nopostdot]{glossaries}
|
\usepackage[numberedsection,toc,numberline,nopostdot]{glossaries}
|
||||||
\makenoidxglossaries
|
\makenoidxglossaries
|
||||||
|
|
||||||
\newcommand{\topic}{A Declarative And Reproducible Approach To The Creation Of Software-Application Container Images}
|
\usepackage{listings}
|
||||||
|
\providecommand*{\listingautorefname}{Listing}
|
||||||
|
\usepackage{minted}
|
||||||
|
\usepackage{graphicx}
|
||||||
|
\usepackage{placeins}
|
||||||
|
\usepackage{tikz}
|
||||||
|
\usetikzlibrary{tikzmark,mindmap}
|
||||||
|
\usetikzlibrary{chains,shapes.arrows, arrows, positioning,decorations.pathreplacing,bending}
|
||||||
|
\usetikzlibrary{calc}
|
||||||
|
\usetikzlibrary{matrix,shapes,arrows,positioning}
|
||||||
|
\usetikzlibrary{shapes.geometric, arrows}
|
||||||
|
\usetikzlibrary{chains,arrows.meta,decorations.pathmorphing,quotes}
|
||||||
|
\usepackage{smartdiagram}
|
||||||
|
\usesmartdiagramlibrary{additions}
|
||||||
|
\usepackage{color}
|
||||||
|
\usepackage[definitionLists,hashEnumerators,smartEllipses,hybrid]{markdown}
|
||||||
|
%\usepackage[fencedCode,inlineFootnotes,citations,definitionLists,hashEnumerators,smartEllipses,hybrid]{markdown}
|
||||||
|
|
||||||
|
|
||||||
|
\tikzset{/minted/basename/.initial=minted}
|
||||||
|
\appto\theFancyVerbLine{\tikzmark{\pgfkeysvalueof{/minted/basename}\arabic{FancyVerbLine}}}
|
||||||
|
|
||||||
|
\usepackage{amsmath}
|
||||||
|
\usepackage{amssymb}
|
||||||
|
\usepackage{caption}
|
||||||
|
\usepackage{subcaption}
|
||||||
|
\usepackage{wrapfig}
|
||||||
|
\usepackage[parfill]{parskip}
|
||||||
|
|
||||||
|
\newcommand{\topic}{Guarantees On In-Kernel Memory-Safety Using Rust's Static Code Analysis}
|
||||||
\newcommand{\authorOne}{Stefan Junker}
|
\newcommand{\authorOne}{Stefan Junker}
|
||||||
|
\newcommand{\authorOneBirthDate}{23.12.1986}
|
||||||
|
\newcommand{\authorOneBirthCity}{Rottweil}
|
||||||
\newcommand{\authorOneInit}{SJ}
|
\newcommand{\authorOneInit}{SJ}
|
||||||
\newcommand{\authorOnestreet}{Alemannenstr. 7}
|
\newcommand{\authorOnestreet}{Alemannenstr. 7}
|
||||||
\newcommand{\authorOnezip}{78467}
|
\newcommand{\authorOnezip}{78467}
|
||||||
|
|
@ -30,16 +74,28 @@
|
||||||
\newcommand{\authorOneCountry}{Germany}
|
\newcommand{\authorOneCountry}{Germany}
|
||||||
\newcommand{\authorOneId}{283751}
|
\newcommand{\authorOneId}{283751}
|
||||||
\newcommand{\supervisorOne}{Prof. Dr. Michael Mächtel}
|
\newcommand{\supervisorOne}{Prof. Dr. Michael Mächtel}
|
||||||
\newcommand{\supervisorTwo}{Jürgen Keppler}
|
\newcommand{\supervisorTwo}{Felix Schuckert}
|
||||||
\newcommand{\studies}{TODO studies}
|
\newcommand{\studies}{Information Technology - Embedded And Mobile Systems}
|
||||||
\newcommand{\startdate}{2016/9/1}
|
\newcommand{\startdate}{2017/4/1}
|
||||||
\newcommand{\submitdate}{2017/2/28}
|
\newcommand{\submitdate}{2017/9/29}
|
||||||
\newcommand{\buzzwords}{TODO buzzwords}
|
\newcommand{\buzzwords}{memory-safety, operating system development, rust, static software analysis, software vulnerability}
|
||||||
|
\renewcommand{\abstract}{%
|
||||||
|
This study evaluated Rust's guarantees on memory safety in the OS through static analysis.
|
||||||
|
Static analysis was identified as a requirement due to the assumption that humans tend to make mistakes and C was found to be an error prone language.
|
||||||
|
Rust, as an affine-typed borrow- and lifetime-checked systems language that is equipped with an ownership model, is considered a viable candidate for replacing C for today's OS development.
|
||||||
|
After identifying common weaknesses of memory vulnerabilities and their manifestations, the choice of programming language was verified as the most effective mitigation attempt.
|
||||||
|
Rust was chosen to act as a new candidate, and was found to be effective against common errors in buffer handling due to its ownership model and strong type system.
|
||||||
|
The language shown to be less error prone in memory intensive tasks like buffer handling, which has been identified as a common cause in software vulnerabilities.
|
||||||
|
After experimentation with various stack protection scenarios and implementing preemptive multitasking on top of interemezzOS, the downside was discovered that Rust cannot statically detect stack overflows of any type.
|
||||||
|
Implementing this detection was considered beyond scope, although requirements could be identified for future reference.
|
||||||
|
It was concluded that Rust's static checks of all kinds are a big improvement in OS development, where object orientation and other paradigms are not simple to manage.
|
||||||
|
Despite the failed hypotheses of guaranteeing full memory-safety in OS development, Rust is suggested as the language for today's and future OS development.
|
||||||
|
}
|
||||||
|
|
||||||
% Numbered Subsubsections
|
% Numbered Subsubsections
|
||||||
\setcounter{secnumdepth}{3}
|
\setcounter{secnumdepth}{3}
|
||||||
|
|
||||||
\date{Wintersemester 2016/2017}
|
\date{}
|
||||||
\title{\topic}
|
\title{\topic}
|
||||||
|
|
||||||
\author{authorOne}
|
\author{authorOne}
|
||||||
|
|
@ -85,30 +141,120 @@
|
||||||
\titlespacing*{\chapter}{0cm}{-1cm}{0.75cm}
|
\titlespacing*{\chapter}{0cm}{-1cm}{0.75cm}
|
||||||
\titleformat{\chapter}[hang]{\normalfont\Large\bfseries}{\thechapter}{0.5cm}{}
|
\titleformat{\chapter}[hang]{\normalfont\Large\bfseries}{\thechapter}{0.5cm}{}
|
||||||
|
|
||||||
|
\usepackage{hyperref}
|
||||||
|
\usepackage{cleveref}
|
||||||
|
|
||||||
\makeatletter
|
\makeatletter
|
||||||
|
|
||||||
|
\newcommand{\cnameref}[1]{\cref{#1} \textit{(\nameref{#1})}}
|
||||||
|
\newcommand{\Cnameref}[1]{\Cref{#1} \textit{(\nameref{#1})}}
|
||||||
|
|
||||||
|
\newcommand{\cpnameref}[1]{\cref{#1} \textit{(\nameref{#1}, \cpageref{#1})}}
|
||||||
|
\newcommand{\Cpnameref}[1]{\Cref{#1} \textit{(\nameref{#1}, \cpageref{#1})}}
|
||||||
|
|
||||||
|
\newcommand{\cnamepref}[1]{\cref{#1} \textit{(\nameref{#1}, \cpageref{#1})}}
|
||||||
|
\newcommand{\Cnamepref}[1]{\Cref{#1} \textit{(\nameref{#1}, \cpageref{#1})}}
|
||||||
|
|
||||||
%\renewcommand\paragraph{\startsection{paragraph}{4}{\z}%
|
%\renewcommand\paragraph{\startsection{paragraph}{4}{\z}%
|
||||||
% {-3.25ex\plus -1ex \minus -.2ex}%
|
% {-3.25ex\plus -1ex \minus -.2ex}%
|
||||||
% {0.0001pt \plus 0.2ex}%
|
% {0.0001pt \plus 0.2ex}%
|
||||||
% {\normalfont\normalsize\bfseries}}
|
% {\normalfont\normalsize\bfseries}}
|
||||||
\renewcommand\subparagraph{\startsection{subparagraph}{5}{\z}%
|
%\renewcommand\subparagraph{\startsection{subparagraph}{5}{\z}%
|
||||||
{-3.25ex\plus -1ex \minus -.2ex}%
|
% {-3.25ex\plus -1ex \minus -.2ex}%
|
||||||
{0.0001pt \plus 0.2ex}%
|
% {0.0001pt \plus 0.2ex}%
|
||||||
{\normalfont\normalsize\bfseries}}
|
% {\normalfont\normalsize\bfseries}}
|
||||||
|
|
||||||
|
\newcommand{\iitemA}{\setlength\itemindent{0pt}\item}
|
||||||
|
\newcommand{\iitemB}{\setlength\itemindent{25pt}\item}
|
||||||
|
\newcommand{\iitemC}{\setlength\itemindent{50pt}\item}
|
||||||
|
|
||||||
|
\let\Partmark\partmark
|
||||||
|
\def\partmark#1{\def\Partname{#1}\Partmark{#1}}
|
||||||
|
\let\Chaptermark\chaptermark
|
||||||
|
\def\chaptermark#1{\def\Chaptername{#1}\Chaptermark{#1}}
|
||||||
|
\let\Sectionmark\sectionmark
|
||||||
|
\def\sectionmark#1{\def\Sectionname{#1}\Sectionmark{#1}}
|
||||||
|
\let\Subsectionmark\subsectionmark
|
||||||
|
\def\subsectionmark#1{\def\Subsectionname{#1}\Subsectionmark{#1}}
|
||||||
|
\let\Subsubsectionmark\subsubsectionmark
|
||||||
|
\def\subsubsectionmark#1{\def\Subsubsectionname{#1}\Subsubsectionmark{#1}}
|
||||||
|
|
||||||
|
|
||||||
|
\newenvironment{compactminted}{%
|
||||||
|
\VerbatimEnvironment
|
||||||
|
\let\FV@ListVSpace\relax
|
||||||
|
\begin{minted}}%
|
||||||
|
{\end{minted}}
|
||||||
|
|
||||||
|
\tikzset{west above/.code=\tikz@lib@place@handle@{#1}{south west}{0}{1}{north west}{1}}
|
||||||
|
\tikzset{west below/.code=\tikz@lib@place@handle@{#1}{north west}{0}{-1}{south west}{1}}
|
||||||
|
\tikzset{east above/.code=\tikz@lib@place@handle@{#1}{south east}{0}{1}{north east}{1}}
|
||||||
|
\tikzset{east below/.code=\tikz@lib@place@handle@{#1}{north east}{0}{-1}{south east}{1}}
|
||||||
|
|
||||||
|
% Tikzmark code helpers
|
||||||
|
\newcommand{\tikzmarkprefix}{\pgfkeysvalueof{/tikz/tikzmark prefix}}
|
||||||
|
\newcommand{\tikzmarkcountprep}[1]{%
|
||||||
|
\tikzset{tikzmark prefix=#1}%
|
||||||
|
\newcounter{Tikzcounter#1}%
|
||||||
|
\setcounter{Tikzcounter#1}{0}%
|
||||||
|
}
|
||||||
|
\newcommand{\tikzmarkcount}[1][\tikzmarkprefix]{%
|
||||||
|
\stepcounter{Tikzcounter#1}%
|
||||||
|
\tikzmark{\arabic{Tikzcounter#1}}%
|
||||||
|
}
|
||||||
|
\newcommand{\tikzmarkgetcount}[1][\tikzmarkprefix]{%
|
||||||
|
\expandafter\arabic\expandafter{Tikzcounter#1}%
|
||||||
|
}
|
||||||
|
\newcommand{\tikzmarkcircle}[1]{%
|
||||||
|
\tikz[baseline=-0.77ex]\fill circle[fill=black,radius=1.1ex] node[font=\small,color=white]{#1};%
|
||||||
|
}
|
||||||
|
\newcommand{\tikzmarkdrawcirclesarg}[1]{%
|
||||||
|
\begin{tikzpicture}[remember picture,overlay]
|
||||||
|
\foreach \x in {1,...,\expandafter\arabic{Tikzcounter#1}}
|
||||||
|
\fill (pic cs:\x)+(1.3ex,0.5ex) circle[fill=black,radius=1.1ex,anchor=west] node[font=\small,color=white]{$\x$};
|
||||||
|
\end{tikzpicture}%
|
||||||
|
}
|
||||||
|
\newcommand{\tikzmarkdrawcircles}{%
|
||||||
|
\begin{tikzpicture}[remember picture,overlay]
|
||||||
|
\foreach \x in {1,...,\expandafter\arabic\expandafter{Tikzcounter\expandafter\tikzmarkprefix}}
|
||||||
|
\fill (pic cs:\x)+(1.3ex,0.5ex) circle[fill=black,radius=1.1ex,anchor=west] node[font=\small,color=white]{$\x$};
|
||||||
|
\end{tikzpicture}%
|
||||||
|
}
|
||||||
|
|
||||||
|
% capitablize every First Letter
|
||||||
|
\let\oldmakefirstuc\makefirstuc
|
||||||
|
\renewcommand*{\makefirstuc}[1]{%
|
||||||
|
\def\gls@add@space{}%
|
||||||
|
\mfu@capitalisewords#1 \@nil\mfu@endcap
|
||||||
|
}
|
||||||
|
\def\mfu@capitalisewords#1 #2\mfu@endcap{%
|
||||||
|
\def\mfu@cap@first{#1}%
|
||||||
|
\def\mfu@cap@second{#2}%
|
||||||
|
\gls@add@space
|
||||||
|
\oldmakefirstuc{#1}%
|
||||||
|
\def\gls@add@space{ }%
|
||||||
|
\ifx\mfu@cap@second\@nnil
|
||||||
|
\let\next@mfu@cap\mfu@noop
|
||||||
|
\else
|
||||||
|
\let\next@mfu@cap\mfu@capitalisewords
|
||||||
|
\fi
|
||||||
|
\next@mfu@cap#2\mfu@endcap
|
||||||
|
}
|
||||||
|
\newcommand{\code}[2][md]{\mintinline{#1}{`#2`}}
|
||||||
|
|
||||||
\makeatother
|
\makeatother
|
||||||
\include{glossary}
|
\include{glossary}
|
||||||
|
|
||||||
\overfullrule=1cm
|
|
||||||
|
|
||||||
\begin{document}
|
\begin{document}
|
||||||
|
|
||||||
%TODO: \include{cover}
|
\include{cover}
|
||||||
\pagestyle{front}
|
\pagestyle{front}
|
||||||
\include{title}
|
\include{title}
|
||||||
|
|
||||||
\pagestyle{preamble}
|
\pagestyle{preamble}
|
||||||
\include{abstract}
|
\include{abstract}
|
||||||
%TODO: \include{affidavit}
|
\include{affidavit}
|
||||||
\cleardoublepage
|
\cleardoublepage
|
||||||
\newcounter{roman_pagenumbers} % save page number
|
\newcounter{roman_pagenumbers} % save page number
|
||||||
\setcounter{roman_pagenumbers}{\value{page}}
|
\setcounter{roman_pagenumbers}{\value{page}}
|
||||||
|
|
@ -116,32 +262,28 @@
|
||||||
\pagestyle{main}
|
\pagestyle{main}
|
||||||
%TODO \include{acknowledgments}
|
%TODO \include{acknowledgments}
|
||||||
|
|
||||||
\chapter*{Preface}
|
|
||||||
This thesis is original, unpublished, independent work by the author, \authorOne.
|
|
||||||
I strongly believe in openness and collaboration in the development of new technology, therefore the development will be based solely on Open-Source software.
|
|
||||||
The results of this project will be freely available on my personal Github site\footnote{https://github.com/steveeJ/msc-thesis} once the academic process of this project is complete.
|
|
||||||
|
|
||||||
|
|
||||||
\tableofcontents
|
\tableofcontents
|
||||||
|
|
||||||
\part{Context}
|
\part{Context}
|
||||||
|
\label{context}
|
||||||
|
|
||||||
\printnoidxglossary
|
\printnoidxglossary
|
||||||
|
|
||||||
\include{parts/context/context}
|
\include{parts/context/context}
|
||||||
|
|
||||||
\part{Research}
|
\part{Research And Development}
|
||||||
\label{part:research}
|
\label{rnd}
|
||||||
\include{parts/research/research}
|
\include{parts/research_and_development/research_and_development}
|
||||||
|
|
||||||
\part{Development}
|
\part{Evaluation And Conclusion}
|
||||||
\part{Conclusion}
|
\label{enc}
|
||||||
|
\include{parts/eval_and_conclusion/eval_and_conclusion}
|
||||||
|
|
||||||
\newpage
|
\newpage
|
||||||
%TODO \listofmyequations
|
%TODO \listofmyequations
|
||||||
\listoftables
|
\listoftables
|
||||||
%TODO \lstlistoflistings
|
%TODO \lstlistoflistings
|
||||||
\listoffigures
|
\listoffigures
|
||||||
\bibliography{thesis}
|
\printbibliography
|
||||||
|
|
||||||
\end{document}
|
\end{document}
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
{
|
{
|
||||||
\setlength{\parskip}{0.5cm}
|
\setlength{\parskip}{0.5cm}
|
||||||
\begin{center}
|
\begin{center}
|
||||||
\textbf{\huge Master's Thesis}
|
\textbf{\huge Thesis}
|
||||||
|
|
||||||
\textbf{for achieving the academic degree}
|
\textbf{for achieving the academic degree}
|
||||||
|
|
||||||
|
|
@ -12,7 +12,7 @@
|
||||||
[10ex]
|
[10ex]
|
||||||
|
|
||||||
\textsf{\Large Faculty For Information Technology}\\
|
\textsf{\Large Faculty For Information Technology}\\
|
||||||
Studies \studies
|
Studies: \studies
|
||||||
\end{center}
|
\end{center}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -21,7 +21,7 @@
|
||||||
\begin{tabular}{p{3cm}p{10cm}}
|
\begin{tabular}{p{3cm}p{10cm}}
|
||||||
Topic: & \textbf{\large \topic} \\[10ex]
|
Topic: & \textbf{\large \topic} \\[10ex]
|
||||||
Applicant: & \authorOne, \authorOnestreet, \authorOnezip$ $ \authorOnecity, \authorOneCountry \\
|
Applicant: & \authorOne, \authorOnestreet, \authorOnezip$ $ \authorOnecity, \authorOneCountry \\
|
||||||
& Student Identification Number: \authorOneId\\[10ex]
|
Matr-Nr.: & \authorOneId\\[10ex]
|
||||||
1st Supervisor: & \supervisorOne\\
|
1st Supervisor: & \supervisorOne\\
|
||||||
2nd Supervisor: & \supervisorTwo\\[10ex]
|
2nd Supervisor: & \supervisorTwo\\[10ex]
|
||||||
Start Date: & \startdate\\
|
Start Date: & \startdate\\
|
||||||
|
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
#!/usr/bin/env guile
|
|
||||||
!#
|
|
||||||
(display (+ 3 7))
|
|
||||||
423
static/pandoc-preview.html
Normal file
423
static/pandoc-preview.html
Normal file
|
|
@ -0,0 +1,423 @@
|
||||||
|
<!DOCTYPE html>
|
||||||
|
<html>
|
||||||
|
<head>
|
||||||
|
<meta charset="utf-8">
|
||||||
|
<title>Markdown Preview</title>
|
||||||
|
<style>
|
||||||
|
|
||||||
|
a{text-decoration:none;}
|
||||||
|
|
||||||
|
p{margin:1em 0;}
|
||||||
|
|
||||||
|
img{max-width:100%;}
|
||||||
|
|
||||||
|
h1,h2,h3,h4,h5,h6{font-weight:normal;color:#111;line-height:1em;}
|
||||||
|
h4,h5,h6{ font-weight: bold; }
|
||||||
|
h1{ font-size:2.5em; }
|
||||||
|
h2{ font-size:2em; border-bottom:1px solid silver; padding-bottom: 5px; }
|
||||||
|
h3{ font-size:1.5em; }
|
||||||
|
h4{ font-size:1.2em; }
|
||||||
|
h5{ font-size:1em; }
|
||||||
|
h6{ font-size:0.9em; }
|
||||||
|
|
||||||
|
blockquote{color:#666666;margin:0;padding-left: 3em;border-left: 0.5em #EEE solid;}
|
||||||
|
hr { display: block; height: 2px; border: 0; border-top: 1px solid #aaa;border-bottom: 1px solid #eee; margin: 1em 0; padding: 0; }
|
||||||
|
|
||||||
|
pre, code{
|
||||||
|
color: #000;
|
||||||
|
font-family: monospace;
|
||||||
|
font-size: 0.88em;
|
||||||
|
border-radius:3px;
|
||||||
|
background-color: #F8F8F8;
|
||||||
|
border: 1px solid #CCC;
|
||||||
|
}
|
||||||
|
pre { white-space: pre; white-space: pre-wrap; word-wrap: break-word; padding: 5px;}
|
||||||
|
pre code { border: 0px !important; background: transparent !important; line-height: 1.3em; }
|
||||||
|
sub, sup { font-size: 75%; line-height: 0; position: relative; vertical-align: baseline; }
|
||||||
|
sup { top: -0.5em; }
|
||||||
|
sub { bottom: -0.25em; }
|
||||||
|
ul, ol { margin: 1em 0; padding: 0 0 0 2em; }
|
||||||
|
li p:last-child { margin:0 }
|
||||||
|
dd { margin: 0 0 0 2em; }
|
||||||
|
img { border: 0; -ms-interpolation-mode: bicubic; vertical-align: middle; }
|
||||||
|
table { border-collapse: collapse; border-spacing: 0; }
|
||||||
|
td, th { vertical-align: top; padding: 4px 10px; border: 1px solid #bbb; }
|
||||||
|
tr:nth-child(even) td, tr:nth-child(even) th { background: #eee; }
|
||||||
|
|
||||||
|
ins { text-decoration: none; color: green }
|
||||||
|
del { text-decoration: none; color: red }
|
||||||
|
ins a{ color: green; text-decoration:none; }
|
||||||
|
del a{ color: red; text-decoration: none; }
|
||||||
|
|
||||||
|
#page { position: relative; }
|
||||||
|
#mes { position: fixed; margin-right: -40px; visibility: hidden; }
|
||||||
|
|
||||||
|
</style>
|
||||||
|
|
||||||
|
<script>
|
||||||
|
|
||||||
|
var flag_manual = false;
|
||||||
|
|
||||||
|
var smooth_scroll_to = function(target, duration) {
|
||||||
|
target = Math.round(target);
|
||||||
|
duration = Math.round(duration);
|
||||||
|
if (duration === 0) {
|
||||||
|
window.scrollTo(0, target);
|
||||||
|
return
|
||||||
|
}
|
||||||
|
|
||||||
|
var start_time = Date.now();
|
||||||
|
var end_time = start_time + duration;
|
||||||
|
|
||||||
|
var start_top = document.documentElement.scrollTop || document.body.scrollTop
|
||||||
|
var distance = target - start_top;
|
||||||
|
|
||||||
|
// based on http://en.wikipedia.org/wiki/Smoothstep
|
||||||
|
var smooth_step = function(start, end, point) {
|
||||||
|
if(point <= start) { return 0; }
|
||||||
|
if(point >= end) { return 1; }
|
||||||
|
var x = (point - start) / (end - start); // interpolation
|
||||||
|
return x*x*(3 - 2*x);
|
||||||
|
}
|
||||||
|
|
||||||
|
// This is to keep track of where the window's scrollTop is
|
||||||
|
// supposed to be, based on what we're doing
|
||||||
|
var previous_top = document.documentElement.scrollTop || document.body.scrollTop
|
||||||
|
|
||||||
|
// This is like a think function from a game loop
|
||||||
|
var scroll_frame = function() {
|
||||||
|
var tmp = document.documentElement.scrollTop || document.body.scrollTop
|
||||||
|
if(tmp != previous_top) {
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
|
||||||
|
// set the scrollTop for this frame
|
||||||
|
var now = Date.now();
|
||||||
|
var point = smooth_step(start_time, end_time, now);
|
||||||
|
var frameTop = Math.round(start_top + (distance * point));
|
||||||
|
window.scrollTo(0, frameTop);
|
||||||
|
|
||||||
|
// check if we're done!
|
||||||
|
if(now >= end_time) {
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
|
||||||
|
// If we were supposed to scroll but didn't, then we
|
||||||
|
// probably hit the limit, so consider it done; not
|
||||||
|
// interrupted.
|
||||||
|
var tmp = document.documentElement.scrollTop || document.body.scrollTop
|
||||||
|
if(tmp === previous_top
|
||||||
|
&& tmp !== frameTop) {
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
previous_top = tmp;
|
||||||
|
|
||||||
|
// schedule next frame for execution
|
||||||
|
setTimeout(scroll_frame, 0);
|
||||||
|
}
|
||||||
|
|
||||||
|
// boostrap the animation process
|
||||||
|
setTimeout(scroll_frame, 0);
|
||||||
|
}
|
||||||
|
|
||||||
|
var last_html = undefined;
|
||||||
|
|
||||||
|
/** Function count the occurrences of substring in a string;
|
||||||
|
* @param {String} string Required. The string;
|
||||||
|
* @param {String} subString Required. The string to search for;
|
||||||
|
* @param {Boolean} allowOverlapping Optional. Default: false;
|
||||||
|
*/
|
||||||
|
function occurrences(string, subString, allowOverlapping){
|
||||||
|
|
||||||
|
string+=""; subString+="";
|
||||||
|
if(subString.length<=0) return string.length+1;
|
||||||
|
|
||||||
|
var n=0, pos=0;
|
||||||
|
var step=(allowOverlapping)?(1):(subString.length);
|
||||||
|
|
||||||
|
while(true){
|
||||||
|
pos=string.indexOf(subString,pos);
|
||||||
|
if(pos>=0){
|
||||||
|
n++; pos+=step;
|
||||||
|
} else
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
return(n);
|
||||||
|
}
|
||||||
|
|
||||||
|
function unescape1(data) {
|
||||||
|
return decodeURIComponent(escape(window.atob(data)))
|
||||||
|
}
|
||||||
|
|
||||||
|
var g_W;
|
||||||
|
var g_C;
|
||||||
|
|
||||||
|
/* TODO: highligh the W */
|
||||||
|
/* TODO: scroll to W exactly */
|
||||||
|
function setCursor(W, C) {
|
||||||
|
if (flag_manual) {
|
||||||
|
g_W = W;
|
||||||
|
g_C = C;
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
W = unescape1(W);
|
||||||
|
var d = document.getElementById('out');
|
||||||
|
for (var i = 0; i < d.childNodes.length; i++) {
|
||||||
|
f = occurrences(d.childNodes[i].textContent, W, false);
|
||||||
|
C = C - f;
|
||||||
|
if (C <= 0) {
|
||||||
|
smooth_scroll_to(d.childNodes[i].offsetTop - window.outerHeight / 3, 500)
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
// TODO: make this user configurable
|
||||||
|
// var g_foldType = "struct" | "stacked"
|
||||||
|
//var g_foldType = "struct";
|
||||||
|
var g_foldType = "stacked";
|
||||||
|
|
||||||
|
function setOutput(val) {
|
||||||
|
val = unescape1(val)
|
||||||
|
var out = document.getElementById('out');
|
||||||
|
out.innerHTML = val;
|
||||||
|
document.getElementById("mes").style.visibility="hidden";
|
||||||
|
restoreFoldStatuses();
|
||||||
|
setOnClickHandlerToHeaders();
|
||||||
|
window.onresize();
|
||||||
|
}
|
||||||
|
|
||||||
|
document.onwheel = function(x) {
|
||||||
|
if (!flag_manual) {
|
||||||
|
document.getElementById("mes").style.visibility="visible";
|
||||||
|
flag_manual = true;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
document.onkeypress = function(x) {
|
||||||
|
if (x.keyCode == 40 /*Down*/ || x.keyCode == 38 /*Up*/)
|
||||||
|
if (!flag_manual) {
|
||||||
|
document.getElementById("mes").style.visibility="visible";
|
||||||
|
flag_manual = true;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
window.onresize = function(x) {
|
||||||
|
var mes = document.getElementById("mes");
|
||||||
|
mes.style.marginLeft = (document.body.clientWidth - mes.offsetWidth - 30) + "px";
|
||||||
|
}
|
||||||
|
|
||||||
|
function scroll_automaticaly() {
|
||||||
|
flag_manual = false;
|
||||||
|
document.getElementById("mes").style.visibility="hidden";
|
||||||
|
setCursor(g_W,g_C);
|
||||||
|
}
|
||||||
|
|
||||||
|
function setOnClickHandlerToHeaders() {
|
||||||
|
var hs = ["H1", "H2", "H3", "H4", "H5", "H6", "H7"];
|
||||||
|
for (var i = 0; i < hs.length; i++) {
|
||||||
|
var es = document.getElementsByTagName(hs[i]);
|
||||||
|
if (es == null)
|
||||||
|
continue;
|
||||||
|
for (var ii = 0; ii < es.length; ii++) {
|
||||||
|
es[ii].addEventListener("click", onClickHandler, false);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
var g_foldStatus = {};
|
||||||
|
|
||||||
|
// merge two objects. usable for "associate arrays"
|
||||||
|
// destination is modified in place and returned
|
||||||
|
// same keys in destination are overwritten by source
|
||||||
|
function merge(d, s) {
|
||||||
|
for (var p in s) {
|
||||||
|
if (s.hasOwnProperty(p)) {
|
||||||
|
d[p] = s[p];
|
||||||
|
}
|
||||||
|
}
|
||||||
|
return d;
|
||||||
|
}
|
||||||
|
|
||||||
|
function getHeaderPath(t) {
|
||||||
|
var p = [];
|
||||||
|
var headerLevel = t.nodeName[1];
|
||||||
|
p.push(t.id);
|
||||||
|
while ((t = t.previousElementSibling)) {
|
||||||
|
if (t.nodeName[0] == "H"
|
||||||
|
&& t.nodeName[1] < headerLevel) {
|
||||||
|
headerLevel = t.nodeName[1];
|
||||||
|
p.push(t.id);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
return p;
|
||||||
|
}
|
||||||
|
|
||||||
|
function saveFoldStatus(t, i) {
|
||||||
|
var p = getHeaderPath(t);
|
||||||
|
|
||||||
|
var obj = Object();
|
||||||
|
obj[p.join("#")] = i;
|
||||||
|
|
||||||
|
merge(g_foldStatus, obj);
|
||||||
|
}
|
||||||
|
|
||||||
|
// manualFold: undefined, true, false
|
||||||
|
// headerLevel: 0 - visible, > 0 - how many times folded
|
||||||
|
// contentLevel: 0 - visible, > 0 - how many times folded
|
||||||
|
|
||||||
|
// t["fold"] = [manualFold, headerLevel, contentLevel];
|
||||||
|
|
||||||
|
function getFoldInfo(t) {
|
||||||
|
var i = t["fold"];
|
||||||
|
if (i == undefined) {
|
||||||
|
return {mf: undefined, hl: 0, cl: 0};
|
||||||
|
} else {
|
||||||
|
return i;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
function setFoldInfo(t, i) {
|
||||||
|
t["fold"] = i;
|
||||||
|
saveFoldStatus(t, i);
|
||||||
|
}
|
||||||
|
|
||||||
|
function toggleStackedFoldInfo(i) {
|
||||||
|
if (i.mf == undefined) {
|
||||||
|
if (i.cl > 0) {
|
||||||
|
i.mf = false;
|
||||||
|
} else {
|
||||||
|
i.mf = true;
|
||||||
|
}
|
||||||
|
} else {
|
||||||
|
i.mf = !i.mf;
|
||||||
|
}
|
||||||
|
if (i.mf) { // Folded
|
||||||
|
i.hl = 0;
|
||||||
|
i.cl = 1;
|
||||||
|
} else { // Unfolded
|
||||||
|
i.hl = 0;
|
||||||
|
i.cl = 0;
|
||||||
|
}
|
||||||
|
return i;
|
||||||
|
}
|
||||||
|
function updateStackedFoldInfo(infoClickedHeader, infoHeader) {
|
||||||
|
infoHeader.hl = 0;
|
||||||
|
if (infoClickedHeader.mf) {
|
||||||
|
infoHeader.cl = 1;
|
||||||
|
} else {
|
||||||
|
if (infoHeader.mf) {
|
||||||
|
infoHeader.cl = 1;
|
||||||
|
} else {
|
||||||
|
infoHeader.cl = 0;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
return infoHeader;
|
||||||
|
}
|
||||||
|
function toggleStructFoldInfo(i) {
|
||||||
|
if (i.mf == undefined) {
|
||||||
|
i.mf = true;
|
||||||
|
} else {
|
||||||
|
i.mf = !i.mf;
|
||||||
|
}
|
||||||
|
if (i.mf) { // Folded
|
||||||
|
i.hl = 0;
|
||||||
|
i.cl = 1;
|
||||||
|
} else { // Unfolded
|
||||||
|
i.hl = 0;
|
||||||
|
i.cl = 0;
|
||||||
|
}
|
||||||
|
return i;
|
||||||
|
}
|
||||||
|
function updateStructFoldInfo(infoClickedHeader, infoHeader) {
|
||||||
|
if (infoClickedHeader.mf) {
|
||||||
|
infoHeader.hl += 1;
|
||||||
|
infoHeader.cl += 1;
|
||||||
|
} else {
|
||||||
|
infoHeader.hl -= 1;
|
||||||
|
infoHeader.cl -= 1;
|
||||||
|
}
|
||||||
|
return infoHeader;
|
||||||
|
}
|
||||||
|
function applyFold(t, infoClickedHeader, updateFoldInfo) {
|
||||||
|
var headerLevel = t.nodeName[1];
|
||||||
|
var cl = infoClickedHeader.cl;
|
||||||
|
|
||||||
|
while ((t = t.nextElementSibling)
|
||||||
|
&& (t.nodeName[0] != "H" || t.nodeName[1] > headerLevel)) {
|
||||||
|
if (t.nodeName[0] == "H") {
|
||||||
|
infoHeader = updateFoldInfo(infoClickedHeader, getFoldInfo(t));
|
||||||
|
setFoldInfo(t, infoHeader);
|
||||||
|
cl = infoHeader.cl;
|
||||||
|
t.style.display = infoHeader.hl > 0 ? "none" : "";
|
||||||
|
} else {
|
||||||
|
t.style.display = cl > 0 ? "none" : "";
|
||||||
|
}
|
||||||
|
}
|
||||||
|
return t;
|
||||||
|
}
|
||||||
|
|
||||||
|
function runHeaderPath(p, t, f) {
|
||||||
|
if (t == null) {
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
if (p.length == 0) {
|
||||||
|
f(t);
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
var id = p.pop();
|
||||||
|
while (t != null) {
|
||||||
|
if (t.id == id) {
|
||||||
|
runHeaderPath(p, t, f);
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
t = t.nextElementSibling;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
function finalElementFunc(i) {
|
||||||
|
return function X(t) {
|
||||||
|
setFoldInfo(t, i);
|
||||||
|
t.style.display = i.hl > 0 ? "none" : "";
|
||||||
|
while ((t = t.nextElementSibling)
|
||||||
|
&& t.nodeName[0] != "H") {
|
||||||
|
t.style.display = i.cl > 0 ? "none" : "";
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
function restoreFoldStatuses() {
|
||||||
|
var foldStatus = g_foldStatus;
|
||||||
|
g_foldStatus = {};
|
||||||
|
|
||||||
|
for (var p in foldStatus) {
|
||||||
|
if (foldStatus.hasOwnProperty(p)) {
|
||||||
|
var i = foldStatus[p];
|
||||||
|
var p = p.split("#");
|
||||||
|
var id = p.pop();
|
||||||
|
runHeaderPath(p, document.getElementById(id), finalElementFunc(i));
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
function onClickHandler() {
|
||||||
|
var t = this;
|
||||||
|
|
||||||
|
if (g_foldType == "struct") {
|
||||||
|
var infoClickedHeader = toggleStructFoldInfo(getFoldInfo(t));
|
||||||
|
|
||||||
|
setFoldInfo(t, infoClickedHeader);
|
||||||
|
applyFold(t, infoClickedHeader, updateStructFoldInfo);
|
||||||
|
} else if (g_foldType == "stacked") {
|
||||||
|
var infoClickedHeader = toggleStackedFoldInfo(getFoldInfo(t));
|
||||||
|
|
||||||
|
setFoldInfo(t, infoClickedHeader);
|
||||||
|
applyFold(t, infoClickedHeader, updateStackedFoldInfo);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
</script>
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<div id=page>
|
||||||
|
<div id=mes><input type="button" value="Scroll automatically" onclick=scroll_automaticaly() /></div>
|
||||||
|
<div id=out></div>
|
||||||
|
</div>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue