읽는 데 8분Cat

Linux 라우팅 조회가 느려진 이유, 함수에서 돌아오는 비용이었어요

2026-11-11 IT 개발원리 인프라

Linux 커널을 새로 올렸는데 경로 조회가 느려졌다면, 라우팅 코드만 볼 일은 아닐 수 있어요. 네트워크 개발자 Vincent Bernat의 EPYC 8024P 측정에서는 SRSO라는 CPU 취약점의 보안 완화가 IPv6 조회에는 약 200ns, IPv4에는 약 30ns를 더했어요.

같은 보호 기능인데 왜 차이가 클까요. 이 완화는 함수가 일을 마치고 호출한 곳으로 돌아갈 때 비용을 더해요. 경로 하나를 찾는 동안 함수를 얼마나 많이 거치는지가 차이를 만들었죠. 측정 결과에 커널의 공식 보호 상태 설명과 실제 최적화 패치를 붙여 보면, 새 커널이 느리다는 그래프를 읽을 때 확인할 조건이 보여요.

같은 조회인데 왜 비용이 다를까요

경로 조회는 목적지 주소를 보고 어느 네트워크 경로로 보낼지 찾는 일이에요. Bernat은 AMD EPYC 8024P를 2.4GHz로 고정하고 부스트를 끈 조건에서 여러 커널의 조회 시간을 비교했어요.

그가 지목한 큰 변화는 Linux 6.5의 SRSO 완화예요. SRSO는 CPU가 함수의 복귀 위치를 미리 예측하는 동작을 악용해 정보를 알아낼 수 있는 취약점이에요. 커널의 Safe RET 방식은 복귀 예측이 통제된 안전한 위치를 향하도록 만들어요. 그 대가로 함수 복귀 때 추가 작업이 생기죠.

원문이 설명하는 추가 비용은 함수 복귀당 약 20 CPU 사이클이에요. CPU 사이클은 프로세서의 한 박자로 생각하면 돼요. 저자가 비교한 경로는 IPv4가 대략 네 번의 함수 호출을 거치는 데 비해 IPv6는 약 25번을 거쳐요. 같은 비용이 더 자주 붙는 셈이에요.

EPYC 8024P 측정에서 SRSO 완화의 추가 조회 지연은 IPv6 약 200ns, IPv4 약 30ns였다 — EPYC 8024P, 2.4GHz, 부스트 해제 조건의 추가 지연이에요. 두 프로토콜의 전체 조회 시간을 비교한 값은 아니에요.

이 수치는 경로를 찾는 작은 작업의 시간이므로, 웹페이지 로딩이나 네트워크 전체 처리량에 그대로 옮겨 붙일 수는 없어요.

빨랐던 옛 커널도 같은 조건이었을까요

원문 그래프의 별표부터 봐야 해요. SRSO 완화는 구형 커널 계열에도 나중에 반영됐지만, 저자는 비교를 읽기 쉽게 하려고 일부 구형 버전에서 이를 끄고 별표를 붙였어요. 별표가 붙은 옛 커널과 보호가 켜진 새 커널은 보안 조건이 달라요.

그래서 커널 버전과 함께 실제 완화 상태를 비교해야 해요. 커널 문서는 다음 파일에 SRSO 상태가 표시된다고 안내해요. 설정을 바꾸지 않고 내용을 읽을 수 있어요.

cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow

문구에 Microcode가 들어 있다고 모든 경계가 보호되는 것도 아니에요. 마이크로코드는 CPU 동작을 보완하는 낮은 수준의 업데이트예요. 표의 사용자는 사용자 프로그램을 뜻해요. 게스트는 가상 머신(VM), 호스트는 이를 실행하는 시스템이에요. 공식 문서의 상태 설명을 비교하면 다음 차이가 있어요.

표시되는 상태	보호 범위를 볼 때의 차이
`Vulnerable: Safe RET, no microcode`	커널용 Safe RET는 적용됐지만, 보완 마이크로코드가 없어 사용자 프로세스는 여전히 취약할 수 있어요
`Vulnerable: Microcode, no safe RET`	사용자→커널과 게스트→호스트 경계를 보호하지 못해요. 사용자끼리·VM끼리의 경계에는 마이크로코드가 대응하며, 사용자끼리의 보호는 별도 IBPB 정책에도 달려요
`Mitigation: Safe RET`	마이크로코드와 소프트웨어 보호를 결합해 사용자→커널과 게스트→호스트 경계까지 보완해요

IBPB는 예측 정보를 경계에서 정리하는 보호 동작이에요. 표는 SRSO에 관한 상태 구분이며, 다른 CPU 취약점까지 전부 해결됐다는 판정은 아니에요.

자신의 시스템과 원문을 견줄 때는 CPU, 마이크로코드, 커널, 이 상태 문구를 함께 기록해야 해요. 배포판이 같은 계열 커널에 수정을 가져올 수 있으니 버전 번호만으로 보호 유무를 추정하지 않는 편이 정확해요.

보안 기능을 끄지 않고 줄인 비용도 있어요

같은 글에는 별도의 IPv4 최적화도 나와요. 네트워크 링크가 내려간 경우를 처리하는 조건문의 순서를 바꾼 패치예요.

이전에는 설정을 확인하는 ip_ignore_linkdown()을 먼저 불렀어요. 그다음에 링크가 실제로 내려갔는지 봤죠. 패치는 링크 상태부터 확인하도록 바꿔서, 정상 링크라면 뒤의 설정 조회를 건너뛸 수 있게 했어요. &&로 연결한 조건은 앞이 거짓이면 뒤를 평가하지 않는다는 성질을 이용해요.

변경 전에는 설정 조회 뒤 링크 상태를 검사했고, 변경 후에는 정상 링크일 때 첫 검사에서 종료해 설정 조회를 생략한다 — 정상 링크일 때의 차이만 요약했어요. 링크가 내려간 경우의 나머지 조건은 코드에 그대로 있어요.

패치 커밋의 50만 개 /32 경로 시험에서는 조회 시간 중앙값이 132사이클에서 126사이클로 줄었어요. 감소율을 계산하면 약 4.5%예요. 하지만 같은 커밋의 평균은 134사이클에서 133사이클로 바뀌었어요.

중앙값의 4.5% 감소를 전체 네트워크가 4.5% 빨라졌다고 읽으면 안 돼요. 중앙값은 측정값을 늘어놓았을 때 가운데 값이고, 평균은 큰 지연값의 영향도 받아요. 지표를 바꾸면 같은 시험에서도 효과의 크기가 달라 보여요.

이 패치는 보안 완화를 해제하는 대신 자주 지나는 경로에서 불필요한 조회를 줄여요. 원문의 큰 비용 차이와 작은 최적화를 구분해 보면, 성능 분석의 출발점도 구체적이에요. 먼저 보호 조건을 맞추고, 그다음 어떤 경로에서 비용이 반복되는지 보는 거죠.

확인한 범위

기준일: 2026-11-11
직접 한 것: 원문의 측정 조건을 SRSO 공식 문서의 보호 상태와 대조했어요. IPv4 패치의 조건 순서와 평균·중앙값을 확인하고 중앙값 감소율을 새로 계산했어요.
읽은 것: Bernat의 분석 전문, 커널 SRSO 문서, IPv4 조건 재정렬 커밋.
확인하지 못한 것: 벤치마크를 재현하거나 보안 완화를 변경하지 않았어요. 다른 CPU와 실제 서비스의 효과, 사용 중인 배포판에 해당 IPv4 패치가 포함됐는지는 별도로 확인해야 해요.