Smith, Kevin B via llvm-dev
2015-Nov-02 23:47 UTC
[llvm-dev] How to prevent registers from spilling?
That breaks the whole IR idea of using alloca to allocate/denote space for local variables, and then optimize those into SSA values when optimization proves that is OK. Also, for a lot of things, that attribute is simply impossible to implement. Any value that is live across a call needs to be spilled to memory. You cannot put an unspillable value in a callee preserved register, because you cannot know whether the callee may save that or not. And if it is in a caller-save register, then the caller has to spill it if it is live across a call. Kevin B. Smith -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of C Bergström via llvm-dev Sent: Monday, November 02, 2015 3:30 PM To: Stephen Crane Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] How to prevent registers from spilling? 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) _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Stephen Crane via llvm-dev
2015-Nov-03 00:08 UTC
[llvm-dev] How to prevent registers from spilling?
Thanks, I hadn't thought about the HPC applications. I'm not sure that the requirements for the HPC and security use-cases are compatible. Pinning for performance can tolerate spills if it is still fast, while security uses can tolerate slow rematerialization but not spills. Maybe a shared infrastructure is possible but with variable constraints? On Mon, Nov 2, 2015 at 3:47 PM, Smith, Kevin B <kevin.b.smith at intel.com> wrote:> That breaks the whole IR idea of using alloca to allocate/denote space for > local variables, and then optimize those > into SSA values when optimization proves that is OK. >Agreed, but the values I care about (which is not really the HPC use-case) would actually be values internal to the compiler, such as the location of CFI metadata, which are never exposed to the front end. Thus I would be happy with something at the machine IR level, after that abstraction has been lost.> Also, for a lot of things, that attribute is simply impossible to > implement. Any value that is live across a call needs to be spilled to > memory. > You cannot put an unspillable value in a callee preserved register, > because you cannot know whether the callee may save that or not. > And if it is in a caller-save register, then the caller has to spill it if > it is live across a call. >Yes, but what about values that can be rematerialized? Of course values that _need_ to be live across calls are out, but I'm more concerned about values that were coalesced, hoisted, and which then get spilled. Maybe prevention of coalescing for sensitive values and explicitly inserting materialization at each use is an option here, although that sounds like teaching a lot of passes about sensitive values, with no guarantee of finding all of them. Wouldn't the register allocator still need to make sure that sensitive values are not present in dead callee-saved registers, so they don't get accidentally spilled by a callee? - stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151102/9c9ef11f/attachment.html>
Robinson, Paul via llvm-dev
2015-Nov-03 00:21 UTC
[llvm-dev] How to prevent registers from spilling?
Sounds like such a security-sensitive value would need to treat calls as barriers for any kind of reordering. Also, at the end of the value's live range, it would not have to be merely dead, but dead-and-buried (i.e. overwritten) to avoid scavenging by subsequent callees. Same goes for merely copying the value from one register to another, the source would have to be erased. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Stephen Crane via llvm-dev Sent: Monday, November 02, 2015 4:08 PM To: Smith, Kevin B Cc: llvm-dev at lists.llvm.org; Per Larsen; Andrei Homescu Subject: Re: [llvm-dev] How to prevent registers from spilling? Thanks, I hadn't thought about the HPC applications. I'm not sure that the requirements for the HPC and security use-cases are compatible. Pinning for performance can tolerate spills if it is still fast, while security uses can tolerate slow rematerialization but not spills. Maybe a shared infrastructure is possible but with variable constraints? On Mon, Nov 2, 2015 at 3:47 PM, Smith, Kevin B <kevin.b.smith at intel.com<mailto:kevin.b.smith at intel.com>> wrote: That breaks the whole IR idea of using alloca to allocate/denote space for local variables, and then optimize those into SSA values when optimization proves that is OK. Agreed, but the values I care about (which is not really the HPC use-case) would actually be values internal to the compiler, such as the location of CFI metadata, which are never exposed to the front end. Thus I would be happy with something at the machine IR level, after that abstraction has been lost. Also, for a lot of things, that attribute is simply impossible to implement. Any value that is live across a call needs to be spilled to memory. You cannot put an unspillable value in a callee preserved register, because you cannot know whether the callee may save that or not. And if it is in a caller-save register, then the caller has to spill it if it is live across a call. Yes, but what about values that can be rematerialized? Of course values that _need_ to be live across calls are out, but I'm more concerned about values that were coalesced, hoisted, and which then get spilled. Maybe prevention of coalescing for sensitive values and explicitly inserting materialization at each use is an option here, although that sounds like teaching a lot of passes about sensitive values, with no guarantee of finding all of them. Wouldn't the register allocator still need to make sure that sensitive values are not present in dead callee-saved registers, so they don't get accidentally spilled by a callee? - stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/882039cc/attachment-0001.html>