task_struct: Only use anon struct under randstruct plugin

The original intent for always adding the anonymous struct in task_struct was to make sure we had compiler coverage. However, this caused pathological padding of 40 bytes at the start of task_struct. Instead, move the anonymous struct to being only used when struct layout randomization is enabled.

---
 include/linux/compiler-clang.h |  3 ---
 include/linux/compiler-gcc.h   | 12 +++---------
 2 files changed, 3 insertions(+), 12 deletions(-)

index d3f264a5b04d..ceb96ecab96e 100644
@@ -17,9 +17,6 @@
  */
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
-#define randomized_struct_fields_start	struct {
-#define randomized_struct_fields_end	};
-
 /* all clang versions usable with the kernel support KASAN ABI version 5 */
 #define KASAN_ABI_VERSION 5
 

index e2c7f4369eff..b4bf73f5e38f 100644
@@ -242,6 +242,9 @@
 #if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__)
 #define __randomize_layout __attribute__((randomize_layout))
 #define __no_randomize_layout __attribute__((no_randomize_layout))
+/* This anon struct can add padding, so only enable it under randstruct. */
+#define randomized_struct_fields_start	struct {
+#define randomized_struct_fields_end	} __randomize_layout;
 #endif
 
 #endif /* GCC_VERSION >= 40500 */

@@ -256,15 +259,6 @@
  */
 #define __visible	__attribute__((externally_visible))
 
-/*
- * RANDSTRUCT_PLUGIN wants to use an anonymous struct, but it is only
- * possible since GCC 4.6. To provide as much build testing coverage
- * as possible, this is used for all GCC 4.6+ builds, and not just on
- * RANDSTRUCT_PLUGIN builds.
- */
-#define randomized_struct_fields_start	struct {
-#define randomized_struct_fields_end	} __randomize_layout;
-
 #endif /* GCC_VERSION >= 40600 */
 
 

2.7.4


-- 
Kees Cook
Pixel Security

Why? What caused this padding? It happens in all configs?

So the mysterious 40 byte bloat is still present in this case?

Why cc:stable?

I assume what happens is that the anonymous struct ends up containing fields that are cacheline-aligned, and then the whole anonymous struct is cacheline-aligned.

Which is all kinds of stupid, since the anonymous struct itself does not exist outside of the outer struct. So it would be entirely sufficient to just make the outer struct cacheline aligned (like it used to be), but not align the inner anonymous one - just the fields in it.

But there may be "reasons" why the inner anonymous one needs to be aligned. Maybe it's some standards requirement, or maybe it's just an internal gcc implementation detail.

Regardless, it's a bit sad. It also means that when randomization is on, that unnecessary padding will be there.

I wonder if there is some acceptable trick to avoid it. Maybe the anonymous struct can be marked as not needing alignment, even if the fields inside of it would still need to be aligned wrt the outer struct.

Almost certainly. And the struct randomization will possibly add much *more* padding elsewhere, since at least some of our structures are laid out to try to avoid padding, and then the randomization might be breaking that.

Linus

Since the padding existed in all configs, it's kind of an ugly wart and should likely be fixed up for 4.14 and 4.15 -stable.

Given how insane[1] task_struct can end up under randstruct, these 40 bytes aren't too bad. I've added fixing this to the randstruct to-do list, but I don't view it as high priority.

-Kees
[1] https://git.kernel.org/linus/ffa47aa678cfaa9b88e8a26cfb115b4768325121

Kees Cook
Pixel Security

That didn't tell us much :( Documentation/process/stable-kernel-rules.rst doesn't mention "ugly wart".

I think what you're hearing here is that this patch needs a better changelog, please. Not an uncommon failing, sigh. A better explanation of the origins of this padding and a better explanation of the reasons for backporting the fix.

Yes, structures inherit the alignment requirements of their constituent members.

Last time I read the standard there wasn't a distinction between anonymous and regular structures for this. So in that regards a strict reading of the standard would mandate this behaviour.

The other complaint is that the anonymous structure makes the pahole output (which is what I showed) unnecessarily ugly.