I thought it was self-explanatory, but let me provide a little context: a NOP-sled can be used to increase reliability in software (especially for ROMs exposed to hard radiation). It can also be used in various attacks. The letter describes how the author has built in a replacement for NOPs at the assembler level that should make software more secure without adverse effect.
Unless you were making a joke about context-free replacement.
I was under the impression that NOP sleds were inserted by the attacker when they can't quite be sure where exactly their code will begin executing. They just transfer execution to about the region the NOP sled will be, and then slide through to the start of the payload.
Modifying NOP sleds at compile time is not going to defend against this.
OpenBSD uses W^X aka DEP aggressively. In fact, for OpenBSD 6.1 a program can't even disable W^X unless the binary was mounted on a filesystem with the wxallowed option.
Thus, attackers can't insert NOP sleds. They have to rely on the sleds already in the code. From what I gather from the announcement, toolchains often insert NOPs as padding, inadvertently creating NOP sleds. This is an attempt to fix that.
I am absolutely fascinated by this! I have relatively little experience at this level of computing outside of developing some pet project VMs and a bit of 68k assembly in college. Can you expound on the purpose of a NOP sled and why that specific construct lends itself to systems exposed to specific harsh conditions?
The best example I can think of is a set of instructions on a medium. You've got jumps as a normal part of programming at this level. If the address of the jump is corrupted by an environmental factor (e.g. Hard radiation), then the jump
may end up in lalaland. A sled in this context would be placed at the end of and in between sets of instructions
with a jump back to a safe location to restart. So a jump to an invalid location or past the instruction set would have a chance of recovering back to a valid subroutine.
