Skip to content

Instantly share code, notes, and snippets.

View thestinger's full-sized avatar

Daniel Micay thestinger

View GitHub Profile
@thestinger
thestinger / oom.c
Last active February 11, 2016 23:46
// Clang is clever enough to optimize out these malloc and free calls.
#include <stdio.h>
#include <stdlib.h>
int main(void) {
void *ptr = malloc(16);
if (!ptr) {
puts("side effect");
return 1;
// This double-free is detected with 100% reliability in CopperheadOS via the
// malloc quarantine. The malloc quarantine uses a ring buffer to provide a
// guaranteed baseline delay and a hash table for detecting double frees. A
// double free can also be detected after allocations are flushed from the
// quarantine, but only if the slot is still free.
//
// /data/data/test/test(688) in free(): error: double free 0x8e503300
// Aborted
#include <stdlib.h>
@thestinger
thestinger / 0_todo.md
Last active July 11, 2021 14:46
-fstack-protector-all with return address XOR (per 1999 StackGuard)
  1. Tests!
  2. Configuration
  3. Clang user interface
  4. add a better heuristic to use with this than -fstack-protector-all ("can corrupt memory" -> canary)
  5. support leaving SelectionDAG SSP enabled for sibling call optimization compatibility

The AArch64 implementation is far from ideal performance-wise, since it depends on forcing the generation of a proper frame to store and load the return address. It's not clear how to improve this yet.

@thestinger
thestinger / aosp.md
Last active December 23, 2016 06:47
NOT READY FOR PUBLISHING (i.e. future blog post): notes about problems with the Android Open Source Project

The Neglected Android Open Source Project

What is the Android Open Source Project?

The Android Open Source Project is essentially the Android source code for Nexus devices and the Pixel C. However, it's somewhat different from the internal source tree used to build stock Android for those devices.

It's important to note that it's only closely tied to the internal source code for stable releases. The master branch of AOSP does not closely track the internal development. The internal work is released as part of a stable update, and then merged into the AOSP master branch afterwards. AOSP master and the internal source tree are repeatedly merged into each other to some extent during a year of development, as some work happens out in the open (lots of the low-level userspace work) while other work happens internally. For some repositories, there's substantial amounts of both. The merges are primarily from AOSP into the internal tree until new stable source code is released. These strange workflows result

From 90af9982190cc4ff4d4a8d5c1e3eac53b67ac27c Mon Sep 17 00:00:00 2001
From: Daniel Micay <danielmicay@gmail.com>
Date: Thu, 27 Oct 2016 22:25:21 -0400
Subject: [PATCH] turbostat: add support for printing Vcore values
---
tools/power/x86/turbostat/turbostat.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/tools/power/x86/turbostat/turbostat.c b/tools/power/x86/turbostat/turbostat.c
#include <linux/futex.h>
#include <syscall.h>
#include <time.h>
#include <unistd.h>
#include "mutex.h"
#define unlikely(x) __builtin_expect(!!(x), 0)
static int sys_futex(void *uaddr, int op, int val1, struct timespec *timeout, void *uaddr2,
// clang -std=c99 -O2 foo.c && ./a.out
#include <stdio.h>
#include <stdbool.h>
__attribute__((noinline)) void foo(bool b) {
if (b) return; // remove this line and it will exit without printing
for (;;) {}
}
#!/usr/bin/env python
#
# Instrument vmlinux STP, LDP and BLR instructions to protect RA and restrict jumpping
#
# Depends on:
# 1) a modified gcc that
# - outputs 2 nop's before stp x29, x30 instructions
# - outputs 1 nop after ldp x29, x30 instructions
# 2) a kernel built using gcc command-line options to prevent allocation of registers x16, x17, and x18
#
// gcc -O2 -D_FORTIFY_SOURCE
#include <stdlib.h>
#include <string.h>
int main(void) {
char dst[4];
char src[5] = {};
memcpy(dst, src, atoi("5"));
}
@thestinger
thestinger / Linux ASLR comparison.md
Last active November 26, 2022 11:27
Comparing ASLR between mainline Linux, grsecurity and linux-hardened

These results are with glibc malloc on x86_64. The last public PaX and grsecurity patches don't support arm64 which is one of the two architectures (x86_64 kernels including x32/x86_32 and arm64 kernels including armv7 userspace) focused on by linux-hardened. There isn't anything other than x86_64 to compare across all 3 kernels although linux-hardened has the same end result for both x86_64 and arm64 (with slightly different starting points) and there are few mainline differences. The linux-hardened implementation of ASLR is a very minimal modification of the mainline implementation to fix the weaknesses compared to grsecurity. The intention is to upstream all of these changes, although care needs to be taken to properly justify them to avoid getting anything rejected unnecessarily.

Explanation of differences between kernels:

  • Mainline and linux-hardened base randomization entropy for the mmap base and executable to the vm.mmap_rnd_bits sysctl for 64-bit and