Messages in this thread | | | Date | Wed, 19 Oct 2022 12:35:25 -0700 | From | Joao Moreira <> | Subject | Re: [PATCH] x86/ibt: Implement FineIBT |
| |
>> > >> If we look back at how well ASLR did over the years I think we can't >> really >> rely that randomizing the hashes will solve anything. So what you are >> suggesting is that we flip a "viable defence against SpectreBHB" for a >> randomization-based scheme, when what we really should be doing is >> getting >> constant blinding enabled by default. > > I don't think any of these things are mutually exclusive. The > randomization means an additional step (and possibly additional > primitive) > is needed for an attack chain. Since we get this from a one-time cost > on our end, that seems like reasonable value. > I think I misunderstood your original comment/suggestion, so my bad for the noise.
And yeah, I agree that randomization is relevant from the perspective of security in depth. With this said, FWIIW, all suggestions sound good to me.
>> >> Assuming we got 16 bytes padding to play with on each function >> prologue, you >> can randomize between 0-11 in which offset you emit the ENDBR >> instruction. >> Caller/Callee would look like (hopefully I did not mess-up offset): >> >> <caller>: >> and 0xf3, r11b >> call *r11 >> >> <callee>: >> nop >> nop >> nop >> endbr // <- this position is randomized/patched during boot time. >> nop >> nop >> ... >> >> And of course, you get more entropy as you increase the padding nop >> area. > > Oh, I kind of like this -- it'd need to be per matching hash. This > would > require roughly 3 bits of entropy exposure of the .text area. For X^R, > that becomes annoying for an attacker, though likely once close enough, > multiple attempts could find it, assume panic_on_oops/warn wasn't set. > > Anyway, this sounds like an interesting idea to keep in our back > pocket...
Agreed. It is hard to implement this because the space overhead would be too big for meaningful entropy. Yet, again, could be a trick in a swiss army knife for future problems.
Tks, Joao
| |