Slashdot Mirror
What to Expect from Linux 2.6.12
apt-get writes "Saw this Linuxworld report from the annual Australian Linux conference, Linux.conf.au, in Canberra last week. The article outlines some of the new features we can expect for the 2.6.12 kernel release, including: support for trusted computing, and security enhanced Linux. The kernel developers are also working on improving the 'feel' of the Linux desktop with inotify for file managers and events notification so hardware 'just works'. Unfortunately no release date other than 'sometime soon' is given."
I know I'm going to rub a few feathers the wrong way, but I think this kind of feature creep is actually good for the Linux kernel.
The more features we can get into kernel mode, the less we need to rely on "chaining" and other Unix-way solutions and we can think more about applications and OS services as "whole units".
And since the majority of installations of this latest version will be on desktops, the more hardware support, the better the hardware support, the more seamless the hardware support, the better.
It would be nice to see some componentization of the kernel to allow for easy stripping of unnecessary features, but as the kernel will stand, the features are all necessary.
Trusted Computing is just a technology and like probably all technology it can be used to do something good with it (make computers safer), or something bad (take control away from the user to enforce DRM, for example).
As the former seems to be what the inclusion in the Linux kernel is about, I think it's a good thing. And remeber, it's a free system, so you'll always have the choice not to use it or only use what you want to use it for.
This seems like a good thing to me. One of the advantages of Linux not been driven by a need to produce revenue.
The current linux kernel is pretty amazing if you think about it. It's running on everything from OS 390's right down to cell phones with features for everything inbetween. This flexability generally means that the kernel has a lot of untested combinations. Thats a potential problem.
The kernel needs a team of people that specifically tries to break the kernel. Right now kernel testing is haphazard at best. By devoting a team of people (just like the developers) whose sole purpose in life is to break the kernel we (the community) will improve the security, and quality of future linux kernels. It will also improve the quality of code going into the kernel.
The new code sounds very good - but the linux development community needs some hackers to break stuff.
Cluge
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
'did you ever try to configure a kernel these days?' - no, my distro does it for me.
I don't see what the problem is. My distro has all the drivers compiled for me. What use case do you have other than compiling your own kernel for the sake of it?
On a practical level, Linus has said many times that he won't do this because it would require freezing the internal kernel api. While this might sound good for an outsider, you only have to consider how much say the USB structure has been reorganised to realise how bad an idea it would have been if this was all frozen.
And remeber, it's a free system, so you'll always have the choice not to use it or only use what you want to use it for.
Sure you'll have a choice if you decide to compile your own kernel. But I don't see grandma or uncle bob downloading theirs from kernel.org and compiling it from source. I don't oppose it's inclusion in the tree but I think if money is involved (RIAA and MPAA have deep pockets), it won't be too difficult to persuade some of the more user-friendly distros to compile a stock kernel with trusted computing compiled in.
I guess I just believe that computer scientists have a responsibility to protect users from malicious and sneaky actions that violate their rights as computer users. Or maybe I just have a pessimistic view of society.
Let's keep it that way!
As long as the developers release it when it's done, and not according to some abstract schedule, we'll have the best operating system there is.
I don't know the meaning of the word 'don't' - J
"Bundling them all with the kernel will just no longer work (did you ever try to configure a kernel these days?)."
Yep and I don't really see a problem. What's your point exactly and who has to configure his own kernel anyway? (apart from stupid gentoo ricers like me:)
Seriously, I don't really know what your problem is. Maybe you could be a little more specific about which drivers you constantly have to recompile. Thanks.
Inotify is a replacement for dnotify. With both you can watch for a file for changes. You can even watch a directory for changes.
I've seen the older dnotify thing at work in KDE, and even that seemed to work much better than the equivalent in MacOS X on my iBook. I've frequently saved a file from Safari, gone to attach it in Mail only to find it's not present in the file selection dialogue box (that I've opened after saving the file). A quick click on the desktop makes things update, but it's bloody annoying.
I've noticed that open source solutions to problems like this often iterate through various designs, starting from a quick hack, moving on to something with more features grafted on and then an occasional redesign or two before something much longer-lasting and full-featured comes into being. I suppose the lesser need for backwards-compatibility helps a lot - you can kill a crap design and rewrite any (open source) software which used it, instead of having to keep it until the end of time in the style of Windows...
Tedious Bloggy Stuff - hooray?
As much as I would like it to be so, I don't know any grandmas or uncle bobs that install their own Linux machine. All the grandmas and uncle bobs that I know don't even know how to install windows (not that's it's necessarily easier but it is the general perception). They either get it shipped with the OS or get their grandson/cousin to install it.
those who get it with the PC most probably will end up with windows anyway. The others will have the support of the half geek to either install a distribution that fits their TC needs or download/patch/recompile the kernel of those that don't.
Is the inclusion of trusted computing a good thing here? Many people in the /. crowd didn't seem to like the idea of it's inclusion in Windows...
I think the complaints about locking machines down are more in who gets the keys...
Tedious Bloggy Stuff - hooray?
If you don't need protection, don't turn it on. I assume that the kernel segments that deal with trusted computing will be able to be compiled out, and you'll be fine. As for the fact that it'll probably be included by default on many systems, I have to say that I don't consider "safe by default" a fallacy in any way.
Many activeX controls have to be signed for them to run, and they have no trouble getting signed by very high profile companies such as VeriSign. Signing files doesn't prove anything. To get real security, you should run it in a sandbox. When a sandbox is properly implemented, you don't have to worry about whether the code is signed or not.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I realize that it is probably paid for by IBM as part of their campaign to try to dupe people into thinking that the DRM vehicle they call "trusted computing" (remember: that is "trusted" as in "other people can trust your computer to control you") is something benign. However, implementing "TC" in Linux feels like a gigantic waste of time: does anybody here REALLY think that the proprietary DRM applications that are the ONLY REASON WHY WE WOULD NEED "TC" are ever going to be ported to Linux?
Do you see the DRMed "music stores" (it is more like a barter: "give us your money and control over your computer, and we'll let some Britney and Fiddy come from your speakers!") falling over themselves to run on Linux? Do you think that is because Linux doesn't support "TC" or because those companies couldn't possibly care less about Linux as a platform? I'll give you three guesses. And the ENTIRE POINT with "TC" is to make it impossible for us to reverse engineer and write our own replacements for those applications - so be definition we can forget about that alternative.
All I can say is, I hope they had fun implementing it, and that they feel happy about the all the people who believe the astroturfing that "TC" isn't the Torjan Horse of DRM.
"TC" is DRM is the tool of closed networks, closed source, a closed society, and a closed future. People who believe it will coexist with Linux are so naive that it would be quaint if it wasn't so fucking scary...
What about shell scripts or compiled applications that we write ourselves? Do they have to be signed, and how can that be done in a secure fashion? That could be a real nuisance.
The impression I got was that only the image of critical parts of the OS needed to be signed, and its signature would be verified by the boot process. But I'm probably wrong.
I'm not sure what the beef here is... I happen to run Gentoo and love having the ability to easily add/remove/modularize (is that even a word?) drivers from the kernel... And it is rock stable even on an amd64... I can streamline the kernel (becuse it makes me feel better) and ditch things I don't want (like hiding certain hardware or compiling 3rd party drivers in their place). Just giving the kernel what I know it needs does cut down on boot times because of hardware auto-detection, but of course you can just edit init scripts to get the same effect... I'm pretty sure you don't need the entire ~100 MB source to compile drivers either. Fedora stopped including the kernel-source RPMs a while ago and I have had no trouble compiling custom drivers.
Isn't this the great thing about Linux though? I can re-compile the kernel to my heart's content under Gentoo and pretend it makes my computer faster. If I want to slap Linux on a computer and just have everything work, I can go Fedora, SuSE, whatever, and have everything built in and well tested. My choices with Mac OS or Windows basically boil down to "should I go with the latest version, or stick with what I have?". But hey, whatever changes are coming down the pipe for device drivers is fine by me as long as it doesn't rob me of any choices or flexibility.
Actually, I wrote my thesis on life experience.
I mean, WTF? People really are confused about GNU/Linux aint they? When the FSF asks you to refer to the entire system as GNU/Linux they are not asking you to refer to the kernel as GNU/Linux. So if you're going to post a story on Slashdot it that is 100% entirely about the kernel then it makes absolutely no sense to put it in the GNU section.
How we know is more important than what we know.
When I was younger I loved downloading the next kernel, going through every single option, reading the help, and deciding if I want it.
:) Led to me contributing a tiny bit to the kernel (I have a 3 line patch in there still! :) )
;)
Great fun
I don't these days.. perhaps I should. Great for learning even if I don't produce a working kernel heh.
It would be fun to play with SElinux and everything. I'm such a geek..
When TC is pervasive on M$, all media will be DRM'ed and you will have no choice but to use M$ if you want to participate. Linux will be able to use TC for security, but because of it's open nature, no trusted content will be released for it.
Trusted computing is necessary to make DRM work. Any other use can be implemented in software. Basically you *have* to surrender control of your computer in order to play protected content. TC will allow protected content to be available for M$, but not on open systems. Not only will it lock out permissible uses under current copyright loaw, but it will serve to further bolster the monopoly of windows.
Microsoft hasn't provided a stable API. Many Drivers from NT4.0, 2000, XP and 2003 don't work accress all NT based platforms. There answer has been to support all NT based platforms with diff. drivers for Each OS. What happens when longhorn comes out. Either the manf. has keep up with the changes of Longhorn and released updated driver for that version or doesn't support it and you can't use that device on Longhorn. I have been bitten with hardware no longer supported in new Microsoft OS more times than I care to admit. Under Linux I have a Raid Controller by a manf. that went out of bussines 10 Years ago that still works under linux today. In linux it seems once supported allwas supported.
Actually, I'd bet the "majority of exploits" are social-engineering attacks where users are tricked into running email attachments, installing software from a webpage, or installing spyware bundles like Kazaa.
The solution for this is an easily configurable sandbox, which the vapor factory in Redmond says they are working on. Maybe "Sandboxed computing" is a better term, but the DoD called it "trusted computing", so that's what we're stuck with.
"Sandbox computing" also has little relationship to the trusted key storage, bootloader verification and other planned DRM features (as far as I can tell). But its fun to conflate the two ideas for FUD and profit.
Whenever I hear the word 'Innovation', I reach for my pistol.
Did you read what you just said ?
... next time microsoft needs all the internal documents from your company, they will just open their explorer, that just happens to be implicitly trusted by your company's software, and it can do 2 things : they can both read the documents, and they can make the documents AND any backup copies you may have inaccessible.
...
Next time you find out by email your boss is about to fire you because you're e.g. colored, you will not be able to forward that mail to the authorities, and your boss will be able to destroy ALL traces of that email from his home.
Next time the police really needs data on a person's computer it will not be possible to extract it, because "TPM" will prevent it.
And
Adobe will be able to do this for pdfs, your bank for your bank statements,
THAT is what TPM is about.
I won't argue with that, but it seems that remote attestation will allow them to comply with the letter of the law (even publishing all protocol specs) and still lock out competition.
Finkployd
Yes, but once that quick hack is deployed, even to beta testers who then build on it (if the testers are large enough), Microsoft supports them in perpetuity.
.NET protocols, and remember "COM" covers several iterations itself and has several variants. Windows supports them all.
Example: COM, DCOM, ActiveX, now the various
I am increasingly convinced of two things: One, this is why Windows is so bloated; once a feature gets in, it never gets out. I suspect this is the sole reason; if anything, Microsoft programmers are above average so most other explanations don't fly. Two, this is why open source-style development, realizing you can't have backwards compatibility forever and ever and depending on source code and its recompilation, will eventually win; reverse compatibility becomes too expensive. (This is not to say OSS will win, though OSS gets a big foot in the door when source is distributed, but that the style is inevitable. Shipping binary code to run directly on the processor is just too low-level to be shipping programs around in 2005. The JVM has this right, as do a number of open source projects, shipping the code to a virtual machine around.)
This also explains my assertion that Microsoft programmers are above average with the observed code quality coming out of Redmond; they get increasing amounts of the "above-averaged-ness" frittered away in backwards compatibility support. If Microsoft could truly just start 100% fresh, which they can't (destroy-the-business kind of can't), they'd probably produce a fearsome OS. We'll never know.
(The eye candy of Longhorn may take all the processor they've spec'ed out, but, most likely, the reason it needs so much memory is all the garbage hanging around, being backwards compatible. The OSS equivalent of Longhorn eyecandy will fit in much less memory, even if it needs the same or more processor, as a result, and the memory advantage is only going to grow on the OSS side, because by and large, it doesn't implement every half-assed idea from 1988 on in itself. It tries to constrain the half-assed ideas to the last year or so, and goodness knows there are plenty to go around.)
AC: It isn't usefull by itself, but if you combine it with ExecShield and SELinux it could be a useful security layer.
Or, you could just combine ExecShield and SELinux by themselves and have a useful security layer, without needing Trusted Computing at all.
Brushing aside the minor side-features, Trusted Computing is really about tamper-resistant hardware enforcing the signatures of software on the PC. The main use of that is preventing the legal and physical owner of that PC from hacking programs on his own computer, so that RIAA music publishers can continue to trust it.
This is some of the things you can expect:
Already, we see software design flaws. Just because you mention there are multiple things tells us that it's not a clean system, and that it ignores the traditional Unix dictate: "Do one thing, and do it well".
You list the user blocking unsigned programs from running, and you also list hardware-accelerated encryption. Those are two entirely different features, and there is no good reason why they should be part of the same system. If I desire either of those, I should be able to install it individually.
More importantly, you ignored the most important feature of Trusted Computing: remote attestation. Indeed, it is to support RA that "Trusted" hardware will be built at all- if it was just about the OS not running unsigned programs, that could be implemented in pure software. And the encryption-accelerator is just a bonus feature they tossed in, "As long as we're stamping new chips anyhow". RA says you can prove to remote individuals that you are only running software signed by them, so content publishers can prohibit the use of 3rd party programs to view their data.
Vendor lock-in and beyond.
What do you mean? Do you mean that Trusted Computing is not intended for DRM? Thatis what its sponsors would have you believe, but the reality is this - as a security measure, TC is more or less redundant. As a measure for perfect enforcement of DRM, TC is damn near the absolute best thing imaginable. And you can bet that Microsoft will do everything in its power to ensure that those not running Trusted Windows (with the emphasis on Windows - Trusted Linux is among Microsoft's targets) are disadvantaged in every possible way, with being denied internet access being their ideal.
A script copies the compiler, driver sources, and kernel headers to a chroot; compiles the driver; exits the chroot; copies the driver to the appropriate location; and loads it. Another script removes the driver if the user changes his mind.
No stable binary interface is necessary in this way, and no development tools on the user's system so no worries about GCC standards tightening breaking the compile - only worry is source compatibility, so the tested kernels can be stamped on the CD. (e.g., Compatible with Linux up to version 2.6.10)
LRC, the best-read libertarian site on the web
First off, a CRT's refresh rate can be above 100hz, but even so, the CRT's refresh rate is not synchronized with the mouse polling rate. So the cursor drawn to the screen is done so using the last mouse polling data. With 125hz, this means the data could be 8 miliseconds old, while with 500hz, the data is a maximum of 2 miliseconds old. Hence there is less lag in physical mouse movement and its logical and visual effect.
It is actually more complicated than that, but those lag values are for lag due to mouse rate alone. Of course the CRT refresh rate introduces its own lag. But in short, keeping monitor refresh rate constant, because the monitor is not synchronized with the mouse, increasing the polling rate of the mouse makes for an improvement. Conversly the same can be said for increasing the refresh rate of the monitor.
You don't have to take my word for it. If you are already using a good USB mouse at 125hz, try it at 500hz. You will notice the difference. Once you use 500hz for several days, try switching back to 125hz. You will hate it. The difference is even more noticable with higher resolution mice, such as 800 dpi and 1600 dpi optical mice because the movement delta can be quite large and a delay of 8 miliseconds of a large delta "feels" awkward.
Of course, if you use a very crappy low resolution USB mouse, the difference is harder to notice.
I agree that what you say is the 'main reason' is a single reason for trusted computing.
But for systems that are switches or teller machines or heart monitors or guidance control systems for a missle or some other device, they use trusted computing for very good reason.
There are many uses for computers. Some of this is on the desktop. On the desktop 'trusted' can be a hinderance. Engineers need their many devices to work and not be tampered with. Many of these are nodes on a network with no keyboards and no monitors. They can be embedded in devices. Trusted computing assures that all of this is not tampered with. It really makes sense.
Try to think beyond your desktop, dude. Most processors are somewhere else.
The initial version started in December 2001. epoll in its present form was added to the base kernel in 2.5.45, October 2002.
Wrong. It's in every 2.6-based distro, which is most of them right now, and for the "commercial enterprise class" users that includes Red Hat Enterprise Linux 4 and SuSE Linux Enterprise Server 9.
I know the gist of your complaint, but kqueue really was considered during the design of the current epoll, and was rejected. Looking at the kqueue documentation now, I think Linus was right to reject it.
The ideas underlying kqueue are good, but the implemented API has flaws. Take a look at the documentation, and ask: Can you wait for reading/writing on a terminal file descriptor? What about an audio device? A serial port? The answer is not according to the documentation, yet it ought to be possible to wait on an any file descriptor with the same meaning as select/poll.
The initial versions of /dev/epoll had the same flaws and others. But that was rejected too, and it had to be changed to the epoll you see today before it was accepted.
epoll isn't perfect. In fact I argued for a more general event-waiting API at the time, but Linus likes simplicity, and that's what we have now. It is nice and simple to use. It's major ommision is that it doesn't play well with AIO, and that will have to be solved eventually.
It's you who are wrong on this. Ok, let's try exploiting it.
I've mapped a write-only file with PROT_WRITE only (not PROT_READ), opened with O_WRONLY. The file is write-only: it has permission 0200 (--w-------), and it can't be opened for reading or read-write: verified by "cat test_mmap_file" correctly saying "Permission Denied" and other ways it cannot be read.
Then I read from the mapping and printed what was read, to prove it was really reading the file's contents. I tried both a local file in /tmp, and also a file over NFS. Results:
Well, well, the exploit works. You should really test a feature before arguing about it. :)
Tsk, a security hole in the current production versions of FreeBSD and NetBSD no less. :) [It's unlikely to have major consequences, though, as write-only files are rarely used and never for anything critical.]
The results for i386 are no surprise, as the CPU itself is incapable of write-only mappings. (It's a bug that BSD let's you map a write-only file at all, but given that it does then it's not surprising you can r