LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   Is ASM dangerous? (https://www.linuxquestions.org/questions/programming-9/is-asm-dangerous-767495/)

MrCode 11-07-2009 04:25 AM

Is ASM dangerous?
 
I was thinking of learning assembly language (it would be neat to be able to make really tiny executables, and plus which it's really lightning fast), and I was wondering if I should be worried about anything really going wrong during the course of my education (everyone makes mistakes ;)). Is there any risk of hardware damage? I wouldn't imagine there is, but I just want to be sure. Also, can some really simple and/or stupid mistake cause the whole machine to reboot? I only wonder this because I know how low-level ASM is (right next to the hardware), and it can be used for just about anything (provided that you have the skills/knowledge/time; in fact I think some viruses are written using it to minimize filesize and memory footprint).

I apologize if this seems like a really stupid question. And before you LMGTFY me, I looked up both "is assembly dangerous" and "is assembly language dangerous", both of which found nothing useful.

neonsignal 11-07-2009 06:45 AM

No, you shouldn't be worried.

You can do pretty much anything in a language like C that you can in assembler, so assembler isn't any more "dangerous".

It is a bit easier to have a crash in assembler language programs. There are classes of errors that you wouldn't have in a higher level language, such as stack errors. But on a modern operating system, a failure in a user space program does not cause the system (or other programs) to crash.

Hardware damage caused by software is rare. It is usually obscure things like setting the wrong parameters on devices (such as video or hard disk or flash ram) that lead to failures. It is not an assembly language issue. You could have a randomly generated sequence of assembler instructions, and not have any problems.

smeezekitty 11-07-2009 12:37 PM

if you dont touch the harddisk or video you will be fine.

rob.rice 11-07-2009 12:57 PM

Quote:

Originally Posted by smeezekitty (Post 3748388)
if you dont touch the harddisk or video you will be fine.

you can use system calls (int 80 ) to write to the hard drive as long as you do not touch things like format track or sector or write directly to the hard drive but write to an open file
these system calls are also available in C as well

MrCode 11-07-2009 01:57 PM

Quote:

Originally Posted by neonsignal (Post 3748104)
No, you shouldn't be worried.

You can do pretty much anything in a language like C that you can in assembler, so assembler isn't any more "dangerous".

It is a bit easier to have a crash in assembler language programs. There are classes of errors that you wouldn't have in a higher level language, such as stack errors. But on a modern operating system, a failure in a user space program does not cause the system (or other programs) to crash.

Hardware damage caused by software is rare. It is usually obscure things like setting the wrong parameters on devices (such as video or hard disk or flash ram) that lead to failures. It is not an assembly language issue. You could have a randomly generated sequence of assembler instructions, and not have any problems.

Thanks for the reply. I guess this means I'm in the all-clear to search up a (hopefully) decent x86 ASM tutorial :)

theNbomr 11-07-2009 02:18 PM

Assembler language is no more dangerous than it is useful, in the context of userspace Linux applications. If the whole point of the exercise is for academic purposes, then go for it. If your intention is to write code that is for some OS-less target, then even better. If you think you will write something that anyone else will be interested in using in an existing major OS such as Linux, Windows, MACwhatever, etc, then you are probably wasting your time.
Perhaps you can contribute something useful to the OS that smeezekitty has been talking about.
One thing that is very useful about assembler language is understanding what is really going on when a compiler generates code. Understanding how memory is accessed and addressed is a very useful piece of knowledge, especially in the context of a language like C, where the concept of pointers comes directly from the use of pointers in assembler and the CPU instruction set.
--- rod.

Sergei Steshenko 11-07-2009 04:17 PM

Quote:

Originally Posted by smeezekitty (Post 3748388)
if you dont touch the harddisk or video you will be fine.

Strictly speaking, you are wrong. Due to a coding error control may pass to data area, and in that area there can be data whose values represent instruction codes of HW access and/or system calls.

So, the really safe way of coding in assembly is either on a scratch machine or in a virtual machine.

To be exact, even in C/C++ the above dangerous scenario is possible - with, say, wrongly calculated function pointers.

If you think more about it, this is what system program loader is doing intentionally - it first loads program from an executable file - this putting data into (meanwhile) data area, and then passes control to that (previously data, now code) area.

smeezekitty 11-07-2009 04:38 PM

one thing that is very important in ASM is alignment.
and you could crash your code very easy for example you can write over code by loading labels (do no attempt :) ):
Code:

mov ax,FF
xor dx,dx
LABEL:
push dx
mov word cs:LABEL,ax ;This would actually call the address of the value of the next instruction
;in other words a disaster
mov dx,cx


rob.rice 11-08-2009 12:31 AM

Quote:

Originally Posted by Sergei Steshenko (Post 3748548)
Strictly speaking, you are wrong. Due to a coding error control may pass to data area, and in that area there can be data whose values represent instruction codes of HW access and/or system calls.

So, the really safe way of coding in assembly is either on a scratch machine or in a virtual machine.

To be exact, even in C/C++ the above dangerous scenario is possible - with, say, wrongly calculated function pointers.

If you think more about it, this is what system program loader is doing intentionally - it first loads program from an executable file - this putting data into (meanwhile) data area, and then passes control to that (previously data, now code) area.

the descriptor tables that handle the virtual memory prevent the CPU
from fetching instructions from data segments there simply is no way to execute data that's what protected mode means

rob.rice 11-08-2009 12:37 AM

Quote:

Originally Posted by smeezekitty (Post 3748569)
one thing that is very important in ASM is alignment.
and you could crash your code very easy for example you can write over code by loading labels (do no attempt :) ):
Code:

mov ax,FF
xor dx,dx
LABEL:
push dx
mov word cs:LABEL,ax ;This would actually call the address of the value of the next instruction
;in other words a disaster
mov dx,cx


that code would throw a segmentation fault the code segment is NOT writable
even IF it could run it would over write the push instruction and part
of the mov word cs:LABEL,ax instruction
witch may or may not cause a problem depending on wither or not that code was executed again

rob.rice 11-08-2009 01:16 AM

Quote:

Originally Posted by theNbomr (Post 3748471)
Assembler language is no more dangerous than it is useful, in the context of userspace Linux applications. If the whole point of the exercise is for academic purposes, then go for it. If your intention is to write code that is for some OS-less target, then even better. If you think you will write something that anyone else will be interested in using in an existing major OS such as Linux, Windows, MACwhatever, etc, then you are probably wasting your time.
Perhaps you can contribute something useful to the OS that smeezekitty has been talking about.
One thing that is very useful about assembler language is understanding what is really going on when a compiler generates code. Understanding how memory is accessed and addressed is a very useful piece of knowledge, especially in the context of a language like C, where the concept of pointers comes directly from the use of pointers in assembler and the CPU instruction set.
--- rod.

have you ever looked at the linux kernel sources
assembly is still alive and well there are more programs with assembly
mixed in to them than you think anything with a deep need for speed
or anything that needs to be ultra small
some things are easy in assembly that are next to imposable in HLLs
the one and only downside to assembly is that it is not portable
learning assembly is the best thing to learn for a deep understanding
of how computers work right down to the logic gate level and on up to
algorithms

Sergei Steshenko 11-08-2009 03:57 AM

Quote:

Originally Posted by rob.rice (Post 3748834)
the descriptor tables that handle the virtual memory prevent the CPU
from fetching instructions from data segments there simply is no way to execute data that's what protected mode means

Even in 'gcc' "C", as regular user, I can execute code from data.

rob.rice 11-08-2009 10:10 AM

Quote:

Originally Posted by Sergei Steshenko (Post 3748919)
Even in 'gcc' "C", as regular user, I can execute code from data.

well you found a bug in gcc or the kernel
please report your bug to both the kernel and gcc maintainers
the data is being put in to the code segment or the local descriptor
tables are being written wrong

gerard4143 11-08-2009 10:39 AM

Quote:

Originally Posted by MrCode (Post 3748454)
Thanks for the reply. I guess this means I'm in the all-clear to search up a (hopefully) decent x86 ASM tutorial :)

Try dr paul carter's tut or programming from the ground up

Links:

http://www.drpaulcarter.com/

http://programminggroundup.blogspot.com/

tuxdev 11-08-2009 10:48 AM

Quote:

well you found a bug in gcc or the kernel
please report your bug to both the kernel and gcc maintainers
the data is being put in to the code segment or the local descriptor
tables are being written wrong
I believe he's referring to thunks, JIT and such.. Without the NX bit set on a page, you can execute whatever you like on the stack or heap - the processor doesn't really care inherently, it's just memory.


All times are GMT -5. The time now is 03:10 PM.