You are welcome.
To sidetrack, there is a longstanding vulnerability/security bug or just a "feature" of linux kernel though:
If you compile any program with "float" or "double" type declaration, you will see that a lot of "XMM" registers and its instruction set being used. But searching the entire kernel source for XMM, we know the kernel don't touch these registers.
So if u were to do your security keys calculation on these registers, then beware that upon being context-switched (which can happened anytime, beyond your control), another process can easily view all the XMM registers contents, and thus potentially looking at your secret keys.
Same goes with the GPU as well (which has been commonly used for password cracking) - simply because the kernel don't touch these "memory" sources inside the kernel, and thus cross-process it is possible to have information leakage.
On Wed, Jul 30, 2014 at 12:31 AM, Prasad Ram <prasad.ram126@xxxxxxxxx> wrote:
Thanks @Peter a very good explanation and it's very help full to me.On 29 July 2014 19:49, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
Perhaps a little explanation: anything that can be done at userspace, should not be done at the kernel, simply because doing at the kernel entailed a lot of security privileges being available. (ie, logic which require hardware interaction / access, process scheduling logic or anything cutting across processes, sharing of common resources like memory etc) floating point arithmetics is a good example which is not necessary to be done in the kernel. Lots of hardware registers are available for FPU stuff (SSE/SSE2/XMM registers etc):and generally their usage entailed a lot of performance hits when used extensively (another good reason to avoid it). And more importantly, context switching as provided by Intel processor, the hardware operation does not include the floating pointers registers (simply because there are so many of them, and XMM can be like 128 bytes long?) Context switching will swap out the entire registers set when switching from one process to another, and if u were to do this for all the process, when 99% of the time floating point are not in use, it is a terrible waste of CPU cycle.Userspace can only interact with the kernel through well-defined syscall - for purpose of security, interprocess, or hardware access etc. So generally it is not possible to schedule floating point instruction (or any user-defined instructions for that matter) to be executed in the kernel.But it is possible to schedule floating point arithmetics to be executed in the kernel indirectly, for example, when u have a special hardware like DSP that does floating point arithmetics, and u wrote a driver to schedule instructions to be executed in that hardware unit. And u have to worry about many processes concurrently sending instructions to the same unit as well.Thanks for the reading.On Wed, Jul 23, 2014 at 11:15 AM, me storage <me.storage126@xxxxxxxxx> wrote:
HiI am reading LDD .In that i didn't understand one point .In Chapter 2(Building and Running Modules) they mentioned that
" Kernel code cannot do floating point arithmetic"
.My doubt is which code is used for floating point arithmetic that means at low level?Thank you
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
Regards,
Peter Teoh
Regards,
Peter Teoh
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
