Migrate to a Linux 6.12 kernel #1808
Comments
|
Sources already out ? Can i get link to source? Btw, where i can met tempesta tech authors in chat? Telegram channel doesnt exist. Irc maybe? Newest lts kernel will be 6.1 according linux kernel maintainer.. Thanks and Best regards |
|
Hi @osevan , so far we have only https://github.com/tempesta-tech/linux-5.10.35-tfw , which should be replaced with a newer longterm kernel in the next release. Unfortunately, we don't have a public chat yet. |
|
Can we create one in telegram? |
|
Hi @osevan , at some time we had a public chat in Slack, but it vanished after some time due to not enough traction. It still makes sense to create a chat (BTW Telegram looks like a good platform) and a Reddit group, but not earlier than we reach GA. |
krizhanovsky
changed the title
|
Probably it makes sense to migrate to 6.8 or later, even not stable yet, to get the TCP performance optimizations |
I have some questions:
|
|
I created new repo for the kernel https://github.com/tempesta-tech/linux-6.8.9-tfw , so please
|
|
I divided this issue into 7 parts:
1. fpu invalid opcode: 0000
Unlike the old version, the new kernel raises softirq even in the boot phase, when fpu related stuff (such as registers or process fpu state) is not ready for manipulation (otherwise exception raised), so it should be enabled in the first 2. paged-skb-patchThe skb stuff is refactored by the latest kernel a lot, for example, now the kernel uses |
3. Assembly problem: endbr64-disallow-indirect-jumpWe have below assembly functions:
Solution
As an aside, interestingly, if a user-mode C program uses a switch statement that meets the conditions for generating a jump table (gcc uses |
kingluo
added a commit
that referenced
this issue
May 14, 2024
This was referenced May 21, 2024
4. kernel crash triggered by test cases4.1 cryptd_queue_workerThis issue is related to fpu. Because fpu save/restore in softirq context has not worked so far, some assumptions of our code are broken:
workaround──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
modified: crypto/simd.c
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
@@ -317,10 +317,10 @@ static int simd_aead_encrypt(struct aead_request *req)
subreq = aead_request_ctx(req);
*subreq = *req;
- if (!crypto_simd_usable() ||
- (in_atomic() && cryptd_aead_queued(ctx->cryptd_tfm)))
- child = &ctx->cryptd_tfm->base;
- else
+ //if (!crypto_simd_usable() ||
+ // (in_atomic() && cryptd_aead_queued(ctx->cryptd_tfm)))
+ // child = &ctx->cryptd_tfm->base;
+ //else
child = cryptd_aead_child(ctx->cryptd_tfm);
aead_request_set_tfm(subreq, child);
logThe cryptd worker queue contains invalid list items whose
4.2 ipv6_dup_options
workaround──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
modified: net/ipv6/tcp_ipv6.c
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
@@ -564,8 +564,8 @@ static int tcp_v6_send_synack(const struct sock *sk, struct dst_entry *dst,
rcu_read_lock();
opt = ireq->ipv6_opt;
- if (!opt)
- opt = rcu_dereference(np->opt);
+ //if (!opt)
+ // opt = rcu_dereference(np->opt);
err = ip6_xmit(sk, skb, fl6, skb->mark ? : READ_ONCE(sk->sk_mark),
opt, tclass, READ_ONCE(sk->sk_priority));
rcu_read_unlock();
@@ -1489,8 +1489,8 @@ static struct sock *tcp_v6_syn_recv_sock(const struct sock *sk, struct sk_buff *
to newsk.
*/
opt = ireq->ipv6_opt;
- if (!opt)
- opt = rcu_dereference(np->opt);
+ //if (!opt)
+ // opt = rcu_dereference(np->opt);
if (opt) {
opt = ipv6_dup_options(newsk, opt);
RCU_INIT_POINTER(newnp->opt, opt);
log
5. userspace segment fault triggered by test cases
|
kingluo
added a commit
that referenced
this issue
May 25, 2024
6. test failures
|
krizhanovsky
changed the title
7. TSO
|
|
Do not forget to remove commit from #2299. This commit is already in new kernel |
|
New LTS kernel 6.12 have been released. It would be better to migrate to this version. |
krizhanovsky
changed the title
const-t
pushed a commit
that referenced
this issue
Feb 7, 2025
const-t
pushed a commit
that referenced
this issue
Feb 19, 2025
const-t
pushed a commit
that referenced
this issue
Feb 19, 2025
const-t
pushed a commit
that referenced
this issue
Feb 19, 2025
#1808 (comment) Problems: 1. In the new kernel, assembly functions uniformly return from `__x86_return_thunk`. However, our assembly code uses the original `ret` instruction, so objtool in the kernel will notice this is a naked return during compilation. 2. `SYM_FUNC_START` in the new kernel will add endbr64 to the head of the assembly function, and all indirect jumps to ENDBR instructions, that is, the code snippet within the same function, will fail, but we use jump tables in the assembly function to perform indirect jumps. It will raise CET exception: https://en.wikipedia.org/wiki/X86_instruction_listings#Added_with_Intel_CET). Solutions: 1. Substitute the `ret` with `RET`, a macro in the new kernel to ensure the correct return. 2. `notrack jmp` and enable notrack in CPU setting: `wrmsrl(MSR_IA32_S_CET, CET_ENDBR_EN | CET_NO_TRACK_EN)` As an aside, interestingly, if a user-mode C program uses a switch statement that meets the conditions for generating a jump table (gcc uses `-fcf-protection=full` by default), the generated jump table will use a `jmp` with the `notrack` prefix, and IBT will be marked as `true` in the `.note.gnu.property` section of the compiled elf file, so that the `NO_TRACK_EN` of the `MSR` will be set to `true` in user mode when the kernel is loaded. So user mode can use `notrack` to bypass CET without caring about setting or not setting `NO_TRACK_EN`. bignum_x86-64.S: replace ret with RET, to use __x86_return_thunk
const-t
pushed a commit
that referenced
this issue
Feb 19, 2025
#1808 (comment) Problems: 1. In the new kernel, assembly functions uniformly return from `__x86_return_thunk`. However, our assembly code uses the original `ret` instruction, so objtool in the kernel will notice this is a naked return during compilation. 2. `SYM_FUNC_START` in the new kernel will add endbr64 to the head of the assembly function, and all indirect jumps to ENDBR instructions, that is, the code snippet within the same function, will fail, but we use jump tables in the assembly function to perform indirect jumps. It will raise CET exception: https://en.wikipedia.org/wiki/X86_instruction_listings#Added_with_Intel_CET). Solutions: 1. Substitute the `ret` with `RET`, a macro in the new kernel to ensure the correct return. 2. `notrack jmp` and enable notrack in CPU setting: `wrmsrl(MSR_IA32_S_CET, CET_ENDBR_EN | CET_NO_TRACK_EN)` As an aside, interestingly, if a user-mode C program uses a switch statement that meets the conditions for generating a jump table (gcc uses `-fcf-protection=full` by default), the generated jump table will use a `jmp` with the `notrack` prefix, and IBT will be marked as `true` in the `.note.gnu.property` section of the compiled elf file, so that the `NO_TRACK_EN` of the `MSR` will be set to `true` in user mode when the kernel is loaded. So user mode can use `notrack` to bypass CET without caring about setting or not setting `NO_TRACK_EN`. bignum_x86-64.S: replace ret with RET, to use __x86_return_thunk
const-t
pushed a commit
that referenced
this issue
Feb 19, 2025
#1808 (comment) Problems: 1. In the new kernel, assembly functions uniformly return from `__x86_return_thunk`. However, our assembly code uses the original `ret` instruction, so objtool in the kernel will notice this is a naked return during compilation. 2. `SYM_FUNC_START` in the new kernel will add endbr64 to the head of the assembly function, and all indirect jumps to ENDBR instructions, that is, the code snippet within the same function, will fail, but we use jump tables in the assembly function to perform indirect jumps. It will raise CET exception: https://en.wikipedia.org/wiki/X86_instruction_listings#Added_with_Intel_CET). Solutions: 1. Substitute the `ret` with `RET`, a macro in the new kernel to ensure the correct return. 2. `notrack jmp` and enable notrack in CPU setting: `wrmsrl(MSR_IA32_S_CET, CET_ENDBR_EN | CET_NO_TRACK_EN)` As an aside, interestingly, if a user-mode C program uses a switch statement that meets the conditions for generating a jump table (gcc uses `-fcf-protection=full` by default), the generated jump table will use a `jmp` with the `notrack` prefix, and IBT will be marked as `true` in the `.note.gnu.property` section of the compiled elf file, so that the `NO_TRACK_EN` of the `MSR` will be set to `true` in user mode when the kernel is loaded. So user mode can use `notrack` to bypass CET without caring about setting or not setting `NO_TRACK_EN`. bignum_x86-64.S: replace ret with RET, to use __x86_return_thunk Use endbr64 on each switch label
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We were living with 5.10 for too long, it's time to migrate to the 6.1 longterm kernel.
Please update all the https://github.com/tempesta-tech/tempesta/wiki pages referencing the old kernel.
Please also grep and fix all
TODO #1808comments.The text was updated successfully, but these errors were encountered: