OSDev.org

Hi,

I rewrote our article on the Stack Smashing Protector provided by modern compilers. I added it to my OS yesterday and it was quite easy. I spent some time pondering how best to implement it, whether to use gcc's libssp or whether to denounce it and use my own, how the randomness should be delivered, how it should be initialized, how best to handle such issues (realizing the handler environment could be very hostile), and so on.

I figured I'd perhaps start making forum topics when I made useful changes to the wiki that the general community could be interested in. Is that something you'd be interested in?

I took the liberty of linking it from Meaty Skeleton (a new-ish tutorial that continues Bare Bones with a full project template). I didn't add it to Bare Bones as it might just be a little too irrelevant for absolute novices, but meaty skeleton does already assume global constructors and a minimal C library is in place.

I notice we have a Security page and Security category. It could be interesting to add some stuff there and reorder it and link it better to the rest of the wiki. I think security and robustness is one of the areas where osdev can seriously compete in. For instance, I build and run my entire OS (even kernel and libc) with -fsanitize=undefined (ubsan) to catch undefined behavior, and now -fstack-protector-all to catch buffer overflows. I might actually be the first reasonably-sized operating system to use both ubsan and stack protector in the entire system. Hardening is pretty fun and straightforward to add when the base operating system is clean code, as opposed to the third party code that breaks big-time when features like this are used.

Anyways,

Share and Enjoy!

Thanks for making the Wiki suck less sortie.

sortie wrote:I figured I'd perhaps start making forum topics when I made useful changes to the wiki that the general community could be interested in. Is that something you'd be interested in?

Yes, definitely.

I stumbled a bit over this sentence:

The detection is perfect is a impossible to fake the correct value

I guess it should be "The detection is perfect if it is impossible to fake the correct value"?

Also, those security topics are really interesting and helpful. Many things are rather new to me and it's really nice to have this kind of introductory articles. Good work!

Interesting to state that the canary should contain a null byte, and then not doing it in the example

Before I ignorantly go put back some different magic values, where did you get these from?

I didn't say it should have a nul byte. It makes some cases safe, but offers no protection in many others. Existing operating systems randomize every bit to get more entropy. Perhaps it is worth making one byte zero on 64 bit, but I doubt it.

Those constants doesn't matter except being unlikely to collide with bugs. They are cryptographic random nunbers from /dev/random. Either use them or your own constants, it is equally bad. You must generate a random number at kernel load time.