31–40 of 42 posts
Earlier quoted context omitted.
Seems a decent educational tool too.. run in a virtual box and let your students go all out overflowing buffers and seeing the concepts in action. It comes with easy-to-follow guides.
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?
Earlier quoted context omitted.
Why sit around replacing packages by hand when you're not really learning anything? The best fix for a system like this is to nuke it from orbit and reinstall. I mean, odds are, you'll miss something, and then spent hours fooling around after getting hacked, when you could have just spent your time concentrating on what's important: saving relevant data and configuration, reinstalling, and securing the updated config…
This is a course in security and thats why the comment is completely beside the point.
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?
A finer-grained approach is to have a flag bit that prevents preemption, perhaps even just preemption by threads of the same process. This is weaker than CLI because it doesn't prevent I/O callbacks etc from preempting; ideally those would be suspended as well for the process.
This assume a non-priviledge flag word i.e. user-mode code owns the "process flags", not the kernel.
My favorite solution is a "process signal register" in hardware. Its a wide register full of test-and-set bits, shared by threads of a process. They can be used to implement critical section, semaphore, event, even waiting on a timer. All without a trip thru the kernel - essentially zero-latency kernel primitives.
Earlier quoted context omitted.
What's the (efficient) alternative?
A big-hammer approach is to set thread affinity for your process to one hyperthread/processor. But that loses the opportunity for lovely parallelism. A finer-grained approach is to have a flag bit that prevents preemption, perhaps even just preemption by threads of the same process. This is weaker than CLI because it doesn't prevent I/O callbacks etc from preempting; ideally those would be suspended as well for the p…
And "process signal registers", while sounding attractive, aren't really a feasible alternative, given that the number of processes running even on uniprocessors are overwhelming, at least. Plus, if they're beyond CPU control, privilege issues arise again.
In short, yes, there are many alternatives, but the current model works, and not just for x86. And you know what engineers say..
Earlier quoted context omitted.
Seems a decent educational tool too.. run in a virtual box and let your students go all out overflowing buffers and seeing the concepts in action. It comes with easy-to-follow guides.
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?
Earlier quoted context omitted.
This is a course in security and thats why the comment is completely beside the point.
The important point, which I did miss, is that it's not just a "security course", it's a course about how to break into things, so you need vulnerable programs. If you're not specializing in security stuff, the best course of action, is, however, to just keep your stuff up to date via apt or some similar mechanism.
That actually sounds like a fun concept.
Securing this beast should serve as a nice training course for any sysadmin; bonus points if you start handing out shell accounts to anonymous people in certain neighborhoods of EFNet.
Just update packages to the latest, patched version. What so difficult about it?
I have spent hundreds if not thousands of hours upgrading random packages in Linux for various reasons. Afterwards, I didn't feel any wiser in security or anything except how to build stuff (well, maybe a bit of systems stuff...).
If upgrading is main task here, what do you really learn? If upgrading isn't the main task here, what is?