How much entropy is actually gained ?

Posted May 12, 2017 12:11 UTC (Fri) by deater (subscriber, #11746)
In reply to: How much entropy is actually gained ? by moltonel
Parent article: Randomizing structure layout

> While it's certainly a step in the right direction (better
> security with zero runtime cost

Has it been shown to have zero runtime cost?

What about structs that cross cachelines? Suddenly frequently accessed fields that are close together and have good cache behavior might be moved apart.

Or structs that used to be far apart might be moved together and cause false sharing which is a really hard performance issue to track down.

to post comments

How much entropy is actually gained ?

Posted May 12, 2017 19:40 UTC (Fri) by Lionel_Debroux (subscriber, #30014) [Link] (1 responses)

The version of RANDSTRUCT in grsecurity definitely aims at addressing at least your first concern, and possibly your second one as well. The Kconfig snippet corresponding to the GRKERNSEC_RANDSTRUCT_PERFORMANCE config option reads:
+config GRKERNSEC_RANDSTRUCT_PERFORMANCE
+ bool "Use cacheline-aware structure randomization"
+ depends on GRKERNSEC_RANDSTRUCT
+ default y if GRKERNSEC_CONFIG_PRIORITY_PERF
+ help
+ If you say Y here, the RANDSTRUCT randomization will make a best effort
+ at restricting randomization to cacheline-sized groups of elements. It
+ will further not randomize bitfields in structures. This reduces the
+ performance hit of RANDSTRUCT at the cost of weakened randomization.

How much entropy is actually gained ?

Posted May 13, 2017 10:53 UTC (Sat) by aggelos (subscriber, #41752) [Link]

In the absence of any way to quantify the "security" "increase" by this kind of defense, how could one possibly decide whether they want to make this tradeoff or not? I mean, yah, if you can't afford any slowdown at all then sure, you probably want to set this option at least. In the absence of hard "fails to perform adequately"-situations though, this seems to be more of a CYA solution for the vendor, not the user. "Here's a choice that's impossible to make. Take a guess and it's not our fault for the users that get it wrong". There's really a continuum here (e.g. structures consisting only of function pointers are usually singletons, so you can "raise the bar" by blowing them up X% and fill them with booby-trap function pointers) and this applies to most other kinds of probabilistic defenses too.