Discussion:
Randomizing structure layout
Add Reply
Noob
2017-08-02 21:45:05 UTC
Reply
Permalink
Raw Message
Hello,

This article discusses a gcc plugin making the compiler
shuffle the order of struct fields (and possibly insert
random padding).

https://lwn.net/Articles/722293/

IIUC, this makes gcc non-conforming, because the standard
requires to be stored in the order specified by the code
[C99 6.7.2.1p13] Is that correct?

http://port70.net/~nsz/c/c99/n1256.html#6.7.2.1p13
Within a structure object, the non-bit-field members and the units in
which bit-fields reside have addresses that increase in the order in
which they are declared. A pointer to a structure object, suitably
converted, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides), and vice versa.
There may be unnamed padding within a structure object, but not at
its beginning.
Regards.
Richard Heathfield
2017-08-02 21:54:21 UTC
Reply
Permalink
Raw Message
Post by Noob
Hello,
This article discusses a gcc plugin making the compiler
shuffle the order of struct fields (and possibly insert
random padding).
https://lwn.net/Articles/722293/
IIUC, this makes gcc non-conforming, because the standard
requires to be stored in the order specified by the code
[C99 6.7.2.1p13] Is that correct?
Yes, to invoke such a plug-in would indeed make gcc non-conforming, and
for the reason you state.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
David Brown
2017-08-03 08:38:21 UTC
Reply
Permalink
Raw Message
Post by Richard Heathfield
Post by Noob
Hello,
This article discusses a gcc plugin making the compiler
shuffle the order of struct fields (and possibly insert
random padding).
https://lwn.net/Articles/722293/
IIUC, this makes gcc non-conforming, because the standard
requires to be stored in the order specified by the code
[C99 6.7.2.1p13] Is that correct?
Yes, to invoke such a plug-in would indeed make gcc non-conforming, and
for the reason you state.
No, it would not make gcc non-conforming, for several reasons. First,
of course, is that gcc is already non-conforming by default!

This patch only applies to structures that are specifically marked
"__randomize_layout", which is a gcc extension.

And as always, there is the "as if" rule. If code accessing the
structures could do so "as if" the structs were laid out in the
standards specified order, then it would still be conforming. It does
not look like this is the case here, but it /could/ be.

For a while, gcc had an optimisation that would re-order struct fields
for better packing and alignment - but only in cases where that would
not affect other code (assuming, of course, that the other code used
only properly defined ways of accessing the structs). That optimisation
was dropped in later versions because it got too complicated to track
the changes when doing link-time optimisation, but it was a "legal"
optimisation.
Richard Heathfield
2017-08-03 08:45:47 UTC
Reply
Permalink
Raw Message
Post by David Brown
Post by Richard Heathfield
Post by Noob
Hello,
This article discusses a gcc plugin making the compiler
shuffle the order of struct fields (and possibly insert
random padding).
https://lwn.net/Articles/722293/
IIUC, this makes gcc non-conforming, because the standard
requires to be stored in the order specified by the code
[C99 6.7.2.1p13] Is that correct?
Yes, to invoke such a plug-in would indeed make gcc non-conforming, and
for the reason you state.
No, it would not make gcc non-conforming, for several reasons. First,
of course, is that gcc is already non-conforming by default!
Ha! Your nits are so much finer than my nits! Do you breed them for shows?
Post by David Brown
This patch only applies to structures that are specifically marked
"__randomize_layout", which is a gcc extension.
In my defence, that information had not been brought into evidence at
the time I wrote my reply (unless it's on that Web page, which *of
course* I didn't read, because if it contained any further relevant
information the OP would *of course* have provided it in the body of his
article).
Post by David Brown
And as always, there is the "as if" rule.
That's a more reasonable nit, although surely it would be easier to make
the behaviour "as if" it were conforming simply by laying the fields out
in the right order in the first place.

On reflection, I stand by my reply, modulo your nits. But I will be
cheering for them at the next awards ceremony.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
David Brown
2017-08-03 10:34:42 UTC
Reply
Permalink
Raw Message
Post by Richard Heathfield
Post by David Brown
Post by Richard Heathfield
Post by Noob
Hello,
This article discusses a gcc plugin making the compiler
shuffle the order of struct fields (and possibly insert
random padding).
https://lwn.net/Articles/722293/
IIUC, this makes gcc non-conforming, because the standard
requires to be stored in the order specified by the code
[C99 6.7.2.1p13] Is that correct?
Yes, to invoke such a plug-in would indeed make gcc non-conforming, and
for the reason you state.
No, it would not make gcc non-conforming, for several reasons. First,
of course, is that gcc is already non-conforming by default!
Ha! Your nits are so much finer than my nits! Do you breed them for shows?
Nit-picking is a common pastime in c.l.c. Deep down, we are all just a
bunch of great apes keeping each other's furs clean.
Post by Richard Heathfield
Post by David Brown
This patch only applies to structures that are specifically marked
"__randomize_layout", which is a gcc extension.
In my defence, that information had not been brought into evidence at
the time I wrote my reply (unless it's on that Web page, which *of
course* I didn't read, because if it contained any further relevant
information the OP would *of course* have provided it in the body of his
article).
Sorry to say - it was on the web page...

However, on the other hand the web page also notes that the structs
containing nothing but function pointers are considered
"__randomize_layout" by default (unless you specify
"__no_radnomize_layout") because they are very unlikely to have problems
with randomisation, and very big targets for attacks.

On the third hand, Mr. Beeblebrox, the whole plugin only applies if you
actively choose to enable it.
Post by Richard Heathfield
Post by David Brown
And as always, there is the "as if" rule.
That's a more reasonable nit, although surely it would be easier to make
the behaviour "as if" it were conforming simply by laying the fields out
in the right order in the first place.
The point of the randomizing struct plugin is that it will vary the
layouts randomly (but deterministically, based on a supplied seed). So
if some bad person gets a way to write to a kernel struct, he can't make
use of it to elevate the attack because he does not know the layout of
the struct. If he knows the seed used for the build, he can figure it
out - but with significant effort.
Post by Richard Heathfield
On reflection, I stand by my reply, modulo your nits. But I will be
cheering for them at the next awards ceremony.
Well, it is not a feature that is intended to be conforming or
standardised in any way. If it becomes popular in kernel builds (note
that Torvalds is "unimpressed"), it could be used in other
security-critical software. But it would always be an implementation
feature, not a conforming one.

Loading...