| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Prepared with help from jsg@ and mortimer@
Tested on amd64 by bcallah@, krw@, naddy@
Tested on arm64 by patrick@
Tested on macppc by kettenis@
Tested on octeon by visa@
Tested on sparc64 by claudio@
|
|
|
|
Makes things slightly faster and also improves security in these functions,
since the retguard cookie can't leak via the stack.
ok deraadt@
|
|
this is a bit different to gcc as gcc likes to use movs to move
stuff on and off the stack, and directly updates the stack pointers
with add and sub instructions. llvm prefers to use push and pop
instructions, is a lot more careful about keeping track of how
much stuff is currently on the stack, and generally pops the frame
pointer rather than do maths on it.
-msave-args adds a bunch of pushes as the first thing a function
prologue does. to keep the stack aligned, if there's an odd number
of arguments to the function it pushes the first one again to put
the frame back on a 16 byte boundary.
to undo the pushes the frame pointer needs to be updated in function
epilogues. clang emits a series of pops to fix up the registers on
the way out, but popping saved arguments is a waste of time and
harmful to actual data in the function. rather than add an offset
to the stack pointer, -msave-args emits a leaveq operation to fix
up the frame again. leaveq is effectively mov rbp,rsp; pop rbp, and
is a single byte, meaning there's less potential for gadgets compared
to a direct add to rsp, or an explicit mov rbp,rsp.
the only thing missing compared to the gcc implementation is adding
the SUN_amd64_parmdump dwarf flag to affected functions. if someone
can tell me how to add that from the frame lowering code, let me
know.
when enabled in kernel builds again, this will provide useful
arguments in ddb stack traces again.
|
|
|
|
|
|
|
|
With fixes from mortimer@ (thanks!)
Tested by many, especially naddy@ (thanks!)
|
|
|
|
|
|
random cookies to protect access to function return instructions, with the
effect that the integrity of the return address is protected, and function
return instructions are harder to use in ROP gadgets.
On function entry the return address is combined with a per-function random
cookie and stored in the stack frame. The integrity of this value is verified
before function return, and if this check fails, the program aborts. In this way
RETGUARD is an improved stack protector, since the cookies are per-function. The
verification routine is constructed such that the binary space immediately
before each ret instruction is padded with int03 instructions, which makes these
return instructions difficult to use in ROP gadgets. In the kernel, this has the
effect of removing approximately 50% of total ROP gadgets, and 15% of unique
ROP gadgets compared to the 6.3 release kernel. Function epilogues are
essentially gadget free, leaving only the polymorphic gadgets that result from
jumping into the instruction stream partway through other instructions. Work to
remove these gadgets will continue through other mechanisms.
Remaining work includes adding this mechanism to assembly routines, which must
be done by hand. Many thanks to all those who helped test and provide feedback,
especially deaadt, tb, espie and naddy.
ok deraadt@
|
|
|
|
|
|
"where is the kaboom?" deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
ok deraadt@
|
|
|
|
|
|
development effort on OpenBSD/arm64.
|
|
|
|
|
|
ok hackroom@
|
patrick
mortimer
dlg
pascal