[llvm-dev] How to prevent registers from spilling?

C Bergström via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 2 15:30:24 PST 2015


On Tue, Nov 3, 2015 at 6:24 AM, Stephen Crane via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> I've been trying to figure out if there is a feasible way to prevent values
> from ever spilling from registers to the stack. I've looked for code or
> documentation on how to do this but haven't found anything, apologies if
> this has already been done.
>
> Recent security research has shown that protection schemes such as CFI (that
> might otherwise be secure) are undermined by sensitive values spilling to
> the stack. When security-critical values spill from registers to the stack,
> they can be read and overwritten by an attacker with arbitrary memory read
> or write capabilities. See "Losing Control" from CCS 2015 for more details
> on this sort of attack: https://www.ics.uci.edu/~perl/ccs15_stackdefiler.pdf
>
> I think it would be great if we could allow values or at least virtual regs
> to be tagged as "security-sensitive" and disallow spilling of these values
> across their lifetime. I expect that the best way to do this would be to
> start at the virtual register level and push support up to IR values as well
> if and only if machine IR turns out to be insufficient.
>
> Is this a good idea? Does something to support register pinning already
> exist? I'm unfortunately not familiar enough with the register allocators to
> know how to best support this, although I'm willing to give it a try if
> people can point me in the right direction.

I don't a real answer for you, but my 1st idea is that it would be an
attribute you could apply to a variable. How you *force* that to never
spill on the backend is an entirely different issue. You'd basically
force a split on a certain variable under certain conditions - would
it be possible - (why not) Unless I'm missing something it would be
hell to schedule though..

There's use cases in HPC and GPGPU codes which may benefit from
something similar, but for different reasons. (Some really hot
variable that you never want spilled for example)


More information about the llvm-dev mailing list