On Friday 03 January 2003 21:34, Nikhil Karkera wrote:
- LUG meet on 12 Jan. 2003 @ VJTI
On Wed, 25 Dec 2002 Nikhil Joshi wrote :
Come on who are we kidding? Do these ppl really care (and why should they?) if theres Linux or GNU/Linux or whatever and what is the right (read purists) way of The shopowners and home users already use free (read pirated) software. While the step is very welcome it would be really good >> to see the lowest denominator using Linux apart from scientists,sarkari babus,geeks
Wrong presumption that initial capital costs is the only cost. As usage increases, the costs for maintainence and security of data exceeds the initial capital cost by orders of magnitude (now u know why M$ is trying to change it's bussiness model). This is true for any user. The hassle of keeping out worms and preventing random crashes is what will turn the shop owner and home user to GNU/Linux.
rgds jtdsouza@softhome.net
On Fri, 3 Jan 2003, jtdsouza@softhome.net wrote:
Wrong presumption that initial capital costs is the only cost. As usage increases, the costs for maintainence and security of data exceeds the initial capital cost by orders of magnitude (now u know why M$ is trying to change it's bussiness model). This is true for any user. The hassle of keeping out worms and preventing random crashes is what will turn the shop owner and home user to GNU/Linux.
I guess you are assuming 3 things:
1. Worms/viruses are impossible under Linux
2. There are no free (beer) tools to combat worms/viruses under Windows
3. Random crashes are impossible in Linux
IMHO *all* these assumptions are misleading and incorrect.
Nikhil
On Sat, Jan 04, 2003 at 08:41:14PM +0530, Nikhil Joshi wrote:
initial capital cost by orders of magnitude (now u know why M$ is trying to change it's bussiness model). This is true for any user. The hassle of keeping out worms and preventing random crashes is what will turn the shop owner and home user to GNU/Linux.
I guess you are assuming 3 things:
- Worms/viruses are impossible under Linux
Why allow any program to access almost any part of the file system and then use antivirus software to guard against it? Let every access to a file be authenticated by the kernel according to the privileges of the program, thus making it very difficult to write a virus (except for the security holes that might be present in the kernel). But having some security holes (getting constantly fixed) is definitely better than having no security at all at the file system level.
Viruses/Worms could exploit the holes in the various protocol standards. But that problem is not specific to some operating system and hence also possible on GNU/Linux and irrelevant to the comparison between the security or stability in different OSs.
- Random crashes are impossible in Linux
IMHO *all* these assumptions are misleading and incorrect.
Almost nothing can be considered impossible; except something that is strictly forbidden due to some law of physics. Considering quantum mechanical effects, there is always a possiblity, though extremely small, that a bit in the memory contained in an important data structure of the kernel toggles and causes the system to freeze. So even if the software is perfect, the possibility of a system crash cannot be ruled out. So the question is not whether a crash occurs or not, but how often does it occur. It is observed that systems running GNU/Linux crash much less often than those running Windows OSs.
On Sun, 5 Jan 2003, Abhir Joshi wrote:
Why allow any program to access almost any part of the file system and then use antivirus software to guard against it? Let every access to a file be authenticated by the kernel according to the privileges of the program, thus making it very difficult to write a virus (except for the security holes that might be present in the kernel). But having some security holes (getting constantly fixed) is definitely better than having no security at all at the file system level.
AFAIK 386 gives you the reqd previlege levels
Kernel is the highest and User/App the lowest Now how is kernel to decide (if it had powers/facility) whether program is virus or not?
e.g. a simple shell script like
rm -rf * or cat < /dev/null > *.txt
maybe useful for someone or virus for others
not, but how often does it occur. It is observed that systems running GNU/Linux crash much less often than those running Windows OSs.
Agreed
On Tue, 7 Jan 2003, Nikhil Joshi wrote:
Now how is kernel to decide (if it had powers/facility) whether program is virus or not?
A virus is not a program on its own. It is a snippet of code that needs to be attached to an existing program to be effective. A virus consists of three parts - one which loads it into memory - this would be written somewhere near the start of the infected binary, the payload - the stuff that the virus does, and the contagion - the part that helps the virus spread.
A worm is a program in itself that propagates on its own. It does not require user intervention or the existence of other programs. It does not infect other programs.
A trojan is a program that claims to be something that it isn't. For example, the program format.com will destroy all data on your hard disk, but that's what it says it will do - hence it is not a trojan. a program that says it is a new year card, but in reality destroys all data on your hard disk - that is a trojan. Trojans need to be executed by the user.
It is impossible for an antivirus program to identify trojans. Well known trojans can be added to a database, but it is impossible to identify new ones based solely on what they do. Viruses are easy to detect because all viruses must have code that allows them to write themselves onto other binaries.
Worms are hard to identify, but there are telltale signs that can give a hint as to whether a piece of code is a worm or not.
Consider now, what would happen if a virus were to infect a worm.
Philip
On Tue, 7 Jan 2003, Philip S Tellis wrote:
A virus is not a program on its own. It is a snippet of code that needs to be attached to an existing program to be effective. A virus consists
<snip>
thx for the details. Now i've got the complete idea about viruses, worms and troajans
no wonder, things being so complicated the average age of a virus coder is around 16 yrs. I guess the brain is more "active" at that age ...
Consider now, what would happen if a virus were to infect a worm.
brrrr... double mayhem ...
On Tue, 7 Jan 2003 12:28:42 +0530 (IST) Nikhil Joshi wrote:
AFAIK 386 gives you the reqd previlege levels
If you're talking of the protected and unprotected modes of operation in ix86 CPUs, the last I heard, Linux kernel operates entirely in protected mode. AFAIK, none of the modern OSes use that feature - someone please check this and correct me if I'm wrong.
Now how is kernel to decide (if it had powers/facility) whether program is virus or not?
e.g. a simple shell script like
rm -rf * or cat < /dev/null > *.txt
^^ Ambiguous redirect - won't work
maybe useful for someone or virus for others
Kernel doesn't decide whether a script is a virus or not. All it checks is whether a process is authorized to do what it's trying to do. This itself goes a long way in keeping things secure. And it goes beyond simple deletion of files and formatting of disks.
On Tue, 7 Jan 2003 13:36:20 +0530 Tahir Hashmi wrote:
If you're talking of the protected and unprotected modes of
Uh, s/unprotected/real/
The reason why real mode is no longer used seems to be that it doesn't offer 32 bit addressing, while that's possible in protected mode.
On Tue, 7 Jan 2003, Tahir Hashmi wrote:
The reason why real mode is no longer used seems to be that it doesn't offer 32 bit addressing, while that's possible in protected mode.
386DX has 3 modes:
1. Real Mode (for older apps, specifically for 8086/88 support) 2. Virtual Real Mode or Virtual 86 mode(for having (some) protected mode feat. in real mode) 3. Protected Mode
Protected mode has following advantages:
1. Full 32 bit addressing 2. Better interrupt/fault handling (more no. of interrupt conditions possible) 3. Multiuser, Multitasking environment possible because of different previlege levels, task switiching thru call gates and interrupt gates, etc. 4. Data is secure at the hardware level. Non previleged task will not be able to access higher privelege data segment 5. Better memory management
and more ...
However it is interesting to note that whenever 386 is reset it will go into Real Mode by *default* (obviously for DOS and other real mode OSes which dont know about protected mode.)
It is the job of the OS to take 386 from Real to Protected Mode ( maybe by setting the CR0 bit, I'm trying to find this in the Kernel sources :) )
After protected mode has been initialized, kernel loads the IVT (Interrupt Vector Table ), the previlege levels of the data and code segments ( *maybe* this facility is used for user level file acess/execution previleges ) and continues loading the OS.
P.S. But how the Kernel is loaded in first place by the BIOS? Conjecture:
When reset, 386 points to a default location in PROM. ( the location is FFFF0H note: for 8086 compatibility 16 bit address)
The default location then has a subroutine which passes control to the BIOS (a sort of PROM right ?)
Now BIOS performs the IO checks. Afterwards it searches for address (Track 0) of a media (CDROM/HDD/FDD). Now it is expected that Track 0 contains valid OS. (Some Magic Number AFAIK)
Now where does the Bootloader come into picture? ( I dunno pls someone elucidate on this)
Ok lets assume that Bootloader "fools" BIOS in believing that it actually is an OS.
Now control is transferred to the bootloader which according to the option selected loads the kernel of the selected OS. The kernel now continues with its operation....
whew... Can someone pls tell whether this is the right sequence?
On Wed, 8 Jan 2003 09:07:32 +0530 (IST) Nikhil Joshi wrote:
Protected mode has following advantages:
- Full 32 bit addressing
- Better interrupt/fault handling (more no. of interrupt
conditions possible) 3. Multiuser, Multitasking environment possible because of different previlege levels, task switiching thru call gates and interrupt gates, etc. 4. Data is secure at the hardware level. Non previleged task will not be able to access higher privelege data segment 5. Better memory management
Ah! There are all the reasons why modern OSes use protected mode.
[snip]
After protected mode has been initialized, kernel loads the IVT (Interrupt Vector Table ), the previlege levels of the data and code segments ( *maybe* this facility is used for user level file acess/execution previleges ) and continues loading the OS.
Uh no, the privilege levels are only used to control access to memory locations, CPU resources and certain instructions (like HLT). It doesn't cover file access/execution privileges. Those are handled by the uid/gid (real, effective, file, or saved uids/gids) associated with the process and the access permissions on the files the process is trying to access, as reported by the filesystem. This is done by the kernel and a single user OS like Windows 98 may choose to entirely skip this issue.
When reset, 386 points to a default location in PROM. ( the location is FFFF0H note: for 8086 compatibility 16 bit address)
You probably meant FFF0H.
Now BIOS performs the IO checks. Afterwards it searches for address (Track 0) of a media (CDROM/HDD/FDD). Now it is expected that Track 0 contains valid OS. (Some Magic Number AFAIK)
Now where does the Bootloader come into picture? ( I dunno pls someone elucidate on this)
For a bios does it really matter what the bootloader really is? Its just looking for a piece of code to run which has the correct magic number. The bootloader may either be the code that bootstraps an OS or it may be a proxy bootloader that calls the bootloading code of an OS later.
On Wed, 8 Jan 2003, Tahir Hashmi wrote:
When reset, 386 points to a default location in PROM. ( the location is FFFF0H note: for 8086 compatibility 16 bit address)
You probably meant FFF0H.
I think 0xffff0 is correct. Remember, 8086 has a 20 bit address bus (1MB addressable memory). 8088 had to multiplex 4 bits since motherboards only had a 16 bit address bus.
On Wed, 8 Jan 2003, Nikhil Joshi wrote:
Now BIOS performs the IO checks. Afterwards it searches for address (Track 0) of a media (CDROM/HDD/FDD). Now it is expected that Track 0 contains valid OS. (Some Magic Number AFAIK)
Now where does the Bootloader come into picture? ( I dunno pls someone elucidate on this)
After BIOS finishes the POST, it checks the Master Boot Record on the boot devices in configured order (configurable in newer bioses). Control is passed to the first MBR with executable code on it.
In the case of DOS/Windows, this simply has a JMP instruction to go to the boot sector of the active partition (this is set in the partition table). In the case of boot loaders, it is a JMP instruction to the boot loader image - wherever on the hard disk it may be. If you configured your lilo to be on the boot sector of some partition, then you would have to make that partition active for control to be passed to it.
This is more or less how things happen. I'm sure someone else can give a more technical explanation.
If you're interested, get a hold of a disk editor and browse the raw disk.
Philip
Hi Nikhil,
Its almost the correct sequence.
It is the job of the OS to take 386 from Real to Protected Mode ( maybe by setting the CR0 bit, I'm trying to find this in the Kernel sources :)
CR0 is a register not a bit. It contains system control flags. Switching from Real Mode to Protected mode happens when the PE (Protection Enable) bit in this register is set. I think protected mode is enabled in /usr/src/linux-2.4/arch/i386/boot/setup.S section "code32_start" and paging is enabled in /usr/src/linux-2.4/arch/i386/kernel/head.S section "startup_32".
Now it is expected that Track 0 contains valid OS. (Some Magic Number AFAIK) Now where does the Bootloader come into picture? (
I >dunno pls someone elucidate on this)
BIOS looks for the content of sector 0 (bootsect.S in linux). If it has the magic number 'AA55' at offset 510 it is considered valid. In case a bootloader is used , part of the bootloader (lilo etc.) exists in the bootsector(Sector 0) and has the magic number AA55.
Verify this in :-
/usr/src/linux/arch/i386/boot/bootsect.S (note : this file is used when lilo not used)
regards, Sabu
--- Nikhil Joshi nikhil_joshi@gmx.net wrote:
386DX has 3 modes:
- Real Mode (for older apps, specifically for
8086/88 support) 2. Virtual Real Mode or Virtual 86 mode(for having (some) protected mode feat. in real mode) 3. Protected Mode
Protected mode has following advantages:
- Full 32 bit addressing
- Better interrupt/fault handling (more no. of
interrupt conditions possible) 3. Multiuser, Multitasking environment possible because of different previlege levels, task switiching thru call gates and interrupt gates, etc. 4. Data is secure at the hardware level. Non previleged task will not be able to access higher privelege data segment 5. Better memory management
and more ...
However it is interesting to note that whenever 386 is reset it will go into Real Mode by *default* (obviously for DOS and other real mode OSes which dont know about protected mode.)
It is the job of the OS to take 386 from Real to Protected Mode ( maybe by setting the CR0 bit, I'm trying to find this in the Kernel sources :) )
After protected mode has been initialized, kernel loads the IVT (Interrupt Vector Table ), the previlege levels of the data and code segments ( *maybe* this facility is used for user level file acess/execution previleges ) and continues loading the OS.
P.S. But how the Kernel is loaded in first place by the BIOS? Conjecture:
When reset, 386 points to a default location in PROM. ( the location is FFFF0H note: for 8086 compatibility 16 bit address)
The default location then has a subroutine which passes control to the BIOS (a sort of PROM right ?)
Now BIOS performs the IO checks. Afterwards it searches for address (Track 0) of a media (CDROM/HDD/FDD). Now it is expected that Track 0 contains valid OS. (Some Magic Number AFAIK)
Now where does the Bootloader come into picture? ( I dunno pls someone elucidate on this)
Ok lets assume that Bootloader "fools" BIOS in believing that it actually is an OS.
Now control is transferred to the bootloader which according to the option selected loads the kernel of the selected OS. The kernel now continues with its operation....
whew... Can someone pls tell whether this is the right sequence?
-- Nikhil Earth,19.12N 73.02E
-- _______________________________________________
__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
On Wed, 8 Jan 2003, Nikhil Joshi wrote:
When reset, 386 points to a default location in PROM. ( the location is FFFF0H note: for 8086 compatibility 16 bit address)
^^^^^^ oops.. actually it is 20 bit address 8086 can handle 20 bit address by converting 16 bit address to 20 bit internally. 8086 has 20 address pins ==> it can address 1 MB memory
-
Abhir Joshi -
jtdsouza＠softhome.net -
Nikhil Joshi -
Philip S Tellis -
Sabu Thaliyath -
Tahir Hashmi