Linux kernel에서 폐기된 API와 coding 관례

Deprecated pattern 목록이 필요한 이유

이상적으로는 deprecated API의 모든 사용을 새 API로 바꾸고 한 development cycle 안에 old API를 완전히 제거할 수 있어야 한다. 그러나 kernel 규모, maintainer hierarchy, 일정 때문에 한 번에 전환하기 어려운 경우가 많다.

기존 사용을 제거하는 동안 새 사용이 들어오면 API 제거 작업량이 오히려 늘어난다. 무엇이 왜 deprecated되었는지 developer에게 알리고 새 사용이 kernel inclusion 대상으로 제안될 때 가리킬 기준으로 이 목록을 만들었다.

__deprecated attribute의 한계

__deprecated는 interface가 deprecated되었음을 source에서 시각적으로 표시하지만 이제 build warning을 생성하지 않는다. Kernel은 warning 없이 build하는 것을 목표로 하고, warning이 있어도 실제로 old interface를 제거하는 사람이 없었기 때문이다.

Header에서 old API를 표시하는 데에는 유용하지만 완전한 해결책은 아니다. Interface를 kernel에서 완전히 제거하거나 이 문서에 추가하여 향후 사용을 막아야 한다.

• __deprecated warning 제거 commithttps://git.kernel.org/linus/771c035372a036f83353eef46dbb829780330234

BUG()와 BUG_ON() 대신 복구 가능한 처리

BUG()와 BUG_ON() 대신 WARN()과 WARN_ON()을 사용하고 “불가능한” error condition도 가능한 한 정상적으로 처리한다. BUG family는 impossible-state assertion과 kernel thread의 안전한 종료를 목표로 했지만 실제로는 lock 해제 순서와 state 복원 여부를 보장하기 어려워 위험하다.

BUG()는 흔히 system을 불안정하게 하거나 완전히 망가뜨려 debugging과 유효한 crash report 수집까지 불가능하게 한다.

WARN family는 도달하지 않을 것으로 예상하는 상황에만 사용한다. 도달 가능하지만 바람직하지 않은 상황을 알리려면 pr_warn family를 사용한다. System owner가 unreachable condition 뒤 실행을 계속하지 않도록 panic_on_warn sysctl을 설정했을 수 있다.

• BUG 사용에 관한 Linus의 설명 1https://lore.kernel.org/lkml/CA+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO=82SPKCpLQ@mail.gmail.com/
• BUG 사용에 관한 Linus의 설명 2https://lore.kernel.org/lkml/CAHk-=whDHsbK3HTOpTF=ue_o04onRwTEaK_ZoJp_fjbqq4+=Jw@mail.gmail.com/
• panic_on_warn 관련 예https://git.kernel.org/linus/d4689846881d160a4d12a514e991a740bcb5d65a

Allocator argument의 open-coded arithmetic

Dynamic size 계산, 특히 multiplication을 memory allocator argument 안에서 직접 수행하면 overflow로 값이 wrap되어 caller 예상보다 작은 allocation이 생길 수 있다. 이를 사용하면 heap linear overflow와 다른 잘못된 동작이 발생한다. Compiler가 overflow를 경고할 수 있는 literal은 예외일 수 있지만 이 경우도 helper로 바꾸는 편이 낫다.

count * size를 직접 넘기지 않는다.

/* 나쁜 예 */
foo = kmalloc(count * size, GFP_KERNEL);

/* 권장 */
foo = kmalloc_array(count, size, GFP_KERNEL);

kmalloc()은 kmalloc_array(), kzalloc()은 kcalloc()로 교체한다. Two-factor allocator가 없으면 overflow 시 saturate하는 helper를 사용한다.

bar = dma_alloc_coherent(dev, array_size(count, size), &dma,
                         GFP_KERNEL);

Trailing array가 있는 structure 크기도 sizeof와 multiplication으로 직접 계산하지 않는다.

/* 나쁜 예 */
header = kzalloc(sizeof(*header) + count * sizeof(*header->item),
                 GFP_KERNEL);

/* 권장 */
header = kzalloc(struct_size(header, item, count), GFP_KERNEL);

다른 계산은 size_mul(), size_add(), size_sub()를 조합한다.

/* 나쁜 예 */
foo = krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL);

/* 권장 */
foo = krealloc(size_add(current_size,
                        size_mul(chunk_size,
                                 size_sub(count, 3))), GFP_KERNEL);

그 밖에 array3_size(), flex_array_size(), check_mul_overflow(), check_add_overflow(), check_sub_overflow(), check_shl_overflow() family도 사용한다.

simple_strto*()와 string copy API

simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull()은 overflow를 명시적으로 무시하므로 caller가 예상하지 못한 결과를 받을 수 있다. 각각 kstrtol(), kstrtoll(), kstrtoul(), kstrtoull()로 교체한다. 새 API는 string이 NUL 또는 newline으로 끝나야 한다.

strcpy()

strcpy()는 destination bound를 검사하지 않아 buffer 끝을 넘는 linear overflow를 만들 수 있다. CONFIG_FORTIFY_SOURCE=y와 compiler flag가 위험을 줄이지만 새 사용을 추가할 이유는 없다. strscpy()로 교체한다. strcpy()는 destination pointer를 return하지만 strscpy()는 복사한 non-NUL byte 수 또는 truncation 시 negative errno를 return하므로 return value 사용을 함께 수정해야 한다.

NUL-terminated string에 strncpy() 사용

strncpy()는 destination의 NUL termination을 보장하지 않아 linear read overflow 등을 일으킬 수 있다. Source가 destination보다 짧으면 전체 destination을 NUL padding하여 불필요한 성능 비용도 낸다.

NUL termination이 필요하면 strscpy()를 사용하고 return 의미 차이를 처리한다. NUL padding이 필요하면 strscpy_pad()를 쓴다. Non-NUL-terminated string이면 strtomem()을 사용하고 향후 compiler warning을 피하려고 destination에 __nonstring attribute를 붙인다. Padding도 필요하면 strtomem_pad()를 쓴다.

strlcpy()

strlcpy()는 strlen()과 같은 return value를 만들기 위해 source 전체를 먼저 읽는다. 이 read는 destination size limit을 넘을 수 있어 비효율적이며 source가 NUL-terminated가 아니면 linear read overflow를 만들 수 있다. strscpy()로 교체하되 truncation 시 negative errno를 return하는 차이를 처리한다.

• __nonstring GCC attributehttps://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html

%p format specifier

전통적으로 format string의 %p는 dmesg, proc, sysfs 등에서 실제 address를 노출하는 취약점을 만들었다. 현재 kernel의 %p는 exploit을 막으려고 hash된 값을 출력하므로 address로 사용할 수 없다. 새 %p 사용을 추가하지 않는다.

Text address에는 유용한 symbol name을 출력하는 %pS가 더 적절할 수 있다. 그 밖의 대부분은 pointer를 아예 출력하지 않는다.

• Hash된 %p 값이 쓸모없다면 pointer 자체가 정말 필요한지 검토하고 가능하면 출력 전체를 제거한다.
• 실제 pointer가 반드시 필요하다면 특정 system state나 privilege level을 특별히 신뢰할 이유를 묻는다. Comment와 commit log로 충분히 정당화하고 sensible permission을 보장할 수 있을 때만 %px를 검토한다.
• %p hashing이 debugging을 방해하면 임시로 no_hash_pointers debug boot flag를 사용할 수 있다.

• Pointer format 지침https://lore.kernel.org/lkml/CA+55aFwQEd_d40g4mUCSsVRZzrFPUJt74vc6PPpb675hYNXcKw@mail.gmail.com/
• no_hash_pointershttps://git.kernel.org/linus/5ead723a20e0447bc7db33dc3070b420e5f80aa6

Variable Length Array

Stack VLA는 static-size stack array보다 훨씬 나쁜 machine code를 만든다. 성능 문제뿐 아니라 security risk도 있다. Stack array가 dynamic하게 커지면 stack segment의 남은 memory를 넘을 수 있다.

그 결과 crash, CONFIG_THREAD_INFO_IN_TASK=y가 없을 때 stack 끝의 민감한 content overwrite, CONFIG_VMAP_STACK=y가 없을 때 stack 인접 memory overwrite가 생길 수 있다.

• VLA performance issuehttps://git.kernel.org/linus/02361bc77888

Implicit switch fall-through 금지

C는 case 끝에 break가 없으면 다음 case로 fall through한다. 하지만 누락이 의도인지 bug인지 알기 어려워 code가 모호해진다.

switch (value) {
case STATE_ONE:
    do_something();
case STATE_TWO:
    do_other();
    break;
default:
    WARN("unknown state");
}

Missing break로 생긴 defect가 많아 implicit fall-through는 허용하지 않는다. 의도적인 경우 GCC __attribute__((__fallthrough__))로 확장되는 pseudo-keyword macro fallthrough를 사용한다. C17/C18 [[fallthrough]]를 compiler, analyzer, IDE가 더 널리 지원하면 macro도 그 syntax로 바꿀 수 있다.

모든 switch/case block은 다음 중 하나로 끝나야 한다.

• break;
• fallthrough;
• continue;
• goto <label>;
• return [expression];

• CWE-484: Omitted Break Statement in Switchhttps://cwe.mitre.org/data/definitions/484.html
• GCC fallthrough attributehttps://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html

Zero-length와 one-element array를 flexible array로 전환

Structure 끝에 dynamic-size element 집합을 두어야 하는 경우 kernel code는 항상 flexible array member를 사용한다. 오래된 one-element 또는 zero-length array style은 더 이상 사용하지 않는다.

옛 C code는 trailing element를 one-element array로 선언했다.

struct something {
    size_t count;
    struct foo items[1];
};

Header size를 구할 때 trailing element 하나의 크기를 빼야 하므로 sizeof 계산이 취약했다. GNU C zero-length extension은 이 문제를 피하려 했지만 다른 문제를 만들었고 array가 structure 마지막이 아닌 위치에 잘못 쓰이는 것도 검출하지 못했다.

struct something {
    size_t count;
    struct foo items[0];
};

C99 flexible array member는 size를 완전히 생략한다. Kernel이 기대하는 선언은 이 형태다.

struct something {
    size_t count;
    struct foo items[];
};

Compiler는 flexible array가 structure 마지막에 없으면 error를 내어 undefined behavior 유입을 막는다. sizeof(), CONFIG_FORTIFY_SOURCE, CONFIG_UBSAN_BOUNDS도 array size를 올바르게 분석할 수 있다.

• Flexible array memberhttps://en.wikipedia.org/wiki/Flexible_array_member
• GCC zero-length arrayhttps://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
• Flexible array 위치와 UB 관련 fixhttps://git.kernel.org/linus/76497732932f15e7323dc805e8ea8dc11bb587cf

Zero-length array의 sizeof() 함정

Zero-length array에 sizeof()를 적용하면 항상 0이지만 compiler warning이 없다. 다음 code에서 trailing items에 allocation한 전체 byte 수를 계산한다고 생각할 수 있으나 size는 0이 되어 memcpy가 아무 것도 복사하지 않는다.

struct something {
    size_t count;
    struct foo items[0];
};

struct something *instance;

instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL);
instance->count = count;

size = sizeof(instance->items) * instance->count;
memcpy(instance->items, source, size);

Flexible array member는 incomplete type이어서 sizeof()를 적용할 수 없으므로 이런 오용을 build time에 즉시 발견한다.

• Zero-length sizeof bug example 1https://git.kernel.org/linus/f2cd32a443da694ac4e28fbf4ac6f9d5cc63a539
• Zero-length sizeof bug example 2https://git.kernel.org/linus/ab91c2a89f86be2898cee208d492816ec238b2cf

One-element array allocation과 올바른 helper

One-element array는 element 하나만큼 실제 공간을 차지하므로 enclosing structure 크기에 포함된다. Dynamic allocation size를 계산할 때 오류를 만들기 쉽다.

struct something {
    size_t count;
    struct foo items[1];
};

struct something *instance;

instance = kmalloc(struct_size(instance, items, count - 1), GFP_KERNEL);
instance->count = count;

size = sizeof(instance->items) * instance->count;
memcpy(instance->items, source, size);

count - 1을 기억하지 않으면 item 하나를 더 allocation한다. 가장 명확하고 오류가 적은 방법은 flexible array member와 struct_size(), flex_array_size()를 함께 쓰는 것이다.

struct something {
    size_t count;
    struct foo items[];
};

struct something *instance;

instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL);
instance->count = count;

memcpy(instance->items, source,
       flex_array_size(instance, items, instance->count));

DECLARE_FLEX_ARRAY()가 필요한 두 경우

Flexible array가 struct 안에 혼자 있거나 union member인 두 경우에는 DECLARE_FLEX_ARRAY() helper를 사용한다. UAPI header에서는 __DECLARE_FLEX_ARRAY()라는 이름을 쓴다. C99 specification은 기술적 이유 없이 이 배치를 금지하므로 helper가 workaround를 제공한다.

/* 오래된 형태 */
struct something {
    ...
    union {
        struct type1 one[0];
        struct type2 two[0];
    };
};

/* 권장 형태 */
struct something {
    ...
    union {
        DECLARE_FLEX_ARRAY(struct type1, one);
        DECLARE_FLEX_ARRAY(struct type2, two);
    };
};

Struct object allocation에는 kmalloc_obj family 사용

Open-coded kmalloc family assignment는 kernel과 compiler가 destination variable type을 검사하지 못하게 한다. Alignment, wrap-around, 추가 hardening에 유용한 introspection을 제한한다. kmalloc_obj family macro는 single, array, flexible object allocation pattern에 type 정보를 제공한다.

/* open-coded */
ptr = kmalloc(sizeof(*ptr), gfp);
ptr = kzalloc(sizeof(*ptr), gfp);
ptr = kmalloc_array(count, sizeof(*ptr), gfp);
ptr = kcalloc(count, sizeof(*ptr), gfp);
ptr = kmalloc(sizeof(struct foo, gfp);

/* type-aware replacement */
ptr = kmalloc_obj(*ptr, gfp);
ptr = kzalloc_obj(*ptr, gfp);
ptr = kmalloc_objs(*ptr, count, gfp);
ptr = kzalloc_objs(*ptr, count, gfp);
__auto_type ptr = kmalloc_obj(struct foo, gfp);