인프런 커뮤니티 질문&답변

cred 구조체 소스코드를 elixir를 통해 확인해보니 다음과 같았습니다. (실습 버전인 5.8.5 기준)

struct cred {
	atomic_t	usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
	atomic_t	subscribers;	/* number of processes subscribed */
	void		*put_addr;
	unsigned	magic;
#define CRED_MAGIC	0x43736564
#define CRED_MAGIC_DEAD	0x44656144
#endif
	kuid_t		uid;		/* real UID of the task */
	kgid_t		gid;		/* real GID of the task */
	kuid_t		suid;		/* saved UID of the task */
	kgid_t		sgid;		/* saved GID of the task */
	kuid_t		euid;		/* effective UID of the task */
	kgid_t		egid;		/* effective GID of the task */
	kuid_t		fsuid;		/* UID for VFS ops */
	kgid_t		fsgid;		/* GID for VFS ops */
	unsigned	securebits;	/* SUID-less security management */
	kernel_cap_t	cap_inheritable; /* caps our children can inherit */
	kernel_cap_t	cap_permitted;	/* caps we're permitted */
	kernel_cap_t	cap_effective;	/* caps we can actually use */
	kernel_cap_t	cap_bset;	/* capability bounding set */
	kernel_cap_t	cap_ambient;	/* Ambient capability set */
#ifdef CONFIG_KEYS
	unsigned char	jit_keyring;	/* default keyring to attach requested
					 * keys to */
	struct key	*session_keyring; /* keyring inherited over fork */
	struct key	*process_keyring; /* keyring private to this process */
	struct key	*thread_keyring; /* keyring private to this thread */
	struct key	*request_key_auth; /* assumed request_key authority */
#endif
#ifdef CONFIG_SECURITY
	void		*security;	/* subjective LSM security */
#endif
	struct user_struct *user;	/* real user ID subscription */
	struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
	struct group_info *group_info;	/* supplementary groups for euid/fsgid */
	/* RCU deletion */
	union {
		int non_rcu;			/* Can we skip RCU deletion? */
		struct rcu_head	rcu;		/* RCU deletion hook */
	};
} __randomize_layout;

이 중 마지막 __randomize_layout 이 뭔지 찾아보니 커널에서 정의한 매크로이고 구조체의 순서를 랜덤화하는 일종의 보호 기법이라는 것을 알았습니다.

실습을 따라가보니 uid, gid, suid, sgid를 순서대로 덮기 때문에 현재 커널에서 이 보호 기법이 적용되지 않았다는 것을 알 수 있었습니다.

이 매크로의 정의 부분은 총 두 부분이고 다음과 같았습니다.

#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

#ifndef __randomize_layout
# define __randomize_layout __designated_init
#endif

첫 번째 부분에서는 flag처럼 보이는 RANDSTRUCT_PLUGIN 과 __CHECKER__ 에 cross reference(?)가 더이상 안돼서 확인은 못했습니다만, 이게 define 되어있으면 __randomize_layout 매크로를 정의하는 것 같아보입니다.

반대로 flag가 켜져있지 않아 첫 번째 부분에서 매크로 선언이 이뤄지지 않으면 두 번째 부분에서 __designated_init 으로 어쨌든 선언은 되는 것 같습니다.

마지막으로 __designated_init 의 선언 부분을 보면 다음과 같습니다.

#if __has_attribute(__designated_init__)
# define __designated_init              __attribute__((__designated_init__))
#else
# define __designated_init
#endif

첨부는 했지만 어떻게 동작하는건지 잘 모르겠어서 여기부터 이해가 안됐습니다...

제 질문은 다음과 같습니다.

1. 구조체 멤버 랜덤화가 적용되어야 할 것 같은데 강의자님께서 일부러 커널을 빌드할 때 소스코드를 수정하신건가요?

2. 아니라면 __designated_init__ 이 없기 때문에 빈 매크로가 할당된 것 같은데, 이게 어떤 플래그이며 어떻게 키고 끌 수 있는건가요?

3. 커널 소스코드를 확인할 때 RANDSTRUCT_PLUGIN 과 __CHECKER__ 같이 더 이상 cross reference가 불가능한 경우는 어떻게 값을 확인할 수 있나요?

4. 정작 __randoimze_layout 이 붙었을 때 어떻게 메모리 레이아웃을 변경하는지에 대한 로직은 못찾았는데, 이런 부분은 어디서 확인할 수 있을까요?

5. 강의자님 경험상 대회나 리얼월드 커널에서 구조체 멤버 랜덤화가 잘 적용되어있는 편인가요?

질문이 길어졌는데, 답변주시면 큰 도움이 될 것 같습니다. 감사합니다.