No error messages that I could find (except one, below). I wouldn't have expected ethernet to be correlated either, but bluetooth definitely is—it's the only thing that requires ecdh_generic on my system (according to lsmod, at least). If bluetooth is turned off (either from BIOS or the wireless hardware switch) the system boots without the kernel oops even with the buggy kernels. And it doesn't seem to mind bluetooth being turned on later, after boot either. It feels like a sort of race condition, and a delay to loading ecdh_generic is sufficient to fix it.
I ended up applying your official (non-nasty) patch to the 4.14 kernel sources and recompiling the module, in the end. And it works great! There's now one cryptic error message during boot, that says
alg: ecdh: test failed on vector 3, err=-14
where -14 is -EFAULT, of course. I imagine this error message is what should have happened all along instead of the kernel oops, so I view it as a good thing!
The mysterious ethernet annoyances still remain, but they're intermittent and work-aroundable, and I agree they are a completely different issue…
Merci beaucoup encore une fois! I won't load up the comment section anymore, I'll try to contact you on email/irc if anything interesting develops!
Ok, after much tribulation I finally did the manual patch. I didn't realise we can excise the whole ecc_gen_privkey()—that is quite drastic, haha!
I tried it on 4.15-rc5, where the address is 0x70+0x23a0. No sign of the oops afterwards! It looks like a clean boot but unfortunately ethernet and bluetooth still didn't come up on my system—it might need some of the things ecc_gen_privkey() was doing, or maybe there's a separate problem for those.
In any case, thank you very much again for teaching me new tricks! As some good news, although it looks like your correction still hasn't been included in RC8, I can see it in the next tree now. So maybe RC9 will have it (or 4.16, at the latest).
My laptop's a Lenovo ThinkPad T430 with an i7-3520M CPU.
I'd love to do the same hex edit you're using, but it's above my knowledge level: I don't know how to work out the address and raw values that need to be set… Comparing disassemblies of 4.13, 4.14 and 4.15-rc5 , there seem to be differences in addresses. But if I understand correctly it's somewhere between 0x2273 - 0x2278 (in 4.13), or 0x2458 - 0x245d (in 4.15-rc5)?
I'm having trouble understanding the gdb disassembly output, but it also looks like the compiler optimized out the "err = -EFAULT" line? If so, how do you insert a return call without shifting other addresses and breaking the .ko?
And to work out what "return -EFAULT" looks like in hex, I suppose you copy bytes from one of the other places it's used?
Thank you for reading this, and don't feel bad if you don't have the time to explain!
Thank you, and sorry about using English! (I can read some French, but not really write/speak anything complex… I used Google Translate for your article, but thought it might be rude to reply using it…)
I haven't made a Debian bug report yet, but I could – would it be helpful? I can contribute some screenshots from my system with 4.15-RC5: https://imgur.com/a/TwLPi
And the Debian compiled version confirms it, still gives a kernel oops. It's really disappointing, as I've been waiting for this patch since 4.13 came out… I wish there was a way to tell the Linux developers this is an important one!
[^] # Re: Not in 4.15-RC5 yet
Posté par razorb . En réponse au journal D'un kernel panic à un patch…. Évalué à 1.
No error messages that I could find (except one, below). I wouldn't have expected ethernet to be correlated either, but bluetooth definitely is—it's the only thing that requires ecdh_generic on my system (according to lsmod, at least). If bluetooth is turned off (either from BIOS or the wireless hardware switch) the system boots without the kernel oops even with the buggy kernels. And it doesn't seem to mind bluetooth being turned on later, after boot either. It feels like a sort of race condition, and a delay to loading ecdh_generic is sufficient to fix it.
I ended up applying your official (non-nasty) patch to the 4.14 kernel sources and recompiling the module, in the end. And it works great! There's now one cryptic error message during boot, that says
alg: ecdh: test failed on vector 3, err=-14
where -14 is -EFAULT, of course. I imagine this error message is what should have happened all along instead of the kernel oops, so I view it as a good thing!
The mysterious ethernet annoyances still remain, but they're intermittent and work-aroundable, and I agree they are a completely different issue…
Merci beaucoup encore une fois! I won't load up the comment section anymore, I'll try to contact you on email/irc if anything interesting develops!
[^] # Re: Not in 4.15-RC5 yet
Posté par razorb . En réponse au journal D'un kernel panic à un patch…. Évalué à 2.
Ok, after much tribulation I finally did the manual patch. I didn't realise we can excise the whole ecc_gen_privkey()—that is quite drastic, haha!
I tried it on 4.15-rc5, where the address is 0x70+0x23a0. No sign of the oops afterwards! It looks like a clean boot but unfortunately ethernet and bluetooth still didn't come up on my system—it might need some of the things ecc_gen_privkey() was doing, or maybe there's a separate problem for those.
In any case, thank you very much again for teaching me new tricks! As some good news, although it looks like your correction still hasn't been included in RC8, I can see it in the next tree now. So maybe RC9 will have it (or 4.16, at the latest).
[^] # Re: Not in 4.15-RC5 yet
Posté par razorb . En réponse au journal D'un kernel panic à un patch…. Évalué à 1.
Alright! I've submitted a Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886556. Hopefully it'll help give the patch an extra push, in Debian at least.
My laptop's a Lenovo ThinkPad T430 with an i7-3520M CPU.
I'd love to do the same hex edit you're using, but it's above my knowledge level: I don't know how to work out the address and raw values that need to be set… Comparing disassemblies of 4.13, 4.14 and 4.15-rc5 , there seem to be differences in addresses. But if I understand correctly it's somewhere between 0x2273 - 0x2278 (in 4.13), or 0x2458 - 0x245d (in 4.15-rc5)?
I'm having trouble understanding the gdb disassembly output, but it also looks like the compiler optimized out the "err = -EFAULT" line? If so, how do you insert a return call without shifting other addresses and breaking the .ko?
And to work out what "return -EFAULT" looks like in hex, I suppose you copy bytes from one of the other places it's used?
Thank you for reading this, and don't feel bad if you don't have the time to explain!
[^] # Re: Not in 4.15-RC5 yet
Posté par razorb . En réponse au journal D'un kernel panic à un patch…. Évalué à 3.
Thank you, and sorry about using English! (I can read some French, but not really write/speak anything complex… I used Google Translate for your article, but thought it might be rude to reply using it…)
I haven't made a Debian bug report yet, but I could – would it be helpful? I can contribute some screenshots from my system with 4.15-RC5: https://imgur.com/a/TwLPi
Thank you again for your work!
# Not in 4.15-RC5 yet
Posté par razorb . En réponse au journal D'un kernel panic à un patch…. Évalué à 2.
It seems this patch still hasn't been applied in 4.15-RC5, the most recent release candidate.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/crypto/ecc.c?id=v4.15-rc5#n943
And the Debian compiled version confirms it, still gives a kernel oops. It's really disappointing, as I've been waiting for this patch since 4.13 came out… I wish there was a way to tell the Linux developers this is an important one!