I still remember when Firefox was Firebird (no, not the database) or whatever. The barebones web-light version of Mozilla suite. And their goal wasn't implement everything under the sun AND the kitchen sink in a browser, but steer away from it. I guess they grew up. I blame Google's money:D
I understand your point. We can all learn something from it, and it is indeed a valuable lesson in software development and product management, but that a child could have tought - if you don't dominate your fears and fight your monsters, sooner or later they will make you suffer.
No, it has hone middle-age hipster. Its a nice niche.
People buying high-end luxury sedans are less concerned about an extra 10-20 grand
Tesla S is hardly a high-end sedan, let alone a luxury one. And 200Km/h top speed combined with a 500Km range is, frankly, unappealing as a sedan. Its more of a city vehicle/short commute vehicle for the family. Check Audi A8, Volvo S80 or BMW 7 for *actual* luxury sedans. And these are somewhat affordable cars.
I live in one of the few countries that actually has a fueling grid for electric cars. It was the country chosen for Leaf's initial presentation. Lexus hybrids are quite common (high-end cars), as well as Honda Civic and other hybrids. Way more than Leaf. Electric scooters are also quite popular. And Segways in tourist areas. All of these would benefit from better battery tech. And if you think manufacturers want combustion engines. you're dead wrong. Electric cars have bigger margins and require periodic maintenance (battery maintenance), so there is a better chance of frequent income from a customer. Some high-end manufacturers have put a deadline in combustion engines a long time ago (eg. mercedes), and I forsee that in a 10 year timeframe, upto 50% of new cars will be electric or hybrid. So, its the difference between profit from a specific subset of vehicles, or profit from your own competition.
On the other hand, new tech in batteries is what will distinguish car manufacturers in the foreseeable future. Limiting the tech to his own niche production is a shot in the foot - sooner or later, someone will beat him. On the other hand, producing OEM components for its own line of cars as well as competitors would yield way bigger profits. See it as Samsung producing Apple's ARM cores. Samsung probably makes more money from CPUs and displays for 3rd party than from their own best-seller phones.
The thing about OpenSSL et al is that everyone who used it had exactly the same opportunity to review the code and make a decision about its use.
Yeah, including the OpenBSD team. (As the video mentions) And they bitched about it for years, regardless of their "proactive" approach. It took a huge vulnerability to make them take the step. Meanwhile, work is being done, yet Linux Foundation is trying to cash in on it and is probably still deciding the logo sizes for the new joint task-force or whatever to "save" OpenSSL.
eriously though, stop bashing the OpenSSL project, it is just as much the product of its community as its developers.
Well, its not. If there was some vague quality control, it wouldn't be the mess it is today. If it was developed by competent developers, it wouldn't be the mess it is today. And not everyone excels at crypto stuff. The community did their job - submitted patches and bug reports that went unfixed for years. Everyone knew it was a clusterfuck, no one took the extra step - but the community did what it was supposed to do. The OpenSSL team didn't delivered, though.
I've actually been in the military (more than a decade ago), and had contact with "top of the line" encryption systems. At the time, I was already using for myself OpenBSD and actual strong encryption. "Military Grade" is like the "Bio" sticker in food - a way of charging more for worthless shit.
I could see being an OpenSSL guy would be a huge one
I don't. OpenSSL has always been the disaster waiting to happen. The codebase is messy, no one really understands it, and there is no real criteria when adding stuff. I have no experience with it and I knew it was a big pile of stinking poo (its not like this hasn't been a probem before), so I hardly doubt that saying you're an OpenSSL dev would give anyone any credit.
Usually have a Novell certification in some drawer and will defend Novell to this day.
I'm not Novell certified (nor a security expert), but Novell DID have his awesomeness - at some level, unmatched today.
I do agree with most of what you said, but the problem is two-fold: actual security experts are either matematicians or hardcore developers, and more often than not, cannot communicate with regular people. And no, this is not a feature. Transmiting a concrete idea to a peer without noise is the ultimate developer experience - you need to develop a subset of the language that allows you to carry your own message without being subject to change on the endpoint; And because most of the guys entwined with computers are too tied in the digital all-or-nothing approach, they think its not their fault they cannot operate on an analog world. Which, by itself, is hilarious, because "digital computers" are actually a subset of the computing field.
In short, the problem is the nerd type. Get rid of them, have them behave and communicate like regular people, and all these bs types are out of a job. And for Pete's sake, its not like most of what is CS is hard.
From the presentation, its not. Its POSIX-compatible. I'm not sure if Windows provide an adequate entropy source they mention, but I'd assume so. They explicitly removed dead architectures (hence the VC++ reference).
With systemd it is just one convenient systemctl stop apache
...Except most of the time you DON'T want to stop everything that apache depends on. Eg. MySQL and Memcache comes to mind. If you DO need this, you can easily do it by an alias (the most easy solution) to something like apachectl stop && service php5-fpm stop. Again, this isn't even a problem.
What you usually want is to start all dependencies of a given program (eg. fpm when you start apache). This is a solved problem.
Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.
I don't get where you think *text* is a lossy format, but ok. Lets add complexity and failure points to something that should be easy.
You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?
Apples and oranges. Text is never a lossy format.
So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache
Well, you do *mention* apache, so the most common approach is to just kill the master process, and all the child processes die. You know, unix systems. In case of apache, you even have an utility for it - apachectl. Other approaches would be 'service apache22 stop', kill -TERM `cat/path_to_apache_pidfile`, and of course, kill -9 $(ps -ef |grep apache2 |grep -v grep| awk '{print $2}') or any other variant (eg. in freebsd you could do a ps ax | grep Ss | grep httpd to determine the master apache process and its pid to kill). On many linux systems, you also have killall and/or pkill, that will achieve the same effect by process name, and easily usable with apache, nginx and the cgi wrappers you may have running.
I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.
I did. FreeBSD 9.2. Most of the sleeps are for hardware settling. Replacing a shellscript sleep() with a binary version of it is not a solution anyway. Both rc.d and init.d approaches allows you to prioritize script startup, to achieve that same effect. In FreeBSD, the rcorder (http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8) allows you to quickly visualize service dependencies. In OpenBSD I specify in rc.local the order I want my stuff to start. I'm assuming other systems provide vaguely the same funcionality, its not rocket science. (Again, a solved problem).
Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.
I'm not against uniformization. What I don't see is the need for yet another tool that fragments even more the available options. And uniformization is pretty common in other operating systems - check eg. FreeBSD and OpenBSD: they are quite different in terms of setup, but not that different. Its not like it wasn't possible before. That approach exists for decades.
Check out http://www.freedesktop.org/sof... [freedesktop.org] , especially all the options starting with "Private" there.
It sounds like a meta-version of linux containers. Why would I want that implicit on a startup script? Its about doing one task and doing it good.
Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.
You did not suggest. You touted it as solution to problems that, frankly, do not exist. It may have features that are very helpful, it may solve a lot of problems, but you mentioned none. Not one valid existing problem.
By then all the hotheads that are running for the BSDs now will be back
Probably not. BSD is not usually appealing to the linux crowd, at least server-wise (the guys that would actually take advantage of some of the features you mentioned). And the ones I know did t
BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix
These are the golden times of Unix.
You really want to go back to that? Seriously?
You sound like its a bad thing. Its not.
the journal instead of a set of randomly formatted text-dumps all over/var/log,
I'll take the text-dumps any day, thanks. And since they're usually created via *syslog*, they may not even be stored locally. And they are easy to manipulate with the available shell tools (grep; cat; awk; etc). If you want a database-driven syslog, there are plenty around.
a convenient way to kill apache with all the crap that it started,
It seems you're getting closer to the real problem. Apparently you don't know how to operate a vaguely modern unix system.
a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
Usually the sleeps are for hardware settling, not for script startup. Eg. when you plug a USB device that may take a couple of seconds to be available after powering on. This will be needed *regardless* of what script is running the show. And dependency management on start scripts is a solved problem. Have a look at FreeBSD/NetBSD rc.d system, or Solaris SMF.
a more secure system by being able to isolate daemons from one another and the rest of the system.
So, its a startup daemon AND a kernel, huh?
a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
Convenient for who? For you, because you cannot be bothered into using the existing tools? You may have some unusual requirements, it doesn't mean everyone else has the same needs. And while I'd applause a sort-of-standard way of bootstrapping Linux distros, adding complexity seems to be a pretty stupid approach.
70-90% of all soy, corn and wheat grown in the US is fed to livestock...and the return on that (in calories or protein) is a fraction of what goes into it..
Of course. But the return on stuff our digestive system can actually process without difficulty is way bigger, or else we'd be eating dirt. After all, plants get their nutrients from the ground, right?
but that's not how 99% of the livestock in the US is raise
I'm assuming you have a huge experience in cattle farming in the US, to come up with such a bold number. Also, the rest of the world isn't the US.
And imagine if it were: the majority of land is already used for this kind of agriculture.
You're assuming that if we just grew soy instead, we'd be better off. The fact is that what most animals do is pruning (they eat the greener leafs of selected species, but leave older leafs intact as well as the roots). Most farming techniques don't use pruning, so the stress in the soils is way bigger. As an example, look at corn plantations. Also, rations made directly by smashing corn use the whole plant (except the roots) while the plant is still green, while human feeding based on it usually only recycles the seed part of it (so half of the plant is waste or used as low-nutrient food for cattle).
Again, just look at that graph.
Well, I cannot speak for graphics or metrics made by others, specially when they aren't really peer-reviewed and related to a specific population. Of course the amount of water I was mentioning was by direct consumption - there is a whole lot of water used for cleaning, irrigation and whatnot. That varies a lot according to the location of the cattle, the heat, the kind of feeding, among other factors. If you're worried about water usage, have a look at aluminum processing or lorries.
And that's not how much water goes into making milk. It's definitely not 1:1
Well, you can show me any blog articles you want.I can only speak by my experience, by working on a cow farm during the summers in my youth.
Imagine the ratio of surface area to protein/vital nutrient intake once those animals are converted into plants. Do you know how much grass a cow eats and how efficient it is converting it and water into milk and tasty meat? Do you think you can do the same by just eating grass? Go, help yourself. An adult cow drinks 20-40l of water and produces around 20l of milk, while producing tasty meat. Do the math.
I have an indian friend that tasted meat the first time when he was like 21 or 22. What he described, besides the obvious bacon bliss, is a symptom of protein privation during is whole life - a "meat rush". He will now bite a steak or a burger everytime he can.
Well, it doesn't take more water for the same protein value. One of the reasons we eat livestock instead of grass is because we need more complex stuctures (eg. proteins) to live. Animal shit may be a problem, but human shit is way worse, as it can't even be easily recycled as a fertilizant. I'm not in favour of animal cruelty (so some heavy processed meat process makes me wonder where we're going, but on the other hand, recycling everything from a corpse is more thant what I do with my vegetables), but your meat choices have no impact in life.
1) You're a short-sighted moron, but that we already knew;
2) If crowdfunding of these kind of projects work, we'll see many more in the future - even if it fails its goal;
3) Learning engineering tricks form a viable, proven piece of tech that went where no man has been before is priceless. You can simulate whatever you want, but in the end I'll take a proven piece of gear to a simulation any day;
4) Your opinion's worth is way inflated. Even for free, its still overpriced.
Ah, ok. SO like Segmexec in PaX where the address space is dual-mapped and split 50/50, or W^X where part of the memory is NX.
Yeah, sort of exactly like that. But it has existed since "forever" in x86-32 and you can specify arbitrary segments per-task.
Code resides in segments in a binary. A library has data and code segments, mapped separately. They're mapped per-page for memory management: if you experience memory pressure, small pages (4K) can be swapped out. Code pages get invalidated and re-read from the original source on disk if needed.
Yeah, but because the address translation system used by segments sits on top of the actual paging mechanism, this is transparent:) Its all linear addresses.
LDT in 32-bit flat protected mode is an interface I never saw. Odd. I only knew about the single segment (code, data) layout using CS and DS and SS.
You're probably a typical unix guy:) And AFAIK, most academic literature does not cover this. Its odd how my path differs from the traditional "academic"way - I learned from system architecture and multitasking from the cpu manuals, so you can imagine my surprise when I started looking into existing operating systems:D
There was no 'Executable' flag in the page table entry (page descriptor) in the 80386 and later x86 processors, until, to make this capability available to operating systems using the flat memory model, AMD added a "no-execute" or NX bit to the page table entry in its AMD64 architecture, providing a mechanism that can control execution per page rather than per whole segment.
I'm not talking about page table entries. I'm taking about segment descriptors. Those are two completely distinct features/funcionalities. Please check the *actual* reference manual link in my previous comment.
What happens is your program starts its VMA with 16MB of non-mapped memory. Then you have the executable.text segment. Directly above that is the non-executable brk() segment (heap). Directly above that are anonymous mappings, including executable shared library.text segments. Finally, you have the stack.
You still don't see the problem. Locking PER-SEGMENT has existed since the 80286. Not per-page but PER-SEGMENT. Because most operating systems use a half-assed, simplified, portable implementation of the x86 protection mechanism this is not used - at all. So you have the stupid contiguous loading that you just described, with all the shitstorm that comes with it.
So memory looks approximately like: nnnnXXXXWWWWXXWXWXnnnnnnnWWWWW for non-mapped, eXecutable, and Writable memory. All mapped is readable to simplify this model.
Mapped and unmapped memory is not relevant for the protection mechanism, UNLESS you want per-page protection (which is kinda stupid anyway, code should reside in its own descriptor).
On x86, PROT_READ is also PROT_EXEC; there aren't 2 bits. While you can use a segmentation setup, it must be contiguous: setting the highest executable page to the top of the main executable makes the heap non-executable, but also makes all library code non-executable.
Again, I'm not talking about pages. Segment descriptors are on top of the paging mechanism (ie. all addresses are linear addresses if using pages, its not even mandatory), and you CAN have execute-only segments on top of this. You can have multiple segment descriptors mapping the same linear addresses with different permissions, if you want. Even with different DPLs. Read the actual manual, and you'll quickly understand this.
There is no bit to say, "This part is executable, and this part isn't, and this next part is, but this next part isn't, this part is, and this last part isn't."
There is a way of saying "this segment is executable, this one isn't", for an arbitrary number of segments. The GDT can have upto 8191 descriptors, and *each* LDT has this kind of limit. On modern systems, you still have the dumb-as-f**k 4 main descriptor approach + upto 4 for "userspace". This happens because the protection mechanism of almost all the SOs specifically DON'T make use of all the x86 protection features.
Hence the tricks with setting up ring-0 memory protection on data pages and then forcing a DTLB load if they're read/written, to act as a kernel-controlled NX bit.
If you're interested, take a couple of minutes to understand how the protection mechanism works on the 80386. All of it. You'll quickly realize how shitty most implementations are.
On a similar note, check "call gates" and then ask yourself why most modern CPUs have an instruction that implements what is a call gate. If you want an answer, have a look at the shitty shitty linux 2.0/2.2 code that deals with syscalls.
The problem was, originally, that the CPU itself did not have an NX bit
It doesn't need one, if a system actually implements protection according to the spec. Check http://www.intel.com/Assets/en... , section 3.4.5.1. (Page 3-16, vol. 3A). If you're still in doubt, check the original 80386 manual, http://css.csail.mit.edu/6.858... (page 109).
because you could *read* program code and why would you want to do that except to execute it
Well, read and execute are two separate permissions even on unix systems:) (eg. you cannot read a file, but you can order the system to execute it). There is a whole range of applications for read-only buffers, not only for execution, specially if eg. my application deals with DMA transfers. On modern PCI Express systems, this makes even more sense.
Yes, and in 2001 no x86 CPUs were physically capable in hardware of marking executability in the LDT.
I actually find that quite hard to believe. The LDT was introduced with the 80286, in 1981. If you check both manuals I mentioned, you'll find indication that you cannot store a TSS in the LDT and some other special descriptor types. Not code/data ones. That would actually *void* the initial purpose of the LDT, which was providing a poor man's protection mechanism without a paging system. My memory isn't what it used to be, and sometimes I do get some things wrong. It happens. But I've spent over 10 years programming mainly in x86 assembly (covering the end of the 90's), and - while I may not recall all the specifics, I still remember some stuff . The drawbacks of using LDTs have more to do with memory consumption and system complexity than anything else. If you have information that support your claim, please share:)
Some of that was just spurting. Also the PaX stuff isn't unmapped pages; they're mapped, just they're ring-0 only, and so when the userspace ring-3 execution flow tries to execute it you get a protection fault.
This happens because all descriptors map the same area. They shoudn't. PaX may be a clever trick, but it is to fix a software design flaw. Modern (elf/coff-based et al) binaries have a fixup table *precisely* to be loaded at a random address. Code segments and data segments are separated for the same reason. The same goes for the BSS info. It makes no sense *not to use this*, specially since most platforms are elf-based.
Then the OS forces a ring-3 DTLB load if it's not an execution attempt, and the program continues--the protection isn't checked if there's a DTLB entry, so this actually works.
By design, in x86 systems, every application should have its own set of descriptors (by using an LDT). In most modern systems, it doesn't. Even if using just a set of 3 descriptors for all tasks (per cpu/execution unit, of course), save/reloading of descriptor info could be done upon task switch (just like task state info is stored and a new TSS is loaded). This would allow every application to have a read/write stack that is not reachable by the code segment, and a data segment that does not map the same area as both the stack and the code segment. Linear address could also solve (at least partially) the shared library problem.
I would think anyone who goes as far as to use BSD in production would be leaning on OpenBSD.
Security is just one parameter of the equation. OpenBSD does security quite well, but the rest leaves a lot to be desired. I was a huge OpenBSD fan/user (and still buy the CDs whenever I can), but the 2-release support cycle isn't enough for my needs. And the lack of *any* kind of container or virtualization technology (like jails), lack of a modern filesystem, and somewhat dysmal smp support make OpenBSD unsuitable for most of my needs. Regardless, I do know of companies using OpenBSD in production without any hiccups, and I'd consider it for some workloads.
I would expect OpenBSD to be the bigger fraction--who uses BSD on a server?
FreeBSD is the bigger fraction. And I use BSD on servers instead of Linux. So do companies like Yahoo and Whatsapp.
Thing is we know a lot of high-profile targets are straight Linux or they have dedicated appliances that were vulnerable (FortiNet products, SonicWall products, Cisco and Juniper gear even)
Well, some versions of JunOS are based on FreeBSD. And BSD-based appliances are quite popular (pfsense, monowall, etc).
(...) I read--16 byte objects are common, so I have a "picoheap" or whatever I called it that's just a collection of mmap() areas for holding 16 byte objects
That vaguely reminds me of the slab allocation available on both FreeBSD and Linux kernels (and Solaris) (http://en.wikipedia.org/wiki/Slab_allocation).
Yes I know. I ingested enough about computer architecture in 1 month when I was 19 to have the Tetris Effect on a hilarious level.
So, do you also agree its dumb?:D
But hey, did you know that on IA-32 you can mark a page with the Supervisor bit, and when you try to access it you cause a page fault exception into the kernel, which can then check if you want to READ/WRITE or EXECUTE the page, and kill the program if EXECUTE, else force a DTLB load (in the CPU) which gets cached and no longer raises an exception until the DTLB fills up and invalidates that entry?
Off the top of my head, no:) You're probably refering to the fact that accessing a linear address that don't map to actual 'real' memory results in a page fault, and then you can decide what to do. That's how virtual memory works, and it is a bit of an overkill to be abusing it. On the other hand, COW uses a somewhat similar mechanism and no one is complaining:)
so the whole stack was automatically NX without all that extra overhead, and the heap was page-granularity protected.
Well, most modern x86 operating systems don't fully use the x86 protection mechanism.If they did, every program would have their separate LDT entry, and each program would have its own set of descriptors to make sure you're not messing around where you shouldn't. This, of course, has its own limitations (LDT entries, for once, since the GDT is limited to 64K), but it also has its own advantages (call gates are awesome, specially when every program has its own stack segment descriptor mapped into linear address space). The common approach is to use a limited set of descriptors in different execution rings, so that shared libraries and other stuff works without too much hiccups. If you saw how Linux handled syscalls in version 2.0/2.2 on x86, you'd laugh. Now modern cpu's have their own instruction to do this, instead of using call gates:)
And kept adding to it for about 3 months before cooling down. I know about word alignment.
Well, I've spent several years working in assembly with x86 ia-32 protected mode. Just not in unix environments:)
Slashdot Mirror
I still remember when Firefox was Firebird (no, not the database) or whatever. The barebones web-light version of Mozilla suite. And their goal wasn't implement everything under the sun AND the kitchen sink in a browser, but steer away from it. I guess they grew up. I blame Google's money :D
I understand your point. We can all learn something from it, and it is indeed a valuable lesson in software development and product management, but that a child could have tought - if you don't dominate your fears and fight your monsters, sooner or later they will make you suffer.
'Murica. That's why. The world exists there or some shit. And aliens love it. As well as huge creatures and whatnot. Seen it on tv, really!
Meanwhile, Tesla has gone high-end.
No, it has hone middle-age hipster. Its a nice niche.
People buying high-end luxury sedans are less concerned about an extra 10-20 grand
Tesla S is hardly a high-end sedan, let alone a luxury one. And 200Km/h top speed combined with a 500Km range is, frankly, unappealing as a sedan. Its more of a city vehicle/short commute vehicle for the family. Check Audi A8, Volvo S80 or BMW 7 for *actual* luxury sedans. And these are somewhat affordable cars.
I live in one of the few countries that actually has a fueling grid for electric cars. It was the country chosen for Leaf's initial presentation. Lexus hybrids are quite common (high-end cars), as well as Honda Civic and other hybrids. Way more than Leaf. Electric scooters are also quite popular. And Segways in tourist areas. All of these would benefit from better battery tech. And if you think manufacturers want combustion engines. you're dead wrong. Electric cars have bigger margins and require periodic maintenance (battery maintenance), so there is a better chance of frequent income from a customer. Some high-end manufacturers have put a deadline in combustion engines a long time ago (eg. mercedes), and I forsee that in a 10 year timeframe, upto 50% of new cars will be electric or hybrid. So, its the difference between profit from a specific subset of vehicles, or profit from your own competition.
On the other hand, new tech in batteries is what will distinguish car manufacturers in the foreseeable future. Limiting the tech to his own niche production is a shot in the foot - sooner or later, someone will beat him. On the other hand, producing OEM components for its own line of cars as well as competitors would yield way bigger profits. See it as Samsung producing Apple's ARM cores. Samsung probably makes more money from CPUs and displays for 3rd party than from their own best-seller phones.
The thing about OpenSSL et al is that everyone who used it had exactly the same opportunity to review the code and make a decision about its use.
Yeah, including the OpenBSD team. (As the video mentions) And they bitched about it for years, regardless of their "proactive" approach. It took a huge vulnerability to make them take the step. Meanwhile, work is being done, yet Linux Foundation is trying to cash in on it and is probably still deciding the logo sizes for the new joint task-force or whatever to "save" OpenSSL.
eriously though, stop bashing the OpenSSL project, it is just as much the product of its community as its developers.
Well, its not. If there was some vague quality control, it wouldn't be the mess it is today. If it was developed by competent developers, it wouldn't be the mess it is today. And not everyone excels at crypto stuff. The community did their job - submitted patches and bug reports that went unfixed for years. Everyone knew it was a clusterfuck, no one took the extra step - but the community did what it was supposed to do. The OpenSSL team didn't delivered, though.
Military grade encryption
I've actually been in the military (more than a decade ago), and had contact with "top of the line" encryption systems. At the time, I was already using for myself OpenBSD and actual strong encryption. "Military Grade" is like the "Bio" sticker in food - a way of charging more for worthless shit.
I could see being an OpenSSL guy would be a huge one
I don't. OpenSSL has always been the disaster waiting to happen. The codebase is messy, no one really understands it, and there is no real criteria when adding stuff. I have no experience with it and I knew it was a big pile of stinking poo (its not like this hasn't been a probem before), so I hardly doubt that saying you're an OpenSSL dev would give anyone any credit.
Usually have a Novell certification in some drawer and will defend Novell to this day.
I'm not Novell certified (nor a security expert), but Novell DID have his awesomeness - at some level, unmatched today.
I do agree with most of what you said, but the problem is two-fold: actual security experts are either matematicians or hardcore developers, and more often than not, cannot communicate with regular people. And no, this is not a feature. Transmiting a concrete idea to a peer without noise is the ultimate developer experience - you need to develop a subset of the language that allows you to carry your own message without being subject to change on the endpoint; And because most of the guys entwined with computers are too tied in the digital all-or-nothing approach, they think its not their fault they cannot operate on an analog world. Which, by itself, is hilarious, because "digital computers" are actually a subset of the computing field.
In short, the problem is the nerd type. Get rid of them, have them behave and communicate like regular people, and all these bs types are out of a job. And for Pete's sake, its not like most of what is CS is hard.
From the presentation, its not. Its POSIX-compatible. I'm not sure if Windows provide an adequate entropy source they mention, but I'd assume so. They explicitly removed dead architectures (hence the VC++ reference).
I'm assuming you're running a system with full blown CGA or EGA drivers, then. 1990 called and they want their DOS floppy back.
Big-endian amd64. Its even more funny.
Or to oh-so-many puppet installations out there. Specially when using PKI auth for automated tasks.
With systemd it is just one convenient systemctl stop apache
...Except most of the time you DON'T want to stop everything that apache depends on. Eg. MySQL and Memcache comes to mind. If you DO need this, you can easily do it by an alias (the most easy solution) to something like apachectl stop && service php5-fpm stop. Again, this isn't even a problem.
What you usually want is to start all dependencies of a given program (eg. fpm when you start apache). This is a solved problem.
Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.
I don't get where you think *text* is a lossy format, but ok. Lets add complexity and failure points to something that should be easy.
You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?
Apples and oranges. Text is never a lossy format.
So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache
Well, you do *mention* apache, so the most common approach is to just kill the master process, and all the child processes die. You know, unix systems. In case of apache, you even have an utility for it - apachectl. Other approaches would be 'service apache22 stop', kill -TERM `cat /path_to_apache_pidfile`, and of course, kill -9 $(ps -ef |grep apache2 |grep -v grep| awk '{print $2}') or any other variant (eg. in freebsd you could do a ps ax | grep Ss | grep httpd to determine the master apache process and its pid to kill). On many linux systems, you also have killall and/or pkill, that will achieve the same effect by process name, and easily usable with apache, nginx and the cgi wrappers you may have running.
I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.
I did. FreeBSD 9.2. Most of the sleeps are for hardware settling. Replacing a shellscript sleep() with a binary version of it is not a solution anyway. Both rc.d and init.d approaches allows you to prioritize script startup, to achieve that same effect. In FreeBSD, the rcorder (http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8) allows you to quickly visualize service dependencies. In OpenBSD I specify in rc.local the order I want my stuff to start. I'm assuming other systems provide vaguely the same funcionality, its not rocket science. (Again, a solved problem).
Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.
I'm not against uniformization. What I don't see is the need for yet another tool that fragments even more the available options. And uniformization is pretty common in other operating systems - check eg. FreeBSD and OpenBSD: they are quite different in terms of setup, but not that different. Its not like it wasn't possible before. That approach exists for decades.
Check out http://www.freedesktop.org/sof... [freedesktop.org] , especially all the options starting with "Private" there.
It sounds like a meta-version of linux containers. Why would I want that implicit on a startup script? Its about doing one task and doing it good.
Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.
You did not suggest. You touted it as solution to problems that, frankly, do not exist. It may have features that are very helpful, it may solve a lot of problems, but you mentioned none. Not one valid existing problem.
By then all the hotheads that are running for the BSDs now will be back
Probably not. BSD is not usually appealing to the linux crowd, at least server-wise (the guys that would actually take advantage of some of the features you mentioned). And the ones I know did t
BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix
These are the golden times of Unix.
You really want to go back to that? Seriously?
You sound like its a bad thing. Its not.
the journal instead of a set of randomly formatted text-dumps all over /var/log,
I'll take the text-dumps any day, thanks. And since they're usually created via *syslog*, they may not even be stored locally. And they are easy to manipulate with the available shell tools (grep; cat; awk; etc). If you want a database-driven syslog, there are plenty around.
a convenient way to kill apache with all the crap that it started,
It seems you're getting closer to the real problem. Apparently you don't know how to operate a vaguely modern unix system.
a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there.
Usually the sleeps are for hardware settling, not for script startup. Eg. when you plug a USB device that may take a couple of seconds to be available after powering on. This will be needed *regardless* of what script is running the show. And dependency management on start scripts is a solved problem. Have a look at FreeBSD/NetBSD rc.d system, or Solaris SMF.
a more secure system by being able to isolate daemons from one another and the rest of the system.
So, its a startup daemon AND a kernel, huh?
a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them
Convenient for who? For you, because you cannot be bothered into using the existing tools? You may have some unusual requirements, it doesn't mean everyone else has the same needs. And while I'd applause a sort-of-standard way of bootstrapping Linux distros, adding complexity seems to be a pretty stupid approach.
70-90% of all soy, corn and wheat grown in the US is fed to livestock...and the return on that (in calories or protein) is a fraction of what goes into it..
Of course. But the return on stuff our digestive system can actually process without difficulty is way bigger, or else we'd be eating dirt. After all, plants get their nutrients from the ground, right?
but that's not how 99% of the livestock in the US is raise
I'm assuming you have a huge experience in cattle farming in the US, to come up with such a bold number. Also, the rest of the world isn't the US.
And imagine if it were: the majority of land is already used for this kind of agriculture.
You're assuming that if we just grew soy instead, we'd be better off. The fact is that what most animals do is pruning (they eat the greener leafs of selected species, but leave older leafs intact as well as the roots). Most farming techniques don't use pruning, so the stress in the soils is way bigger. As an example, look at corn plantations. Also, rations made directly by smashing corn use the whole plant (except the roots) while the plant is still green, while human feeding based on it usually only recycles the seed part of it (so half of the plant is waste or used as low-nutrient food for cattle).
Again, just look at that graph.
Well, I cannot speak for graphics or metrics made by others, specially when they aren't really peer-reviewed and related to a specific population. Of course the amount of water I was mentioning was by direct consumption - there is a whole lot of water used for cleaning, irrigation and whatnot. That varies a lot according to the location of the cattle, the heat, the kind of feeding, among other factors. If you're worried about water usage, have a look at aluminum processing or lorries.
And that's not how much water goes into making milk. It's definitely not 1:1
Well, you can show me any blog articles you want.I can only speak by my experience, by working on a cow farm during the summers in my youth.
Imagine the ratio of surface area to protein/vital nutrient intake once those animals are converted into plants. Do you know how much grass a cow eats and how efficient it is converting it and water into milk and tasty meat? Do you think you can do the same by just eating grass? Go, help yourself. An adult cow drinks 20-40l of water and produces around 20l of milk, while producing tasty meat. Do the math.
I have an indian friend that tasted meat the first time when he was like 21 or 22. What he described, besides the obvious bacon bliss, is a symptom of protein privation during is whole life - a "meat rush". He will now bite a steak or a burger everytime he can.
Well, it doesn't take more water for the same protein value. One of the reasons we eat livestock instead of grass is because we need more complex stuctures (eg. proteins) to live. Animal shit may be a problem, but human shit is way worse, as it can't even be easily recycled as a fertilizant. I'm not in favour of animal cruelty (so some heavy processed meat process makes me wonder where we're going, but on the other hand, recycling everything from a corpse is more thant what I do with my vegetables), but your meat choices have no impact in life.
1) You're a short-sighted moron, but that we already knew;
2) If crowdfunding of these kind of projects work, we'll see many more in the future - even if it fails its goal;
3) Learning engineering tricks form a viable, proven piece of tech that went where no man has been before is priceless. You can simulate whatever you want, but in the end I'll take a proven piece of gear to a simulation any day;
4) Your opinion's worth is way inflated. Even for free, its still overpriced.
Ah, ok. SO like Segmexec in PaX where the address space is dual-mapped and split 50/50, or W^X where part of the memory is NX.
Yeah, sort of exactly like that. But it has existed since "forever" in x86-32 and you can specify arbitrary segments per-task.
Code resides in segments in a binary. A library has data and code segments, mapped separately. They're mapped per-page for memory management: if you experience memory pressure, small pages (4K) can be swapped out. Code pages get invalidated and re-read from the original source on disk if needed.
Yeah, but because the address translation system used by segments sits on top of the actual paging mechanism, this is transparent :) Its all linear addresses.
LDT in 32-bit flat protected mode is an interface I never saw. Odd. I only knew about the single segment (code, data) layout using CS and DS and SS.
You're probably a typical unix guy :) And AFAIK, most academic literature does not cover this. Its odd how my path differs from the traditional "academic"way - I learned from system architecture and multitasking from the cpu manuals, so you can imagine my surprise when I started looking into existing operating systems :D
There was no 'Executable' flag in the page table entry (page descriptor) in the 80386 and later x86 processors, until, to make this capability available to operating systems using the flat memory model, AMD added a "no-execute" or NX bit to the page table entry in its AMD64 architecture, providing a mechanism that can control execution per page rather than per whole segment.
I'm not talking about page table entries. I'm taking about segment descriptors. Those are two completely distinct features/funcionalities. Please check the *actual* reference manual link in my previous comment.
What happens is your program starts its VMA with 16MB of non-mapped memory. Then you have the executable .text segment. Directly above that is the non-executable brk() segment (heap). Directly above that are anonymous mappings, including executable shared library .text segments. Finally, you have the stack.
You still don't see the problem. Locking PER-SEGMENT has existed since the 80286. Not per-page but PER-SEGMENT. Because most operating systems use a half-assed, simplified, portable implementation of the x86 protection mechanism this is not used - at all. So you have the stupid contiguous loading that you just described, with all the shitstorm that comes with it.
So memory looks approximately like: nnnnXXXXWWWWXXWXWXnnnnnnnWWWWW for non-mapped, eXecutable, and Writable memory. All mapped is readable to simplify this model.
Mapped and unmapped memory is not relevant for the protection mechanism, UNLESS you want per-page protection (which is kinda stupid anyway, code should reside in its own descriptor).
On x86, PROT_READ is also PROT_EXEC; there aren't 2 bits. While you can use a segmentation setup, it must be contiguous: setting the highest executable page to the top of the main executable makes the heap non-executable, but also makes all library code non-executable.
Again, I'm not talking about pages. Segment descriptors are on top of the paging mechanism (ie. all addresses are linear addresses if using pages, its not even mandatory), and you CAN have execute-only segments on top of this. You can have multiple segment descriptors mapping the same linear addresses with different permissions, if you want. Even with different DPLs. Read the actual manual, and you'll quickly understand this.
There is no bit to say, "This part is executable, and this part isn't, and this next part is, but this next part isn't, this part is, and this last part isn't."
There is a way of saying "this segment is executable, this one isn't", for an arbitrary number of segments. The GDT can have upto 8191 descriptors, and *each* LDT has this kind of limit. On modern systems, you still have the dumb-as-f**k 4 main descriptor approach + upto 4 for "userspace". This happens because the protection mechanism of almost all the SOs specifically DON'T make use of all the x86 protection features.
Hence the tricks with setting up ring-0 memory protection on data pages and then forcing a DTLB load if they're read/written, to act as a kernel-controlled NX bit.
If you're interested, take a couple of minutes to understand how the protection mechanism works on the 80386. All of it. You'll quickly realize how shitty most implementations are.
On a similar note, check "call gates" and then ask yourself why most modern CPUs have an instruction that implements what is a call gate. If you want an answer, have a look at the shitty shitty linux 2.0/2.2 code that deals with syscalls.
The problem was, originally, that the CPU itself did not have an NX bit
It doesn't need one, if a system actually implements protection according to the spec. Check http://www.intel.com/Assets/en... , section 3.4.5.1. (Page 3-16, vol. 3A). If you're still in doubt, check the original 80386 manual, http://css.csail.mit.edu/6.858... (page 109).
because you could *read* program code and why would you want to do that except to execute it
Well, read and execute are two separate permissions even on unix systems :) (eg. you cannot read a file, but you can order the system to execute it). There is a whole range of applications for read-only buffers, not only for execution, specially if eg. my application deals with DMA transfers. On modern PCI Express systems, this makes even more sense.
Yes, and in 2001 no x86 CPUs were physically capable in hardware of marking executability in the LDT.
I actually find that quite hard to believe. The LDT was introduced with the 80286, in 1981. If you check both manuals I mentioned, you'll find indication that you cannot store a TSS in the LDT and some other special descriptor types. Not code/data ones. That would actually *void* the initial purpose of the LDT, which was providing a poor man's protection mechanism without a paging system. My memory isn't what it used to be, and sometimes I do get some things wrong. It happens. But I've spent over 10 years programming mainly in x86 assembly (covering the end of the 90's), and - while I may not recall all the specifics, I still remember some stuff . The drawbacks of using LDTs have more to do with memory consumption and system complexity than anything else. If you have information that support your claim, please share :)
Some of that was just spurting. Also the PaX stuff isn't unmapped pages; they're mapped, just they're ring-0 only, and so when the userspace ring-3 execution flow tries to execute it you get a protection fault.
This happens because all descriptors map the same area. They shoudn't. PaX may be a clever trick, but it is to fix a software design flaw. Modern (elf/coff-based et al) binaries have a fixup table *precisely* to be loaded at a random address. Code segments and data segments are separated for the same reason. The same goes for the BSS info. It makes no sense *not to use this*, specially since most platforms are elf-based.
Then the OS forces a ring-3 DTLB load if it's not an execution attempt, and the program continues--the protection isn't checked if there's a DTLB entry, so this actually works.
By design, in x86 systems, every application should have its own set of descriptors (by using an LDT). In most modern systems, it doesn't. Even if using just a set of 3 descriptors for all tasks (per cpu/execution unit, of course), save/reloading of descriptor info could be done upon task switch (just like task state info is stored and a new TSS is loaded). This would allow every application to have a read/write stack that is not reachable by the code segment, and a data segment that does not map the same area as both the stack and the code segment. Linear address could also solve (at least partially) the shared library problem.
I would think anyone who goes as far as to use BSD in production would be leaning on OpenBSD.
Security is just one parameter of the equation. OpenBSD does security quite well, but the rest leaves a lot to be desired. I was a huge OpenBSD fan/user (and still buy the CDs whenever I can), but the 2-release support cycle isn't enough for my needs. And the lack of *any* kind of container or virtualization technology (like jails), lack of a modern filesystem, and somewhat dysmal smp support make OpenBSD unsuitable for most of my needs. Regardless, I do know of companies using OpenBSD in production without any hiccups, and I'd consider it for some workloads.
I would expect OpenBSD to be the bigger fraction--who uses BSD on a server?
FreeBSD is the bigger fraction. And I use BSD on servers instead of Linux. So do companies like Yahoo and Whatsapp.
Thing is we know a lot of high-profile targets are straight Linux or they have dedicated appliances that were vulnerable (FortiNet products, SonicWall products, Cisco and Juniper gear even)
Well, some versions of JunOS are based on FreeBSD. And BSD-based appliances are quite popular (pfsense, monowall, etc).
(...) I read--16 byte objects are common, so I have a "picoheap" or whatever I called it that's just a collection of mmap() areas for holding 16 byte objects
That vaguely reminds me of the slab allocation available on both FreeBSD and Linux kernels (and Solaris) (http://en.wikipedia.org/wiki/Slab_allocation).
Yes I know. I ingested enough about computer architecture in 1 month when I was 19 to have the Tetris Effect on a hilarious level.
So, do you also agree its dumb? :D
But hey, did you know that on IA-32 you can mark a page with the Supervisor bit, and when you try to access it you cause a page fault exception into the kernel, which can then check if you want to READ/WRITE or EXECUTE the page, and kill the program if EXECUTE, else force a DTLB load (in the CPU) which gets cached and no longer raises an exception until the DTLB fills up and invalidates that entry?
Off the top of my head, no :) You're probably refering to the fact that accessing a linear address that don't map to actual 'real' memory results in a page fault, and then you can decide what to do. That's how virtual memory works, and it is a bit of an overkill to be abusing it. On the other hand, COW uses a somewhat similar mechanism and no one is complaining :)
so the whole stack was automatically NX without all that extra overhead, and the heap was page-granularity protected.
Well, most modern x86 operating systems don't fully use the x86 protection mechanism.If they did, every program would have their separate LDT entry, and each program would have its own set of descriptors to make sure you're not messing around where you shouldn't. This, of course, has its own limitations (LDT entries, for once, since the GDT is limited to 64K), but it also has its own advantages (call gates are awesome, specially when every program has its own stack segment descriptor mapped into linear address space). The common approach is to use a limited set of descriptors in different execution rings, so that shared libraries and other stuff works without too much hiccups. If you saw how Linux handled syscalls in version 2.0/2.2 on x86, you'd laugh. Now modern cpu's have their own instruction to do this, instead of using call gates :)
And kept adding to it for about 3 months before cooling down. I know about word alignment.
Well, I've spent several years working in assembly with x86 ia-32 protected mode. Just not in unix environments :)