Live data from Hacker News

Damn Vulnerable Linux - The most vulnerable and exploitable distro

damnvulnerablelinux.org

41–42 of 42 posts

Re: Damn Vulnerable Linux - The most vulnerable and exploitable distro

#41

Earlier quoted context omitted.

OK for learning about what has been solved; kind of hacking-101. BUt the exploits involved have all been fixed in the products in that distro. What to use for the advanced class?

i have it on my VM, can someone point me to where these guides are? KDE confuses me :). i will RTFM, I just need to find it first. thanks.

/dvl ;)

Re: Damn Vulnerable Linux - The most vulnerable and exploitable distro

#42
post #29

Earlier quoted context omitted.

It was usually used as an ultra- critical section. It would have been fine to simulate it as a scheduler-freeze for that process, preserving the meaning without getting hung up on the hardware implementation. But instead, Intel decided to try to support actually messing with the interrupt enable state, resulting in years of highly-inefficient "solutions" e.g. trapping and simulating. Sigh.

What's the (efficient) alternative?

I would say that not writing code that requires this. Only valid reason for wrapping something in CLI/STI is when you want to directly control some timing-critical hardware, which is something that simply does not belong into userspace. I would say that in most cases such code does not even belong to kernel, but into some interface controller of said hardware. Other cases are pretty well handled by normal APIs presented by kernel (mutexes, signal flags...).
Post reply on HN