What does the kernel do once put into memory? - linux-kernel

I'm a first year grad student trying to write an Operating System from scratch as a side project. I've read the Linux Programming Interface, Modern Operating Systems 4th edition, a bunch of articles on OSdev wiki's, and anything I can find on Google, but I'm having a tough time finding what I should be doing next after writing a simple bootloader, and a kernel that can take user input and display it back onto the screen.
I have a feeling that I need to create some drivers that interact with the file system and memory, but I'm not entirely sure. I'm trying to work my way up with just physical memory and one process running "kernel" for right now. I'll worry about virtual memory (pagging) and multi-processes later. If anyone can give me some kind of direction or better understanding of what happens when the kernel is finally put into memory, that would be great.
Thanks.

I would like to point a resource that will be of great help for you to understand this stuff in real details. One of the great and evolving resource that is being maintained on git.
https://github.com/0xAX/linux-insides/tree/master/Booting

Related

How do I access a specific register of my Intel chipset?

I want to read the "TSTR"-register (Thermal Sensor Thermometer Read Register) of my Intel Chipset.
I have found that the __readmsr function is what I need.
I have also setup a kernel driver since the function is only available in kernel mode.
But I have no clue how to access the register...
In the datasheet of the chipset it is stated on page 857 that the offset adress of the register is TBARB+03h.
How can I use this adress? Are there tutorials out there that could help me?
Thanks!
As far as I have figured out, trying to do the exact same thing, __readmsr is indeed the right command for accessing registers:
http://msdn.microsoft.com/en-us/library/y55zyfdx%28v=VS.100%29.aspx
however I am working on an i5, and Intel's documentation
http://www.intel.com/content/www/us/en/intelligent-systems/piketon/core-i7-800-i5-700-desktop-datasheet-vol-2.html
suggests that things like MC_RANK_VIRTUAL_TEMP entries are registers, so it ought to work, so you are on the right track probably.. the particular register is on page 272. So technically this is indeed the answer, __readmsr(1568) in my case.
However I am struggling to convince visual studio 2010 to build this in kernel mode, which it seems reluctant to do, I keep getting the Priviledged Instruction error.. When I get this out of the way and the whole program working I'll write a tutorial on the general process, but until then I only dare give a theoretical answer. If your compiler tends to listen to what you say, just add the /kernel compiler option, since you are only reading and not editing the registers it should be safe.
Edit:
There is also this article, the answer more or less suggests what I'm trying to do, though not much more than I have so far, but take a look anyway:
How to access CPU's heat sensors?
"This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) will be generated."
http://faydoc.tripod.com/cpu/rdmsr.htm

where to start linux kernel programming?

I have been programming in C for a couple of years in Linux. Now I want to work on linux kernel and contribute to kernel, if possible. I have been looking on the internet for the information about a starting point but I couldn't find one. So can any one please tell me where to begin?
I'm not a kernel person at all but I work with a lot of people who are very much into the kernel. They all recommend Linux Kernel Development by Robert Love as a good book on the subject. I've bought the book myself and plan to, in my copious free time, go through it.
The Kernel Mentors mailing list related resources at http://kernelnewbies.org/KernelMentors is also a good place to look at.
I would also recommend the site lxr.linux.no as a browsable source code repository.
It contains version 0.0.1 an up. With the help of this site, it is very easy to search for keywords in the kernel source on different versions.
Basically venturing into kernel programming starts off with a need to fiddle with services provided by the kernel....Me for example ..i had a need to fiddle with the IP packets generated and arriving on the kernel network stack....so started of writing LKMs,.,,kernel modules.And understand becomes easier if you have good understand of general Operating System Concepts.For example there was this book which i referred during my engineering undergraduation days...Operating System Concepts Author Silberschatz Galvin..even though i never cracked my head understanding user space and kernel space..that book did look into core concept at a more naive level...and it looked in from general OS point of view not specific to linux as such..now that i am more into kernel space programming that i realize how beautifully that book ventured into both user space and kernel space concepts....it just starts off with NEED to get into kernel side...from user space

GUI paradigm history

I know that Apple and Microsoft were inspired by Xerox PARC in building the GUI, but my question is: from the hardware point of view, which was the switch to GUI become available? I remember that I've read somewhere about OS running on 80KB at that time. Can you explain me(give some links) about what was necessary from the hardware point of view(also memory, speed) to make the GUI available?
I'm interested about the history of this paradigm switch.
TY.
ps: do you know how were those 80KB used?
here is an excellent article from arstechnica on the history of UI's. Wikipedia also has an article on it.
To answer your question about when the switch was available, i think that a GUI was always available, even in the days of analogue machines. You didnt have a windowing UI back then, but even back in the 60's, there were machines which displayed primitive user interfaces.
Machines that had user interfaces that ran on 64kb memory did so by using a lot of special modes in their hardware to display primitives without using alot of RAM. For example, back in those days, hardware sprites were crucial because that was the only way to get good graphics using low memory. Also dont forget about vector graphics and various other innovations which can create user interfaces without much RAM.

Guidance : I want to work at Process Information level

I couldn't find a suitable title for this. I'm going to express my query with examples.
Consider following softwares:
Process explorer from sysinternals (an advanced task manager)
Resource Manager : resmon.exe (lists each and every fine detail about resource usage about each process).
For me these softwares seems like miracles. I wonder how these are even made. C'mon how a user process can know such fine details about other processes? Who tells this software, what processes are running and what all resources are utilized? Which dlls are used? etc..
Does windows operating system give these software that information? I mean though (obviously the most lower level api) WIN32API. Are there some functions,which on calling return these values
abstractly say:
GetAllRunningProcesses()
GetMemoryUsedByProcess(Process* proc)
etc..
Other similar applications are
network Packet Capture software. How does it get information about all those packets? It clearly sits just infront of the NIC card. How is it possible?
Anti-virus: It scans memory for viruses. Intercepts other processes. Acts like a sandbox for the user application space. How? How??
If its WIN32API. I swear, I'm going to master it.
I don't want to create a multi-threaded application. I want to get information about other multithreaded applications.
I don't want to create a program which communicates using sockets. I want to learn how to learn how to capture all communication packets.
I actually want to work at the lower level. But I don't know, what should I learn. Please guide me in proper direction.
This is really a pretty open-ended question. For things like a list of running processes, look up "PSAPI" or "Toolhelp32". For memory information about a particular process, you can use VirtualQuery.
Capturing network packets is normally done by installing a device driver. If you look, you should be able to find a fair amount about how to write device drivers, though don't expect to create wonders overnight, and do expect to crash your machine a few times in the process (device drivers run in kernel mode, so it's easy for a mistake to crash the machine hard).
I can't say as much with any certainty about anti-virus, because I've never tried to write one. My immediate guess would be that their primary technique is API hooking. There's probably more to it than that, but offhand I've never spent enough time looking at them to know what.
Mark Russinovich's classic, Windows Internals, is the go-to book if you want to get deep in this kind of stuff. I notice that the just-released 5th edition includes Vista. Here's a sample chapter to peek at.
If you like Process Explorer, this is the guy who wrote that, and there are lots of examples using it in the book.
Plus, at 1232 hardcover pages, you can use it to press your clothes.

If I know Windows kernel, what can I do?

Currently I am in a stage that can learn Windows kernel programming, but I am wondering after that which types of jobs I can do?
For Linux kernel, seems till now only a bunch of driver works related jobs there.
There are quite a few jobs for people who can write Windows drivers, but most of them are not at traditional software companies -- rather, they're at companies that produce hardware that needs to work with Windows.
There is also the possibility of writing Native API code that bypasses Win32, and talks to the Windows NT kernel directly. For the most part, MS seems to officially frown on people doing this -- but when they do it well (e.g. the former ntinernals.com) MS buys them up and apparently puts them to work for MS (assuming somebody else doesn't first, of course).
The bottom line is that it is a useful skill set, but not particularly likely to be a life-changing event, or anything on that order. Also keep in mind that writing kernel code is writing kernel code -- doing it well goes way beyond the usual definition of "meticulous". A good kernel code is a guy who routinely has to sit back down and physically relax, because he's so anal retentive that the first time he stood up, the chair stuck to his butt!
You could write low level code that interacted with it (optimization purposes I assume).
Also drivers like the Linux world as well.

Resources