SunOS--Minix

Download Report

Transcript SunOS--Minix

SunOS--Minix
A Operating System used in teaching
Laboratories.
Presented By:Oliver Dsouza
Sankara Narayanan
What we will be covering!!!
•
•
•
•
Overview of the Minix Operating System
The Architecture of Minix
The Booting Process
Implementation of System Calls – How it
works
• An Insight into the security
• Conclusion
Bird’s Eye View of Minix
• Minix – Mini Unix (Minix) basically, a UNIX compatible operating system.
• Minix is small in size, with microkernel-based
design.
• Minix has been kept (relatively) small and simple.
• Minix is small, it is nevertheless a preemptive,
multitasking operating system.
• Internally, Minix is highly modular, consisting of
several system processes organized into a number
of independent programs.
Continuation…..
• Full multiprogramming (multiple programs
can run at once).
• Most of the code is written is C language
and the source code is freely available.
• Networking with TCP/IP
Internal Architecture
• The figure represents the internal
architecture of Minix.
Different Layers
4
3
2
1
User Processes
init, login, passwd, sh, ls, cp, cc,………..
Server Processes
File System (FS), Memory Manager (MM)
Kernel I/O Tasks
Floppy, tty, clock, system, …………
Kernel Process Management
Interrupt handlers
Architecture Continuation…..
• There are 4 layers in the Architecture
• Layers 1 to 3 comprise the Minix operating
system, with applications running in Layer 4.
• The operating system code is linked into three
totally separate programs|mm (the memory
manager), fs (the file system), and kernel (layers 1
and 2).
• Processes in layer 2 and interrupt handlers in layer
1 can communicate by message passing or shared
memory; all other communication is through
message passing.
Detailed Analysis of the Different
Layers.
• Layer 1(Kernel Process Management) implements
communicating sequential processes, thus
allowing the remainder of Minix to be
implemented as a set of communicating sequential
processes. Layer 1 is a group of interrupt handlers,
with its own stack space within kernel.
• Layer 2 (Kernel I/O Tasks) contains device driver
processes. System provides an interface between
kernel and the layer 3 processes.
• Layer 3 (Server Processes) contains the memory
manager and the file system.
Continuation…….
• Layer 4 (User Processes) contains a Unixlike process hierarchy rooted at process 1.
Every system call" made by a user process
in layer 4 is converted into a message to one
or other of these processes.
Booting Process
• The booting process is an important one in any
operating system. Here in Minix, the
bootstrapping occurs in the following way,
• A small SunOS program (minix) is responsible for
processing a configuration file, allocating memory
for SunOS Minix, loading and relocating the
SunOS Minix \image" and then jumping to the
startup code within the SunOS Minix kernel
proper.
Continuation….
• minix allocates the requested amount of
memory in the data segment of the SunOS
process, and loads the image, consisting of
kernel, mm, fs and init, at the beginning of
the area allocated.
• Booting has 2 phases
– The minix Phase
– The kernel Phase
Booting Phases.
• Booting – the minix phase
The main functions of the minix program are,
• Read the configuration file, open various devices on well –
known (to minix and kernel) SunOS descriptors.
• A child process is created that will run the Solaris minix.
• The child creates a temporary file that is the same size as minix
physical memory and maps to child’s address space at the
virtual address assigned to the beginning of kernel’s text
segment.
• A bootinfo structure at the start of kernel data segment is filled
in.
• Execution then switches to kernel entry point.
Continuation……
• Booting – the kernel phase
– The kernel entry point is in a small piece of
assembler code that sets the stack pointer to
layer 1 stack, and then calls the C function
“main”(main.c).
– Then the standard pieces of code that are added
to the boot sequence involve the setting up the
handling of SunOS signals, and setting up of
memory protection.
The Important Directory
Structure
•
•
•
•
•
•
commands
fs – file system
kernel – kernel codes
solaris
tools
mm – memory manager
Flow OF control
• The flow of control in minix from the user
level the kernel level is handled by system
calls.
• Minix has a set of system calls which are
located in the table.c file.
• The fs has its own table and so the memory
but the number of system calls is fixed
System Call
• System call in minix is similar to a system,
call in any system.
• A user-level process cannot directly access a
disk. Instead it asks the kernel to obtain data
from a file for it (the read system call).
• A user-level process cannot create another
process. Instead, it asks the kernel to create
one for it.
System call
• System calls are typically made via library
routines. Library routines are normal
procedure calls. They perform the setup for
the system call.
• In minix the system call functions in a
similar fashion.
System call
• To implement a system call in minix one
needs to do the following steps.
• Look for a free slot in the table.c file
• Follow the standard convention
no_sys,
/* 0 = unused */
do_exit,
/* 1 = exit */
do_fork,
/* 2 = fork */
System Call
• The system call would be named in the following
manner
do_sandbox or do_encrypt
• Once the system call method has been written its
declaration should be mentioned in the function
declaration header file in the file system it is
“proto.h”
• _PROTOTYPE ( return type do_XXXX,
(arguments if any)
);
System Call
• The library should also be informed about the
system call that would be called by the user.
• The library file for the system call is written in the
lib/other directory. The file naming convention is
followed here it starts with an underscore
Eg: - _sandbox.c
System Call
• Once the code for the system call is written in the
"lib/other" directory a system file needs to be
created. The system file is present in the
"lib/sunsyscall" directory.
• A standard naming convention is followed here to.
The filename extension is ".s".
.global systemcallname
systemcallname:
ba
_systemcallname
nop
System Call
• A system call will contain a user created command
file which when compiled creates a binary
executable command. the command is created in
the “commands/simple” directory”. The file once
compiled creates an executable binary in the
“commands/simple/bin” directory.
• You will need to do a sunread to get the bin from
the solaris system to the minix system
System Call
• All the headers used in the system calls are kept in
the "include" directory. The "type.h " header file is
a very important and most useful header file.
• To pass a message a variable of a specific data
type is defined, and the variable is added to the
message structure
System Call
• Typedef struct { datatype mnYY; } mess_n;
n => message number of the message
YY => variable name
• The size of the structure defined in the message is
also an important factor as if the size of the
message is increased then the system crashes
System Call
• Typedef struct { char *m1sb; } mess_1;
#define m1_sb m_u.m_m1.m1sb;
• To add data in the message variable the
following need to be done
Message m;
m.m1_sb = data