Handle kernel cache TEXT __const section as possibly writable

[emesare]

It appears that in certain cases we should be treating the __const section in the TEXT segment as writable, looking at other analysis tools it is not always writable so there is some other factor for when we should do this. The driving factor behind this change is that some loader initialized data is being stored in that section and the uninitialized data we are presenting is being picked up by analysis and used in constant value propagation, eliminating code paths and otherwise tainting analysis.

[emesare]

Related: #6717 we should be able to mark the data in that section as volatile, however some of this data is structures / enums which we currently do not parse correctly.

[emesare]

For users trying to do this themselves (mark the section as writable) they will run into the issue that the segment permissions (r-x) supersede that of the section semantics.

This means that the user cannot prevent constant value propagation from the uninitialized data variables, without retyping each one as volatile, which because of #6717 is not actually possible.

As an aside, we have no concept of variable attributes (either in analysis or in data variables) so we cant even markup the variable as volatile independent of the associated type.

[emesare]

Solutions:

1. Provide a psuedo-segment to cover TEXT __const sections, that way we don't need to fight the segment permissions to make the section writable.
2. Markup all data-variables as volatile, and provide some easy keybind to adjust data variable types, and do Volatile structure support #6717.
3. Prioritize sections over segments in IsOffsetWritableSemantics allowing the user to actually mark the __const section as writable.

I am partial to 3 as it is instinctively the first thing a user would reach for and do. 1 would have the same effect but would cause a lot of special casing in code that otherwise is broad and not opinionated. 2 is the most granular and should be done regardless IMO.

The issue with 3 is currently that code is "correct" from the perspective of a "access rights" of the memory page, to make the section supersede the segment.

[bdash]

Do you have some specific examples of this? AFAIK the __TEXT segments should always be read-only. I'm curious what's going on.

[emesare]

Do you have some specific examples of this? AFAIK the __TEXT segments should always be read-only. I'm curious what's going on.

User is looking at a kernel cache in what looks like loader stage of the main kernel image. I presume that would be initializing the uninitialized data. I have not really gotten a clear description of the impact, so this ticket had a pretty broad title.

The issue is more so that the user cannot adjust the section permissions to align with the fact it is writable and expect analysis to pick it up, as the segment it resides in is read-only and will supersede the sections semantics.

I am going to remove shared cache from the ticket as i believe what i was seeing in other tools in shared cache was actually a result of their different section/segment model.