Doubt Regarding Floating Point Arithmetic

Doubt Regarding Floating Point Arithmetic

[me storage]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140723/dcb6c2ad/attachment.html 

Doubt Regarding Floating Point Arithmetic

[Greg KH]

On Wed, Jul 23, 2014 at 08:45:54AM +0530, me storage 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?

I don't understand, what do you mean by this?  You should not do any
floating point math instructions within kernel code.  That's all that is
saying.

Hope you like the book,

greg k-h

Doubt Regarding Floating Point Arithmetic

[me storage]

Can you please explain me one scenario that lets suppose  take calculator
application in lower level it should interact with kernel code So here who
is take care of Floating point calculations?

Sorry if i am wrong
Thanks for replying me


On 23 July 2014 08:45, me storage <me.storage126@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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140724/1aa521dc/attachment.html 

Doubt Regarding Floating Point Arithmetic

[Greg KH]

On Thu, Jul 24, 2014 at 08:09:31AM +0530, me storage wrote:
> Can you please explain me one scenario that lets suppose? take calculator
> application in lower level it should interact with kernel code So here who is
> take care of Floating point calculations?

The userspace program does the floating point calculations.  The kernel
would not interact with a calculator application in a way that would
require the kernel to do anything here, it merely schedules the
userspace tasks to run.

Hope this helps,

greg k-h

Doubt Regarding Floating Point Arithmetic

[Peter Teoh]

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@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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140729/b3d5945b/attachment.html 

Doubt Regarding Floating Point Arithmetic

[Prasad Ram]

Thanks @Peter a very good explanation and it's very help full to me.


On 29 July 2014 19:49, Peter Teoh <htmldeveloper@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@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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140729/450d71ce/attachment.html 

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@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@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@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