| Message ID | cover.1666651511.git.pawan.kumar.gupta@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Branch Target Injection (BTI) gadget in minstrel | expand |
On Mon, Oct 24, 2022 at 03:57:45PM -0700, Pawan Gupta wrote: > The other goal of this series is to start a discussion on whether such > hard to exploit, but theoretical possible attacks deems to be mitigated. > > In general Branch Target Injection class of attacks involves an adversary > controlling an indirect branch target to misspeculate to a disclosure gadget. > For a successful attack an adversary also needs to control the register > contents used by the disclosure gadget. I'm thinking this is going about it wrong. You're going to be randomly sprinking LFENCEs around forever if you go down this path making stuff slower and slower. Not to mention that it's going to bitrot; the function might change but the LFENCE will stay, protecting nothing but still being slow. I think the focus should be on finding the source sites, not protecting the target sites. Where can an attacker control the register content and have an indirect jump/call. Also, things like FineIBT will severely limit the viability of all this. And how is sprinking random LFENCEs around better than running with spectre_v2=eibrs,retpoline which is the current recommended mitigation against all this IIRC (or even eibrs,lfence for lesser values of paranoia).
On Tue, Oct 25, 2022 at 01:07:52PM +0200, Peter Zijlstra wrote: >On Mon, Oct 24, 2022 at 03:57:45PM -0700, Pawan Gupta wrote: > >> The other goal of this series is to start a discussion on whether such >> hard to exploit, but theoretical possible attacks deems to be mitigated. >> >> In general Branch Target Injection class of attacks involves an adversary >> controlling an indirect branch target to misspeculate to a disclosure gadget. >> For a successful attack an adversary also needs to control the register >> contents used by the disclosure gadget. > >I'm thinking this is going about it wrong. You're going to be randomly >sprinking LFENCEs around forever if you go down this path making stuff >slower and slower. Right, an alternative to LFENCE is to mask the indexes(wherever possible) for gadgets that are called frequently. But still its not a clean solution. >Not to mention that it's going to bitrot; the function might change but >the LFENCE will stay, protecting nothing but still being slow. Totally agree with this. >I think the focus should be on finding the source sites, not protecting >the target sites. Where can an attacker control the register content and >have an indirect jump/call. That is an interesting approach. I am wondering what mitigation can be applied at source? LFENCE before an indirect branch can greatly reduce the speculation window, but will not completely eliminate it. Also LFENCE at sources could be costlier than masking the indexes at targets or LFENCE at the targets. >Also, things like FineIBT will severely limit the viability of all this. Yes. >And how is sprinking random LFENCEs around better than running with >spectre_v2=eibrs,retpoline which is the current recommended mitigation >against all this IIRC (or even eibrs,lfence for lesser values of >paranoia). Its a trade-off between performance and spot fixing (hopefully handful of) gadgets. Even the gadget in question here is not demonstrated to be exploitable. If this scenario changes, polluting the kernel all over is definitely not the right approach.
On Tue, 2022-10-25 at 12:38 -0700, Pawan Gupta wrote: > > > And how is sprinking random LFENCEs around better than running with > > spectre_v2=eibrs,retpoline which is the current recommended mitigation > > against all this IIRC (or even eibrs,lfence for lesser values of > > paranoia). > > Its a trade-off between performance and spot fixing (hopefully handful > of) gadgets. Even the gadget in question here is not demonstrated to be > exploitable. If this scenario changes, polluting the kernel all over is > definitely not the right approach. > Btw, now I'm wondering - you were detecting these with the compiler based something, could there be a compiler pass to insert appropriate things, perhaps as a gcc plugin or something? Now honestly I have no idea if it's feasible, but since you're detecting it that way, and presumably then we'd have to maintain the detection and run it regularly to make sure that (a) things didn't bitrot and the gadget is still there, and (b) no new places show up ... perhaps the better way would be to combine both? johannes
On Tue, Oct 25, 2022 at 12:38:45PM -0700, Pawan Gupta wrote: > > I think the focus should be on finding the source sites, not protecting > > the target sites. Where can an attacker control the register content and > > have an indirect jump/call. > > That is an interesting approach. I am wondering what mitigation can > be applied at source? Limiting the value ranges for example. Or straight up killing the values if they go unused -- like how we clear the registers in entry. > LFENCE before an indirect branch can greatly > reduce the speculation window, but will not completely eliminate it. Depends on the part; there's a whole bunch of parts where LFENCE is sufficient.
On 10/25/22 04:07, Peter Zijlstra wrote: > I think the focus should be on finding the source sites, not protecting > the target sites. Where can an attacker control the register content and > have an indirect jump/call. How would this work with something like 'struct file_operations' which provide a rich set of indirect calls that frequently have fully user-controlled values in registers? It certainly wouldn't *hurt* to be zeroing out the registers that are unused at indirect call sites. But, the majority of gadgets in this case used rdi and rsi, which are the least likely to be able to be zapped at call sites.
On Tue, Oct 25, 2022 at 09:56:21PM +0200, Johannes Berg wrote: >On Tue, 2022-10-25 at 12:38 -0700, Pawan Gupta wrote: >> >> > And how is sprinking random LFENCEs around better than running with >> > spectre_v2=eibrs,retpoline which is the current recommended mitigation >> > against all this IIRC (or even eibrs,lfence for lesser values of >> > paranoia). >> >> Its a trade-off between performance and spot fixing (hopefully handful >> of) gadgets. Even the gadget in question here is not demonstrated to be >> exploitable. If this scenario changes, polluting the kernel all over is >> definitely not the right approach. >> >Btw, now I'm wondering - you were detecting these with the compiler >based something, could there be a compiler pass to insert appropriate >things, perhaps as a gcc plugin or something? I hear it could be a lot of work for gcc. I am not sure if its worth especially when we can't establish the exploitability of these gadgets. There are some other challenges like, hot-path sites would prefer to mask the indexes instead of using a speculation barrier for performance reasons. I assume adding this intelligence to compilers would be extremely hard. Also hardware controls and features in newer processors will make the software mitigations redundant.
On Tue, Oct 25, 2022 at 03:00:35PM -0700, Dave Hansen wrote: > On 10/25/22 04:07, Peter Zijlstra wrote: > > I think the focus should be on finding the source sites, not protecting > > the target sites. Where can an attacker control the register content and > > have an indirect jump/call. > > How would this work with something like 'struct file_operations' which > provide a rich set of indirect calls that frequently have fully > user-controlled values in registers? > > It certainly wouldn't *hurt* to be zeroing out the registers that are > unused at indirect call sites. But, the majority of gadgets in this > case used rdi and rsi, which are the least likely to be able to be > zapped at call sites. Right; so FineIBT will limit the targets to the right set of functions, and those functions must already assume the values are user controlled and take appropriate measures. If you really truly care about the old hardware, then one solution would be to de-virtualize the call using LTO or something (yes, it will need some compiler work and you might need to annotate the code a bit and even have a fixed/predetermined set of loadable modules, but meh). Barring that, you could perhaps put {min,max} range information next to the function pointer such that you can impose value ranges before doing the indirect call. But given this is all theoretical and FineIBT solves a lot of it I can't find myself to care too much.