How would you measure that? How would you notice a failed attempt at finding a hole, of stack smashing, etc, if it did not even result in a crash, or any other dysfunction?

Not a rhetorical question.

I suppose if someone found a technique in the wild that defeats regular ASLR (even if only sometimes), they could then test that same technique against fine-grained ASLR and evaluate if the FG ASLR was more effective at preventing exploitation.

Any classic buffer overflow/stackssmash can defeat ASLR, it just might take a long time to get lucky guessing addresses. Couldn’t we Monte Carlo this?

Maybe take a known vulnerable exec, create a fuzzing attacker and run it both ways seeing how long it takes to get lucky a few times. The more secure version should take longer.

There are whitehats constantly looking at this sort of thing. It's why we can say that KASLR is a huge waste of time - because it's both theoretically bogus and we have actual exploit devs saying that they don't care about it.

It's not about failed attempt at finding a hole, it's about failed attempt at actually making use of a hole (i.e. write an exploit) given a hole.

(FG)ASLR is more of a "targeting at exploit instead of vulnerability" style mitigation.

My guess is you look for a security POC that reads something like "We were unable to build the ROP chain on openbsd due to the gadget locations being unknowable."

The traditional antidote to ASLR is "known code reuse", tricks like ret2libc, ret2plt, etc.

FG-ASLR helps a lot because there are now N possible randomized locations for the piece of code your exploit leverages, so if you pick one and exploit M machines that way, only M/N of the exploits will succeed (where you got lucky).

Ultimately it is obfuscation, but with enough entropy it is very effective. It can't mitigate or prevent an exploit, but it makes it a lot more work to turn an exploit into code execution consistently enough for it to be useful.