No!
|
| Author | Content |
|---|---|
| cm1967 Jun 27, 2009 6:58 AM EDT |
I will never, never, never want to run Windows drivers natively on Linux. I made the switch more than 10 years ago to Linux because I don't like the way MS does business and because their software is poorly coded. If I am unable to find a driver for something for Linux then I won't purchase or use that piece of hardware. |
| tracyanne Jun 27, 2009 7:08 AM EDT |
Quoting:I don't like the way MS does business and because their software is poorly coded Windows Drivers are not written by Microsoft. So whether Microsoft code is poorly written or not is irrelevant to this issue. The Windows Drivers are, in the main written by the same companies who write the Linux drivers (at least where the Linux drivers are not a community effort, which is to say most of them), the is the companies who develop the hardware. If you want to argue against the LUK, at least come up with valid arguments. |
| nikkels Jun 27, 2009 7:14 AM EDT |
I am all for it, as long as the results are offered as a choice. Choice one: Pure windows Choice 2 : Linux as we know it. Choice 3 : LUK |
| maxxedout Jun 27, 2009 7:44 AM EDT |
Quoted:Quoting:Windows Drivers are not written by Microsoft. Yes, but to OS the drivers are written to IS. |
| AwesomeTux Jun 27, 2009 8:04 AM EDT |
Quoting:Windows Drivers are not written by Microsoft. So whether Microsoft code is poorly written or not is irrelevant to this issue. Well, Windows being poorly written = Drivers poorly written in order to work with the cr@p that is Windows :) |
| montezuma Jun 27, 2009 8:27 AM EDT |
Traceyanne, Fair point but it is worth pointing out that this argument holds only when closed binary blobs are involved such as the nvidia video driver. Lots of linux drivers are open source so are subject to correction not just by the company (or individual) that writes them but also the community. Usually that isn't the case for windows since they rely on the master servant relations with hardware makers to get drivers written |
| tracyanne Jun 27, 2009 8:32 AM EDT |
Quoting:Well, Windows being poorly written = Drivers poorly written in order to work with the crap that is Windows :) No, it doesn't work that way. They are written against an API, so the quality of the code on the other side of the API has no bearing on how well the driver code is written. You speak like someone who has never written a line of code. Talk about things you actually know something about. same goes fo Maxxedout. The capabilities of the coders who are writing against the Windows API, and therefor the quality of the code they produce IS NOT in any way affected by the Quality of the Code on the other side of the API. The quality of the code produced by the Driver writers is affected ONLY by thier personal skills, and the expediencies they MAY forced to accept in order to meet the dealines of the company they work for. This applies also to any code developed for Linux drivers (which incidentally, is why so many Proprietary Linux drivers are crap) Your argument, that because Windows code is crap (and no one has ever been able to show that it actually is), does not correlate with Driver code for Windows being crap. Your assumptions are wrong, therefore you conclusions are wrong. |
| Sander_Marechal Jun 27, 2009 9:10 AM EDT |
Quoting:(and no one has ever been able to show that it actually is) Yes, they have. Just read the reviews on the quality of the leaked Win2K source :-) |
| r_a_trip Jun 27, 2009 11:08 AM EDT |
Valid arguments? How do you keep a Windows infected Linux kernel clen from virusses and other malware? |
| gus3 Jun 27, 2009 12:28 PM EDT |
From the article:Quoting:Well, we need to ask ourselves what makes Linux secure? Is it just the fact that that we use a different API than Windows?The fact that he's asking that question, and not rhetorically, means he has zero clue about the role of a privilege mechanism in system security. Privileges in desktop Windows were non-existent at first, and the applications were written to reflect the sad state of affairs. Later versions got a privilege mechanism shoe-horned in, too little too late. The quality of the privilege mechanism is immaterial; the presence and use of the mechanism is what matters. There can be some brain-dead cases in the mechanism that improperly allow actions that should be denied, but that can be fixed without requiring a major rewrite over many code blocks. Unix, Linux, and even VMS had it from their starts. Microsoft preferred to sideline privileges, in favor of "just make it work"; they are still dealing with the consequences of that horrible decision. |
| r_a_trip Jun 27, 2009 2:05 PM EDT |
Microsoft preferred to sideline privileges, in favor of "just make it work"; they are still dealing with the consequences of that horrible decision. In other words, LUK needs to emulate the sloppy privilege handling from Windows too. At least if they want the benefit of running unaltered Win32 binaries. They better have well shielded containers for every single Win32 App. I wouldn't mind to have one LUK enabled distro as a proof of concept, to see if it works. I'd rather not have it as a standard desktop kernel. If I need to do Windows, I'd rather have a killable Wine or Windows in a VM. A drunken kernel just goes a little too far for me. |
| azerthoth Jun 27, 2009 2:39 PM EDT |
There is no reason or even any possible excuse for introducing the security nightmare that is a windows implentation into the Linux Kernel. If you want to run the apps then installing wine and configuring file extension is whole seconds worth of work, and keeps the security issues where they need to be kept. Isolated from the core OS. |
| caitlyn Jun 27, 2009 2:48 PM EDT |
I'm with azerthoth on this one. Well said. |
| tracyanne Jun 27, 2009 5:54 PM EDT |
Quoting: In other words, LUK needs to emulate the sloppy privilege handling from Windows too. Once again, an example of wrong assumptions, leading to wrong conclusions. LUK does not need to do anything of the sort. To begin with read the d@mn article. |
| gus3 Jun 27, 2009 6:25 PM EDT |
Quoting:To begin with read the d@mn article.I did. I started reading it with only a slightly jaded view, but willing to give the guy a chance. When I read what I quoted above, my view became totally jaded. I kept reading, hoping to find out he was asking the questions "merely" rhetorically, rather than looking for an answer. My hope was in vain. I do agree that wrong assumptions lead to wrong conclusions; I contend that the wrong assumptions are on the part of the article's author. Going back to the quote above: Quoting:Well, we need to ask ourselves what makes Linux secure? Is it just the fact that that we use a different API than Windows?The API has nothing to do with it. For example, both systems aim toward POSIX compliance, to varying degrees, and even the POSIX definition itself has been known to have some security deficiencies. Still, a strict POSIX program (one which uses only POSIX calls) can be reasonably secure on one platform, and dangerous to run on another, due to differences in the POSIX implementations. One of the lessons of the semi-weekly SANS NewsBites is that security must be designed into the original specs, not added as an afterthought. Put the mechanisms in place, and mandate their use. If a call is accidentally omitted during coding, it should be trivial to add it as a bugfix. Microsoft did not follow this design philosophy, and now the world pays monthly subscriptions to Symantec and McAfee to cover Microsoft's kiester. (And they don't, they only give their subscribers a false sense of security. Sony rootkit, anyone?) |
| tracyanne Jun 27, 2009 6:48 PM EDT |
Well gus, unless you are also r_a_trip I did not direct that comment at you.Quoting:The API has nothing to do with it. Exactly. Quoting:security must be designed into the original specs, not added as an afterthought. And it is my understanding that this is what is done in Linux, and not Windows. HOWEVER, and this is the point that way too many people (probably non technical, based on their comments) are missing. WE ARE NOT TALKING ABOUT MICROSOFT code, we are talking about2 things, 1) code, written for Linux by Linux developers, that provides an API interface to Drivers written for Windows, and 2) Those Drivers, which are written by the hardware manufacturers, to function against a Windows API. That is quite different from adding Windows code to Linux. we are talking about something that WINE already does, but hopefully more securely. I don't know how anyone else feels about this (although I can guess, based on some of the comments), but I would like to be educated on this subject by some people who know a bunch more about the subject. |
| tracyanne Jun 27, 2009 7:00 PM EDT |
Quoting: Yes, they have. Just read the reviews on the quality of the leaked Win2K source :-) Fair enough, I've never seen Microsoft's code, and I have no intention of doing so, so I'll have to take those comments at face value. |
| azerthoth Jun 27, 2009 7:14 PM EDT |
TA, while we are not talking MS code, we are talking about the exact same system calls, except in this case, unlike wine they are not isolated but given root level access. This isnt the first story that has been published about this topic and there is more information to be had than what the author gave us. This is letting system level calls using the same API's that hackers already use into the Linux kernel. There is no level of isolation when your at that level that could remotely be considered safe. As I said before, if you want the funtionality, its already there for you in wine. There is no excuse, no possible reason, that any one should breach isolation. As to windows supposed POSIX compatibility, you do realize that it was implented because the US government IT contracts specify that POSIX compatability must be there. Last I checked to even get that much out of it took patching as it does not come OOB. What you do get out of that patch, is just the bare minimum that they can get by with and meet the letter of contractual necessity. |
| phsolide Jun 27, 2009 7:46 PM EDT |
The Win32, and as near as I can tell, the Native NT system call interface, is very poorly designed. Mix it in with the linux kernel, and you'll get a malware-plagued, poorly performing piece of junk. Just say NO to LUK. http://portal.acm.org/citation.cfm?id=1255421.1255422&coll=G... At the time Windows NT was "POSIX Certified" (by the Coast Guard, as I recall) there was some rancor about the wink-and-a-nudge certification process. That is, a lot of people called "foul" on it. Beyond calling foul, quite a few waivers had to be issued. The only one I recall for sure was about symbolic and/or hard links, but I've never figured out how Windows NT can emulate the fork/exec system call, while it's pretty obvious that fork/exec can emulate the CreateProcess Win32 call. Who knows what evil lies in the heart of NT when it comes to creating a new process? |
| tracyanne Jun 27, 2009 8:11 PM EDT |
Quoting:There is no level of isolation when your at that level that could remotely be considered safe. Why? Please explain. Quoting:This is letting system level calls using the same API's that hackers already use into the Linux kernel. That is the Linux kernel is secure ONLY because so few people use it argument. Which I do not buy. Quoting:As I said before, if you want the funtionality, its already there for you in wine. No it's not. I can no more use a device, for which there is no functional Linux Driver, with WINE than I can without WINE, on a Linux box. WINE gives me no functionality that is not already in Linux, it merely translates Windows API calls to Linux API calls, the actual code is actually owned by root. However, that doesn't stop Viruses from running, on Linux, as the entry point to those API calls is in userspace in the C:WINDOWSSYSTEM32 directory.... exactly where they are on a Windows OS Quoting:There is no excuse, no possible reason, that any one should breach isolation. Where, specifically did anyone suggest breaching isolation? It is my understanding that the same isolation that makes Linux (the kernel) what it is will remain the same. |
| gus3 Jun 27, 2009 8:18 PM EDT |
Quoting:Well gus, unless you are also r_a_trip I did not direct that comment at you.Yeah, I know, but r_a_trip was agreeing with what I had said, and amplifying it. I think you touch on the point with your comment: Quoting:That is quite different from adding Windows code to Linux. we are talking about something that WINE already does, but hopefully more securely.The "more securely" is the killer. If an application is written to expect certain insecure behavior, would it break if suddenly Microsoft were to implement proper security in Windows? IIRC, that was a big complaint with Win2K. XP tried to mitigate it with their "privileged operation, continue?" dialog, and Vista is no better. Yes, I'm a cynic. I can understand why FreeBSD would want to add the Linux entry point to their kernel, but adding a Windows API to the Linux kernel strains credulity. |
| tracyanne Jun 27, 2009 8:37 PM EDT |
Quoting:Yes, I'm a cynic. I can understand why FreeBSD would want to add the Linux entry point to their kernel, but adding a Windows API to the Linux kernel strains credulity. But we already have a Windows API. Only not a secure one. It's called WINE. It's not insecure because the code written by the WINE coder is faulty, or even because the API they are rewriting is badly designed, but because the Windows API, as implemented in WINE... and only because it needs to act exactly like Windows, expects that certain file extensions like exe and bin and bat etc must be executed. If one is to do this right surely one would create some means of making it work the Linux way, for example, NDISWrapper extracts the binary blob from the Windows driver, rather than executing the installer, the blob is then inserted into the appropriate location in the Linux directory tree, and is owned by root, so cannot be modified from user space. So....... If one is making Windows API calls available to the Linux kernel, it stands to reason that one would either write code that works like NDISWrapper, or in some other way works around the Windows "you need to be root for me to function properly bug". So far the majority of comments I've read arguing against the idea have been driven by emotion, the reasons given seem to boil down to "the Linux Developers can't make this work in a proper Linux way", and yet I've not seen any actual technical description of why it's not possible. |
| azerthoth Jun 27, 2009 8:37 PM EDT |
Quoting:That is the Linux kernel is secure ONLY because so few people use it argument. Which I do not buy.No, its the windows API is insecure and there is no effective means of correcting that issue argument. This is very simple, if wine at user level will allow you to pick up a windows virus, and I have had exactly that happen, the putting wine in the kernel is unconditionally insane. This is not saying its secure because no one uses it, this is intentionally unsecuring it by adding fishnet stockings and calling it armor plating. Quoting:Where, specifically did anyone suggest breaching isolation? It is my understanding that the same isolation that makes Linux (the kernel) what it is will remain the same. I suggest more research then, this is a kernel level implementation. This gives it full 100% access to your entire system via the same system calls that hackers already know and use. That by my definition is un securing your system. If you want this kind of functionality, need for virus hunters, immeadiate and uncontrollable permission elevation ... they already make an OS for that and it can not be secured. Your saying that the answer is bolt it onto something already secure will somehow magically make it all better. Hogwash, the only thing it will do is bring the same innate failings to a second OS. Think on this, if windows or its kernel(s) could be secured, dont you think someone would have figured out how by now and done so? |
| Sander_Marechal Jun 27, 2009 8:48 PM EDT |
Quoting:I've never seen Microsoft's code, and I have no intention of doing so And that's probably for the best. As a professional programmer, only bad things can come from reading the leaked Win2K source code. |
| tracyanne Jun 27, 2009 8:48 PM EDT |
Quoting:they already make an OS for that and it can not be secured. To begin with Windows can be secured. It just takes more work to get it right. Quoting:No, its the windows API is insecure and there is no effective means of correcting that issue argument. The Windows API is not insecure, any more than the Linux API is insecure. Run as root on Linux and you stand exactly the same chance of being pwned as you do on Windows... maybe a slightly higher chance, as Windows has the dubious protection of Anti Virus software. You are confusing issues here. Windows the OS is insecure because of marketing decisions that have to do with how you install and use software, NOT because of any basic issues with the API. or it's design. It is exactly for this reason that WINE is insecure (the need for WINE to emulate Windows usage). |
| azerthoth Jun 27, 2009 9:03 PM EDT |
And yet you argue to put it in the kernel ... |
| tracyanne Jun 27, 2009 9:36 PM EDT |
@ azerthoth I'm arguing nothing at the moment, and certainly not that one adds anything to the Linux kernel, other people are saying that it's necessary to add the Windows API to the Linux kernel. I'm just trying to get past the emotion to the technical issues. And trying to explain why the Windows OS (note I didn't say API) is insecure, and why the Windows API is not necessarily insecure. 1) The WINE code written by the WINE developers (which re-implements a significant portion of the Windows API) is as secure as any other piece of Linux code. 2) Yet it's possible to run viruses on Linux using WINE. 3) Applications running on Windows require root (Administrator) level access so they will function properly. the reason for 2) is 3) not because 1) is untrue. Because Microsoft have chosen the expediency of making it "easy" for users to install and execute applications, they have been forced to implement additional expediencies, like including vast amounts of code that could, and should be left out of the kernel, in the kernel, causing among other things bloat. The cause of the insecurity is not the inclusion of the code, but the expediency of how Windows expects applications to work, to make life "easy" for users, in fact to make as little change and possible (from the user perspective) from MS DOS, Window 1,2 3, 95 ,98 ME to the so NT kernel based Systems like XP Vista and 7. In other words Windows insecurity is a Legacy thing.. the legacy of MSDOS, not something inherent in the API itself. Given that WINE is inherently secure, even though the windows user space that relies on it is not, I think that it is safe to assume that it would be possible to create a subsystem that handles Windows drivers in the same safe and sane way that Linux drivers are currently handled, but with a translator like WINE supplying the necessary glue. I'd love to hear some thoughts from a WINE developer or a Kernel developer or both. |
| Sander_Marechal Jun 28, 2009 7:02 AM EDT |
Quoting:like including vast amounts of code that could, and should be left out of the kernel, in the kernel IIRC, in Windows, the GDI was moved into the kernel to make it faster. Running in kernel space means less context switches and thus faster execution. |
| Scott_Ruecker Jun 28, 2009 11:31 AM EDT |
Are we ok in here? We have some heated exchanges going on and I wanted to be sure that if we feel the need to tell each other off that we are doing through PM please. This thread reads like a nice little argument..which is not cool for our readers or acceptable to me. After a certain point its better to just agree to disagree and move on in the forums. You can throw daggers at each other all you want in PM. Kapeesh? |
| TxtEdMacs Jun 28, 2009 1:02 PM EDT |
But Scott! I was only reading ... never got a comment in. So what's the problem? YBT PS I didn't even unlock the weapons cabinet. |
| azerthoth Jun 28, 2009 1:48 PM EDT |
We're cool, just a pleasant disagreement as far as I'm concerned. |
| Bob_Robertson Jun 28, 2009 3:26 PM EDT |
> I was only reading ... never got a comment in. So what's the problem? Yeah, what he said! |
| r_a_trip Jun 28, 2009 5:09 PM EDT |
Because Microsoft have chosen the expediency of making it "easy" for users to install and execute applications, they have been forced to implement additional expediencies, like including vast amounts of code that could, and should be left out of the kernel, in the kernel, causing among other things bloat. The cause of the insecurity is not the inclusion of the code, but the expediency of how Windows expects applications to work, to make life "easy" for users, in fact to make as little change and possible (from the user perspective) from MS DOS, Window 1,2 3, 95 ,98 ME to the so NT kernel based Systems like XP Vista and 7. In other words Windows insecurity is a Legacy thing.. the legacy of MSDOS, not something inherent in the API itself. Well, TA, you already give answer to your own question. So why ask us about it? The problem is not Cutlers NT. This system is very secure and advanced. The trouble with Windows is Microsoft. They have let the inherent security in NT lie unused for years. The consequence is a userland that has no inkling of security anymore. It's a very ironic tragedy. So yes, there is no inherent design reason why an NT based system should be insecure, but... MS borked up the policies and that has led to an entire software base assuming NT to behave promiscuous. So implementing a system that allows the Windows application base to run unaltered and work, will be a formidable task if they want to keep the security policies of *Nix in place. I'm a cynic. I expect it will be easier for Insigma Co., Ltd to just emulate the behaviour of Win32 warts and all. So yes, have a separate project and see if it is viable security wise. If so, congratulations Insigma. If not, have a speedy death LUK. By the way, having WDM in the Linux kernel is a very sharp two edged sword. On the one hand you get instant compatibility with all devices with a Windows driver. On the other, the incentive to write Linux native drivers, with open GPLv2 code instantly drops below zero. Having a WDM interface in Linux will probably condemn us to run every piece of hardware with a closed binary blob. |
| tracyanne Jun 28, 2009 7:10 PM EDT |
Quoting:On the one hand you get instant compatibility with all devices with a Windows driver. On the other, the incentive to write Linux native drivers, with open GPLv2 code instantly drops below zero. I agree. |
| tuxchick Jun 28, 2009 7:29 PM EDT |
Quoting: the incentive to write Linux native drivers, with open GPLv2 code instantly drops below zero. Y'all might recall the 'give up a little freedom now for more freedom later' movement of a few years ago, in which it was advocated that dumping all kinds of non-free stuff into Linux was a good thing to do. Because it would then be irresistible to Windows users who would then dump 'doze and migrate in droves to Linux. And then they would all buy all of this proprietary stuff for Linux, and then at the magic tipping point they would arise en masse and demand that all of this closed stuff be opened up. And because of their mass purchasing clout, vendors would agree. (I am not making this up, people were saying this with straight faces.) So let's run through our checklist: 1. Nvidia-- nope, and no hope 2. Adobe Flash-- nope, though there are rumors of opening the client 3. USB 2.0 audio recording interfaces-- not one. Nada. There are a few actual standards-compliant 1.1 devices that work great on Linux, but the industry lost its collective mind with 2.0. Funny how they don't mind writing unnecessary special drivers for Windows.... 4. Firewire audio recording interfaces-- it is to laugh. A very few vendors are sort of Linux supportive. The FFADO project does all the work, and that still isn't good enough 5. Moronic camera interfaces that still require Windows. Fortunately, using a Flash card reader gets around this. Again, they make unnecessary extra work for themselves for Windows, and that's OK. 6. All the favorite Windows softwares: Quicken, Photoshop, games. Are there any vendor-supported WINE implementations? Nope. Are there Linux ports of any kind, open or closed? Nope. 7. Fingerprint readers? Multicard readers? Webcams? Virtually no effort by hardware vendors, most progress is due to heroic FOSS coders The Linux Driver Project, led by Greg k-H, deserves much of the credit for progress in hardware support in Linux, and the development and maintenance of Free drivers http://www.kroah.com/log/linux/linux_driver_project_status-2... The Linux Wireless project deserves most of the credit for the substantial progress made in wireless support. They completely overhauled the wireless subsystem in Linux, cleaning it up and making it coherent, and they have built good relationships with hardware vendors. As near as I can tell, all progress has come from tireless behind-the-scenes work, and the 'give up a little freedom now for more freedom later' strategy has not produced so much as a line of code. |
| Bob_Robertson Jun 28, 2009 7:39 PM EDT |
> and the 'give up a little freedom now for more freedom later' strategy has not produced so much as a line of code. That same thing has been obvious to me as well. Compromise freedom, and freedom has already lost. This is not a "political" comment just because it relates to life in general. It's a statement of reality in terms of F/OSS. It's times like this when I wish I were a better programmer, so I could contribute more than just bug reports and the occasional bit of funds. |
| r_a_trip Jun 29, 2009 3:23 AM EDT |
Since the LUK project exists and they will most probably produce some LiNTux system with WDM support... Can we use the WDM subsystem to our advantage? How legal would it be to add a "sniffer" to the LUK WDM subsystem to see how the binary blob communicates with the hardware? I imagine that cleanroom (if sniffers are legal) reverse engineering from the actual communication between driver and device could make stuff easier. |
| Sander_Marechal Jun 29, 2009 3:41 AM EDT |
Quoting:It's times like this when I wish I were a better programmer, so I could contribute more than just bug reports and the occasional bit of funds. Start out with a couple of Python tutorials. It's a great language and easy to learn. Quoting:Can we use the WDM subsystem to our advantage? To what end? WDM is deprecated so it's the older drivers that use this. Pretty much all that hardware is supported in the Linux kernel already. Greg HK's driver team is well stocked with programmers but suffers from a lack of work because pretty much everything is already supported. For anything else (i.e. things that don't belong in the kernel) you don't need to sniff WDM. You can already sniff USB traffic for example. I mean seriously, what hardware isn't supported in Linux these days? Perhaps the odd USB wifi stick, but even those are being solved. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!