Fault on reboot (solved)

[salil_bhagurkar]

Hi... This is a basic problem. But I can't seem to find the solution for it. When using QEMU, my first boot is successful, but when i reboot without restarting QEMU (using outb(0xfe, 0x64)), i get a fault. This is probably due to the stale data in the RAM which creates undesired conditions. But I can't really find out what I need to do. Is there any section clearing(bss) I need to do on boot?

[Dex]

Maybe you could try the new method or place a delay

static inline void mach_reboot(void)
{
int i;
- for (i = 0; i < 100; i++) {
- kb_wait();
- udelay(50);
- outb(0x60, 0x64); /* write Controller Command Byte */
- udelay(50);
- kb_wait();
- udelay(50);
- outb(0x14, 0x60); /* set "System flag" */
- udelay(50);
- kb_wait();
- udelay(50);
- outb(0xfe, 0x64); /* pulse reset low */
- udelay(50);
- }
+ u8 cmd ;
+
+
+ /* old method, works on most machines */
+ for (i = 0; i < 100; i++) {
+ kb_wait();
+ udelay(50);
+ outb(0xfe, 0x64); /* pulse reset low */
+ udelay(50);
+ }
+
+ /* new method, sets the "System flag" which when set,
+ indicates successful completion of the keyboard controller
+ self-test (Basic Assurance Test, BAT). This is needed
+ for some machines with no keyboard plugged in.
+ This read-modify-write sequence sets only the system flag. */
+ for (i = 0; i < 100; i++) {
+ outb(0x20, 0x64); /* read Controller Command Byte */
+ udelay(50);
+ kb_wait();
+ udelay(50);
+ cmd = inb(0x60);
+ udelay(50);
+ kb_wait();
+ udelay(50);
+ outb(0x60, 0x64); /* write Controller Command Byte */
+ udelay(50);
+ kb_wait();
+ udelay(50);
+ outb(cmd | 0x04, 0x60); /* set "System flag" */
+ udelay(50);
+ kb_wait();
+ udelay(50);
+ outb(0xfe, 0x64); /* pulse reset low */
+ udelay(50);
+ }
}

I go to realmode and use this method without any problems in emulators

Code: Select all

     DB 0EAh					      ; Machine language to jump to
						      ;    address FFFF:0000 (reboot)
       DW 0000h
       DW 0FFFFh				      ; No return required
						      ;    we're rebooting!

[Stevo14]

A quick way to test if it is indeed a problem with uninitialized memory would be to write a function that actually zeros all of the memory from the end of your kernel to the end of memory. Run the function at the start of the kernel. If the problem disappears, then it should suffice to zero all dynamic memory allocations (eg. kmalloc();).

Obviously, remove the function after testing and only test with small amounts of memory (unless you are willing to wait ).

[salil_bhagurkar]

A quick way to test if it is indeed a problem with uninitialized memory would be to write a function that actually zeros all of the memory from the end of your kernel to the end of memory. Run the function at the start of the kernel. If the problem disappears, then it should suffice to zero all dynamic memory allocations (eg. kmalloc();).

Obviously, remove the function after testing and only test with small amounts of memory (unless you are willing to wait ).

Oh! Why didn't I think of that?

@Dex: Reboot works fine. The fault comes on next boot...

[salil_bhagurkar]

@Stevo14: I did that, and it worked. It was due to uninitialized data. Now i just need to scan for which structure or buffer has got uninitialized data... Thanks!

[Stevo14]

No problem. I'm glad it helped!

It find it easiest to automatically zero all kmalloc()'d areas inside the kmalloc() function. You may also want to write a wrapper function with a different name that does the zeroing (somewhat like malloc() and calloc() ).

[salil_bhagurkar]

Zeroing allocations is not required mostly. Structures are mostly specifically initialized (not necessarily zero). Strings have a null terminating character, which i try to maintain instead of zeroing the string completely. This results in overall performance boost. Especially when you might have applications like editors which might allocate thousands of line buffers and load them with data which naturally doesn't require zeroing...

[frank]

I would zero the memory just in case, that way everything knows that it has a nice clean slab of memory to work with.

As for memory given to user processes, its a security issue if you don't zero the memory before giving it to the process. What if super secret password program was running and freed a page of super secret memory expecting the kernel to zero it and then the memory was given to another process, that would be a major security violation.

[Firestryke31]

An application expecting memory to be zeroed is just asking for bugs. If super-secret password program wanted to be assured that super-secret page won't be read after being freed, it should zero it out itself. Any other application will be full of bugs the moment you even try to use it on another OS.

If an application expects a certain location in memory to be zeroed before use, it should do it itself to keep the applications that don't need it from suffering the speed penalty of zeroing every memory allocation before use, physical, virtual, or whatever.

[Candy]

An application expecting memory to be zeroed is just asking for bugs. If super-secret password program wanted to be assured that super-secret page won't be read after being freed, it should zero it out itself. Any other application will be full of bugs the moment you even try to use it on another OS.

If an application expects a certain location in memory to be zeroed before use, it should do it itself to keep the applications that don't need it from suffering the speed penalty of zeroing every memory allocation before use, physical, virtual, or whatever.

Your OS can confiscate memory for other reasons - swapping, alignment, memory failures, DMA buffers, hibernation, hot swap of memory banks, stuff like that. Your application therefore does not have the guarantee that what is memory now will be the same later on, so the OS will need to guarantee that pages allocated to the app with any data of the app on it (even one bit) gets wiped completely clean before any other app can use it. In other words, the OS must guarantee that data from app X does not leak from that app if X is supposed to be secure at any point. The Orange Book had this as a guideline for C2 IIRC.

[frank]

If an application expects a certain location in memory to be zeroed before use, it should do it itself to keep the applications that don't need it from suffering the speed penalty of zeroing every memory allocation before use, physical, virtual, or whatever.

If done correctly then there should be no speed penalty at all to insure that memory is zeroed before use. When an application frees a page place it on a dirty pages list. Then in idle time you can clear the pages and place them on a zeroed list. Of course you need a way to force a page to be cleaned if you run out of pages on the zeroed list.

An application expecting memory to be zeroed is just asking for bugs. If super-secret password program wanted to be assured that super-secret page won't be read after being freed, it should zero it out itself. Any other application will be full of bugs the moment you even try to use it on another OS.

Can you tell me one OS that doesn't zero memory before it is handed out? AFAIK all the major ones do it. And as Candy said the application can't always be sure that it has complete control over all pages allocated to it. The OS can pretty much do anything it wants to the pages as long as it maintains the illusion of complete control to the program.

[Firestryke31]

I'll admit I completely forgot about an OS forcibly using a page for something else, which an application would have no control over or knowledge of. However, I still think it's a bad idea to assume an OS will clear memory for you. Just as it may be a bad idea to assume it won't. Simply put, don't assume anything. Just my personal view, as I've been burned by that several times.

[Candy]

I'll admit I completely forgot about an OS forcibly using a page for something else, which an application would have no control over or knowledge of. However, I still think it's a bad idea to assume an OS will clear memory for you. Just as it may be a bad idea to assume it won't. Simply put, don't assume anything. Just my personal view, as I've been burned by that several times.

You can't even assume it'll clear memory for you. You *will* be wrong, as 90% of allocations aren't handled by your OS. Most are stack pointer movements, which is implicitly not cleared by C and C++ (and assembly - but then you consciously move the stack pointer so it's more obvious) as it's quicker. Even alloca() doesn't clear your stack, and that's not always called even in Windows.

Not to mention that the malloc/free or new/delete contracts also do not clear memory so nobody will expect you to.

If you really want cleared memory, adjust the compiler to do it. Saves piles of work and works reliably. Also, you won't be using C or C++ anymore.

[frank]

I was never actually talking about malloc and its cousins but more about the direct page level allocations that malloc uses to build the heap. Am I incorrect in thinking that those pages are cleared by the OS before handling them to malloc. If you get into a discussion about malloc then its the C Library and not the OS itself and since that memory gets recycled over and over again then you have to make sure to clear it before using it.