Now I'm in an s390 rabbit hole learning about program status word, storage (memory?) protection keys, z/os interrupt prefixes... and intel reincarnated this as MPX?
"Proceedings of the Seminar on the DoD Computer Security Initiative Program"  https://csrc.nist.gov/CSRC/media/Publications/conference-paper/1979/07/17/proceedings-first-seminar-dod-computer-security-initiative/documents/1979-1st-seminar-proceedings.pdf
This is a really amazing document to me, summarizing a lot of what I'd hoped to get from folks in conversation.
Now that I've had a few conversations with mainframe users, I realize the odds of finding folks who actively worked in security-conscious environments are probably few and far between. Anyway, this spawned a whole bunch of new source material searches for my BSidesCBR talk :)
It seems CTOS was a message-based microkernel thing, had P2P networking and could boot from the network. It "ran on Intel x86 computers, and could run concurrently with Windows NT on Unisys PC" - I sometimes wonder what it would've been like to be involved during this cambrian explosion of computing: https://en.wikipedia.org/wiki/Convergent_Technologies_Operating_System
I'm trying to talk to users/developers of older mainframe/minicomputer systems (to 1980s) to get a feel for what kinds of security threats folks were trying to deal with back then, particularly running untrusted code prior to PC revolution. Burroughs seems to have significant mentions in literature, so through friends I've found two (maybe 3) ex-users. Their stories are interesting, but light on security stuff. I did get solid recommendation to investigate CTOS though, which looks fun.
Microarchitectural attacks: reflecting on 45 years of research since "A note on the confinement problem" - my talk was accepted at BSidesCBR :-) Now, to achieve clarity on what "confinement" has meant, what was attempted, and what was achieved (or not achieved) over the decades...
"The Page-Fault Weird Machine: Lessons in Instruction-less Computation" Bangert, Bratus, Shapiro, Smith - https://www.usenix.org/system/files/conference/woot13/woot13-bangert.pdf
".. We demonstrate a Turing-complete execution environment driven solely by the IA32 architecture’s interrupt handling and memory translation tables, in which the processor is trapped in a series of page faults and double faults, without ever successfully dispatching any instructions .."
... found via a pretty decent blog post on the topic at http://www.pl-enthusiast.net/2017/10/23/what-is-soundness-in-static-analysis/
"DR. CHECKER: A Soundy Analysis for Linux Kernel Drivers" Machiry, Spensky, et al. https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-machiry.pd
.. we present DR. CHECKER, a soundy (i.e., mostly sound) bug-finding tool for Linux kernel drivers that is based on well-known program analysis techniques. We are able to overcome many of the inherent limitations .. we analyzed the drivers of nine production Linux kernels (3.1 million LOC), where it correctly identified 158 critical zero-day bugs with an overall precision of 78%."
Recently encouraged to apply for a job, involved a 5-day/40hr take-home test (negotiated more time; was travelling soon after telling me about the task). Turned out to be amazingly fun, but now realizing how lucky I am to be able to consider doing this at short notice; a lot of great people don't have the support/lack of responsibility to spend this kind of time at home. OTOH, point of it was helping them consider more diverse applicant pool (wrt ppl who hadn't done this exact work). Hmmm.
oh and literally all of Android and Fuchsia... lol
a lot of ppl think Android is good because it's got a license and you can read a bunch of code, but veiwed as an open-source project it's a complete failure to treat its userbase with respect, enfranchise them in the development process, and protect them from exploitation
it has a fucking *app store*!
"Breaking the x86 ISA" - Christopher Domas
"..we demonstrate how page fault analysis and some creative processor fuzzing can be used to exhaustively search the x86 instruction set and uncover the secrets buried in a chipset. The approach has revealed critical x86 hardware glitches, previously unknown machine instructions, ... and flaws in enterprise hypervisors"
Breaking the links: Exploiting the linker 
.. insecure library loading on the [Windows] provoked a significant amount of debate as to whether GNU/Linux and UNIX variants could be vulnerable to similar attacks.. general consensus .. appeared to be that this was just another example of Microsoft doing things wrong, I .. responded with a blog post that sought to highlight an example of where POSIX style
linkers get things wrong..
Hello from the Other Side: SSH over Robust Cache Covert Channels in the Cloud
DRAMA: Exploiting DRAM Addressing for Cross-CPU Attacks.
Malware Guard Extension: Using SGX to Conceal Cache Attacks
Drammer: Deterministic Rowhammer Attacks on Mobile Platforms
Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR
Flush+Flush: A Fast and Stealthy Cache Attack
Cache Template Attacks: Automating Attacks on Inclusive Last-Level Caches.
ARMageddon: Cache Attacks on Mobile Devices
Strong and Efficient Cache Side-Channel Protection using Hardware Transactional Memory
KASLR is Dead: Long Live KASLR
"Software-based Microarchitectural Attacks" - Daniel Gruss https://gruss.cc/files/phd_thesis.pdf
In this thesis, we investigate software-based microarchitectural attacks. Software-based microarchitectural side-channel attacks exploit timing and behavior differences that are (partially) caused through microarchitectural optimizations, i.e., differences that are not architecturally documented. Software-based microarchitectural fault attacks induce faults through microarchitectural optimizations
"LETHE: Strengthening Fine Grained Address Space Layout Randomization with Computationally Inexpensive Memory Disclosure Tripwires" (Selifonov 2015) http://thyth.com/p/lethe/lethe-wp.pdf
"...Fine-grained ASLR pushes the exploit payload creation process into runtime, but it is not enough to prevent just-in-time discovery of return oriented programming gadgets. By incorporating new memory permission capabilities exposed through virtualization on the Intel platform..."
"Looking back at Grsecurity" - (Bijnen, Berkelaar 2014) https://www.edworks.info/papers/Looking_back_at_Grsecurity.pdf
.. We have gathered
an array of potentially system compromising exploits that have
been discovered in a five year time frame. Each of these ex-
ploits are tested on a vulnerable system that has yet to receive
a fix for the exploit, simulating a zero-day attack. We found
that Grsecurity offers considerable enhancements in the field of
kernel security and that from a historical..
Unleashing Use-Before-Initialization Vulnerabilities in the Linux Kernel Using Targeted Stack Spraying" (Lu, Walter, Pfaff, Nürnberger, Lee, Backes 2017) https://www.internetsociety.org/sites/default/files/ndss2017_09-2_Lu_paper.pdf
..automated targeted stack-spraying .. reliably facilitates the exploitation of uninitialized uses..
(1) .. combines tailored symbolic execution and guided fuzzing .. (2) .. exhaustive memory spraying .. reliably control more than 91% of the Linux kernel stack..
A Study of Overflow Vulnerabilities on GPUs  by Di, Sun, Chen
... In this paper, we explore security vulnerabilities of CUDA from multiple dimensions. In particular, we first present a study on GPU stack, and reveal that stack overflow of CUDA can affect the execution of other threads by manipulating different memory spaces. Then, we show that the heap of CUDA is organized in a way that allows threads from the same warp or..
PoC || GTFO 0x03:6, pp18: Prototyping an RDRAND Backdoor in Bochs [Taylor Hornby] - I just love it.