Doubt Regarding Floating Point Arithmetic

[Peter Teoh]

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 at gmail.com>
wrote:

> Thanks @Peter a very good explanation and it's very help full to me.
>
>
> On 29 July 2014 19:49, Peter Teoh <htmldeveloper at gmail.com> 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):
>>
>> http://en.wikipedia.org/wiki/SSE2
>> http://www.godevtool.com/TestbugHelp/XMMintins.htm
>> http://x86.renejeschke.de/html/file_module_x86_id_117.html
>>
>> 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 at gmail.com>
>> wrote:
>>
>>> Hi
>>> I 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 at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>>
>>
>>
>> --
>> Regards,
>> Peter Teoh
>>
>
>


-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140730/9ddc5c5f/attachment.html