LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 11-07-2009, 04:25 AM   #1
MrCode
Member
 
Registered: Aug 2009
Location: Oregon, USA
Distribution: Arch
Posts: 864
Blog Entries: 31

Rep: Reputation: 148Reputation: 148
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.

Last edited by MrCode; 11-07-2009 at 04:26 AM.
 
Old 11-07-2009, 06:45 AM   #2
neonsignal
Senior Member
 
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Wheezy (Fluxbox WM)
Posts: 1,363
Blog Entries: 52

Rep: Reputation: 353Reputation: 353Reputation: 353Reputation: 353
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.
 
Old 11-07-2009, 12:37 PM   #3
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,229

Rep: Reputation: 173Reputation: 173
if you dont touch the harddisk or video you will be fine.
 
Old 11-07-2009, 12:57 PM   #4
rob.rice
Member
 
Registered: Apr 2004
Distribution: slack what ever
Posts: 784

Rep: Reputation: 104Reputation: 104
Quote:
Originally Posted by smeezekitty View Post
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
 
Old 11-07-2009, 01:57 PM   #5
MrCode
Member
 
Registered: Aug 2009
Location: Oregon, USA
Distribution: Arch
Posts: 864
Blog Entries: 31

Original Poster
Rep: Reputation: 148Reputation: 148
Quote:
Originally Posted by neonsignal View Post
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
 
Old 11-07-2009, 02:18 PM   #6
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,395
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
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.
 
Old 11-07-2009, 04:17 PM   #7
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by smeezekitty View Post
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.
 
Old 11-07-2009, 04:38 PM   #8
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,229

Rep: Reputation: 173Reputation: 173
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
 
Old 11-08-2009, 12:31 AM   #9
rob.rice
Member
 
Registered: Apr 2004
Distribution: slack what ever
Posts: 784

Rep: Reputation: 104Reputation: 104
Quote:
Originally Posted by Sergei Steshenko View Post
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
 
Old 11-08-2009, 12:37 AM   #10
rob.rice
Member
 
Registered: Apr 2004
Distribution: slack what ever
Posts: 784

Rep: Reputation: 104Reputation: 104
Quote:
Originally Posted by smeezekitty View Post
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

Last edited by rob.rice; 11-08-2009 at 01:00 AM.
 
Old 11-08-2009, 01:16 AM   #11
rob.rice
Member
 
Registered: Apr 2004
Distribution: slack what ever
Posts: 784

Rep: Reputation: 104Reputation: 104
Quote:
Originally Posted by theNbomr View Post
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
 
Old 11-08-2009, 03:57 AM   #12
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 453Reputation: 453Reputation: 453Reputation: 453Reputation: 453
Quote:
Originally Posted by rob.rice View Post
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.
 
Old 11-08-2009, 10:10 AM   #13
rob.rice
Member
 
Registered: Apr 2004
Distribution: slack what ever
Posts: 784

Rep: Reputation: 104Reputation: 104
Quote:
Originally Posted by Sergei Steshenko View Post
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

Last edited by rob.rice; 11-08-2009 at 10:28 AM.
 
Old 11-08-2009, 10:39 AM   #14
gerard4143
LQ Newbie
 
Registered: Jan 2008
Location: P.E.I. Canada
Posts: 18

Rep: Reputation: 1
Quote:
Originally Posted by MrCode View Post
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/
 
Old 11-08-2009, 10:48 AM   #15
tuxdev
Senior Member
 
Registered: Jul 2005
Distribution: Slackware
Posts: 2,012

Rep: Reputation: 111Reputation: 111
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ASM x32 vs ASM x64 Tegramon Programming 3 02-27-2008 02:26 PM
I/O in ASM Mercurius Programming 10 11-16-2006 07:02 PM
Not exactly a newbie, but still dangerous jhenager LinuxQuestions.org Member Intro 2 09-19-2005 02:51 PM
is this dangerous? Kendo1979 Linux - Security 3 05-17-2005 11:31 PM


All times are GMT -5. The time now is 09:04 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration