[General Omni Discussion] Lanchon:
it's easy to write a userland clobber detector. the problem is, if FP context switching is working correctly, no other userland thread can corrupt the FP. only a kernel thread could do it.

but then, judging by what ive read so far about linux and FPU in arm, my guess would be that the kernel disables the FPU on switching to a kernel thread, so any FPU instruction should trap and the kernel would probably panic or something like that. (or maybe it would restore the FP context of the current userland process and resume? no check for this dangerous situation? sounds improbable.) it's not actually *needed* to disable the FPU, but it would be so much safer to do it; i just have to suppose they do it. btw, the kernel *has* to disable the FPU when context-switching to all user threads, and a special case for kernel threads that makes things dangerous doesnt make sense (with my current knowledge). (checking this assumption is very low on my to-do list, if at all.)

to use the FPU, a kernel thread would need to first call kernel_vfp_begin or kernel_neon_begin. problem here is:

-it would be ok (no FP corruption then)

-we dont even have these functions in our kernels!!

a very rouge kernel module could just static link them of course. in fact, all a kernel thread needs to do to use the FPU (unsafely, corrupting FP in userland) is enabled it, maybe with something like this: fmxr(FPEXC, fmrx(FPEXC) | FPEXC_EN); but who would do such a thing on purpose?

well someone could. maybe she was tasked with increasing performance of some kernel driver and she needed NEON or VFP. but the kernel didn't support kernel FPU usage and she couldn't pull in those changes, so she just hacked the support into the kernel module. when the kernel evolved the hacks became incompatible and the thing breaks. now... this story i can't believe!

but most importantly, where would this code be hiding? i objdumped the kernel and all *.ko files in CM11-M10 and didn't find references to the FPU registers. is there any other place where kernel code could reside? i ask because i really don't know linux at all.

there's an exception to all this: ISRs. ISRs can be invoked with the FPU enabled or disabled, and could invoke instructions. sometimes they would corrupt FP, and sometimes they would trap. would the kernel panic? or would it restore the FP context of the interrupted userland process into the FPU (just as if that process had used the FPU) and resume the ISR? who knows. but then the ISR could interrupt a kernel thread, and then the kernel would react to the FPU trap at least as badly as using the FPU directly from a kernel thread... panic?

the thing is that *everybody knows* not to use FPU from an ISR. all things would go to hell. and you have to keep in mind that this codebase works under the 4412 just fine.

so what you expect to find? a kernel thread that corrupts FP regs? ok... where would that code be? if it can only be in the kernel or the *.ko files, i can't find a single FPU instruction there with objdump -d. propose an alternative hiding place for the code and i could think that doing that instrumentation might help.

the more i read about arm linux, the fewer possible causes for FP corruption remain plausible.

regarding disabling stuff, i don't have a device a test nor i know linux enough to run those tests. i can hunt this thing bottom-up, but to look for it top-down you need someone else.

---------- Post added at 06:36 AM ---------- Previous post was at 06:33 AM ----------

yes, and many other options. just not believable. name a plausible source for the corruption of that data structure and maybe someone will investigate the possibility. we KNOW arm linux kernel is ok, it can only be misconfigured.