One that implements the published specification for the platform/language? Just like MS got burnt trying to knock off java with J++ if you make a C# like languages that is broken from the standard in fundamental ways they'll come after you.
No - they can't. They have not put any clause in the licensing term for neither C# or core libraries prohibiting you from extending those. Sun did that with Java. Microsoft put the equivalent of C# delegates and P/Invoke into their Java implementation. Especially the latter riled Sun, as it allowed MS to integrate Java much more efficiently on Windows than Sun could do on other platforms. Sun sued and won and MS walked away from Java and created J++ but eventually went all-in on C#
This time around you can add anything you want. There is no non-free, licensed test suite you'll have to pass and there's limitation on how you can extend.
As I read it, it was not an issue with the developed software (although there may be issues there as well), but rather an issue with the *setup* of the machines. It was not the developers who failed (passwords not hardcoded) but rather the admins deploying the machines were braindead and the auditors obviously clueless. For something like this they shold have used an randomly generated password or simply shut themselves out of the system (which is possible on Windows).
For some time now, Mark Russinovich at Microsoft has been talking about just how bad the Windows kernel was/is in his blog.
I think you are confused. It was not Mark Russinovich, but rather Linus Torvalds, and he was talking about the Linux kernel, not the Windows kernel.
"I mean, sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse."
Microsoft has granted patents, to anyone who implements a.NET runtime. The grants were part of the standardization of.NET CLR and core libraries.
It is a misunderstanding that it is bound to Microsofts own implementation. Those grants has always extended to Mono. The anti-Mono and anti-Microsoft fanatics started a FUD campaign based on speculation that MS could just sue anyway, and the mere cost of defending against MS would force Mono underground. It was a response to that FUD campaign that MS also issued the community promise.
The patent grants also are not tied to a full-stack implementation like Java/Oracle. The fact is, the patent protection when using CLR is far more transparent and effective, compared to Oracle/JVM.
- e.g. XAML syntax is unnecessary verbose, and QML is much better in that regard. But most of those are surface issues. The core design - the notion of element tree, layout engine, layout and render transforms, data binding, styles, triggers etc - is solid, very powerful, and very flexible.
The beauty of WPF and (especially) XAML is that they really are 2 very different technologies. WPF - like many GUI frameworks - describes an UI through an object graph. You can "new" up the controls yourself, wire the event handlers and achieve the exact same result as describing it through XAML. Which also means that you can dynamically change the graph through code.
XAML on the other hand is not in any way specific to WPF. It is simply a way to describe an object graph. Only, XAML can describe very, very complex object graphs with wired event handlers etc. XAML is also used to describe workflows in Workflow Foundation. And anyone can use the format to describe object graphs of any other type. XAML uses a convention for mapping XML namespaces to CLR namespaces. That is a really, really cool.
1. The ridiculous FAT long-filename patent 2. The subpixel rendering patent (despite prior art being shown) 3. Outright patent-troll behavior: Refusing to disclose a stack of patents its using to extort for-profit Linux distributors behind closed doors.
Thanks.
Which of the above illustrate Microsofts visceral hatred of open source?
(For the record: I believe that software patents should be abolished and I do not condone Microsofts patent litigation)
Problem is let's say there is a bug that is causing your web app to constantly run out of threads or restart?
Who do you call for support? Let's say you think it is mono causing it? WIth VS.NET on Windows you see the bug is not there.
Isn't that a concern with open source in general? That argument could be used against all open source projects where commercial support is not available. Yet, many open source projects thrives despite of this.
.NET is great but not if you make calls that emulate Windows.
But Mono does not make calls that "emulate Windows". In general the call upon native and/or open source libraries. Certainly you'd be hard pressed to come up with any examples of this behavior in the Mono server stack.
Winforms is an example too which uses dcom/com underneath. It would make more sense to use GTK calls if it is a Linux app.
But you are wrong about that. Winforms is definitively NOT based on COM (much less DCOM).Winforms is a thin wrapper around Win32 APIs. When you create a text box in Winforms, you'll get an actual native Windows textbox.
You may be confused by the fact that Winforms also allow ActiveX controls to be used. When you use that capability you will be using COM (not DCOM), as ActiveX controls are implemented using COM. Interestingly, the part of COM that makes this possible is remarkably similar to the object model of Gnome, almost binary compatible. Basic COM is a binary standard which can be implemented on any platform out there.
Microsoft has many times expressed its visceral hatred of open source. It is not to be trusted, not ten years ago, not five years not, not today, not ever.
BS again. Microsoft has NEVER expressed visceral hatred of open source. Ballmer has compared one open source license - GPL - with cancer, because of it's viral nature. The intentionally viral nature.
Ballmer is not at the helm any more. But even he never expressed hatred at open source, as you claim. You could construe his comments about GPL as hatred against that particular license type. And indeed, Microsoft has always opted for other OSI approved licenses when they had the choice.
But if you have any other sources for your made-up claim - say other MS top executives, maybe even present ones - then please feel free to post them.
Can you run a.NET application that currently resides on a Windows-based web server on a Linux-based shared hosting server using Mono?
In general: Yes. Need more context about the application to give a definitive answer, e.g. if it uses Windows specific infrastructure such as AD, Workflow Foundation.
Quite simply, a patent "promise" is not the same thing as a license. You see, even if they're bared by Laches, they can still drag you through the courts and you've got to prove they're barred by making the promise. If you had a license...you could make a single motion at the first hearing or in the pretrial motions to dismiss because of being licensed if they sought to sue you.
Having this crap in there means Mono's toast without a real license to any valid patents, combined with a covenant to license all tech as it becomes apparent, that ends up in this common core of stuff. Otherwise, you're INSANE for using it- because you can and most probably WILL be sued over it.
No - it is actually stronger (look up promissory estoppel). But leave that aside, because the patents have also already been granted.
The *promise* was issued because fanatics cried foul at the patent grant, arguing that Microsoft with it vast army of lawyers could just sue any OS project out of existence, patent grant or not. Hence, Microsoft issued the promise, all but ensuring that such a case would be outright dismissed since you've acted in good faith on a promise. The promise in that case is actually one of the strongest contract forms imaginable, as it is one-sided: you do not have to sign anything to be covered.
The PATENTS.TXT (https://github.com/dotnet/coreclr/blob/master/PATENTS.TXT) also does not claim anything like that. It merely says that if *you* bring a patent lawsuit against *anyone* for using the *covered code*, any patent grant is revoked and the promise is revoked.
well considering their 'mit license' is invalidated because of the wording saying you can't use without their engine or code... it kind of is a trap. Just a bad one.
I suppose you have a source for that restriction?
Can you please help me, because when I view the LICENSE.TXT (https://github.com/dotnet/coreclr/blob/master/LICENSE.TXT) I cannot find anything like that?
not all open source code is bulletproof but microsoft has proven their code is swiss cheese. so why would anyone willingly use a MS product that for something that needs to be secure? when people are shooting at you, do you want to be wearing body armor or cheese?
Microsoft has (discounting the time before the nimda and code red disasters and the security push) consistently beat the industry average on fewer vulnerabilities for comparable products.
Specifically the later versions of internet information services (IIS) - the webserver that would be roughly comparable to Apache httpd with PHP, Ruby or Java - have fared extremely well in comparison: IIS 7 has had 8 vulns discovered in it's entire lifetime, while IIS 8 still has a clean sheet.
Not a troll but a genuine question - what's stunted about ASP.NET MVC?
ASP.NET MVC along with the other "web MVC" have really little to do with the real MVC as in the original smalltalk MVC described by Trygve Reenskaugs MVC. Web MVCs are bastardizations of the original concept, often only riding the name for recognition. I blame Struts and RoR for starting this trend.
I believe grand parent was referring to the original MVC which was a way to design interactive, event-driven GUIs. The original MVC was a recursive concept: The view could itself be a "tool" that in turn followed the MVC pattern. See http://heim.ifi.uio.no/~trygve...
As far as "web MVCs" goes, ASP.NET MVC is a really good one. But real MVC it is not. But that's a lost cause. An entire generation of developers have grown up believing that RoR and Struts were examples of MVC. In actuality, the designers og Struts and RoR grossly misunderstood the concept.
An acronym (pronounced AK-ruh-nihm, from Greek acro- in the sense of extreme or tip and onyma or name) is an abbreviation of several words in such a way that the abbreviation itself forms a pronounceable word....
Abbreviations that use the first letter of each word in a phrase are sometimes referred to as initialisms.
LEGO is an abbreviation (though not an initialism) of Leg godt, danish for "play well" - or perhaps more like "have fun (playing)"
Windows 64 bit has an absolute kernel-driver signing requirement. Windows 32 bit has for compatibility reasons a more "soft" requirement - that's where you'll get the warning box instead. Reason: Windows is still compatible with drivers from the XP/2000 era and will still load those. At that time nobody had considered driver signing, and the vendor may now be defunct. An absolute requirement would render devices unusable. The signing requirement was in force when 64 bit was introduced, and MS reckons that all drivers for 64 bit must have been signed, thus the signing requirement is non-negotiable on x64.
You *can* load non-signed drivers by attaching a kernel mode debugger. This is to facilitate development of drivers without a long signing roundtrip.
Oh, that promise is legally binding? I don't think so. And CEOs change.
Yes, it is binding. Legal estoppel is the term. It is used when you act in good faith on a promise. It is in fact one of the strongest contract types you can imagine, because it is considered a one-sided contract that you do not even have to accept (like you do with e.g. license terms). If you can show that you acted on the promise, a patent case against you will be dismissed.
There is a big difference between mitigation and prevention. Secure boot is a prevention mechanism: It prevents the system from booting if the boot chain has been tampered with. You can boot from external media such as an USB key and salvage data, but the system will not boot by itself.
What you are suggesting is a mitigation mechanism. As I wrote above, code running in a security context cannot protect effectively against code running in the same security context. It can only try to *mitigate* such attacks, but mitigation are speed bumps compared to prevention, which are road blocks
Windows certainly has it's share of mitigation mechanisms. First there are all the anti-exploit mitigation mechanisms which are designed to thwart an exploit from getting foothold, even when a vulnerability exists in 3rd party code. These are stack overflow/underflow prevention, DEP/ASLR, heap encryption/checksumming, safe structured exception handling (SafeSEH) etc etc.
Then there are the built-in running mechanisms such as ELAM, patchguard etc. Patchguard will checksum central kernel tables, and if malware tries to gain foothold in the (running) system by patching into e.g. the page table, patchguard will react to the checksum discrepancy and halt the system.
Secure Boot prevents a compromised system from ever starting. Your suggested mechanism is already there - Windows will *try* to prevent unauthorized patching. But that is mitigation and far less effective than prevention.
To be loaded as a driver, the driver must be signed.
Correct me if I'm wrong but to be loaded as a driver, the driver must simply start a UAC prompt and then let the user click yes, and then yes again to the unsigned driver dialogue.
If you rely on a user not clicking yes then you have a very big gaping security hole.
Consider yourself corrected. UAC has nothing to do with drivers. Kernel mode drivers under Windows *must* be signed by a recognized authority. If a driver is tampered with, the kernel will refuse to load it. If a driver is unsigned, the kernel will refuse to load it. On x64 systems, the user can *not* opt to override this warning.
UAC prompts has to do with integrity levels - which is a way to divide processes, files, registry keys etc into "trust zones" and isolate processes running with lower trust (lower integrity level) from accessing resources having higher trust (higher integrity level). Even when your account has admin rights, the admin rights are stripped from your token at login, i.e. you are running as a standard user without any special privileges. Windows saves the "full" token, but it is not active. When you start a process based on an image that declares in its manifest that it must run as admin, Windows will issue the UAC prompt on a separate secured desktop. If you accept the elevation (that your admin privileges can be used for the process), Windows starts the new process with the "full" token - and with high integrity level.
In Windows, it's not unheard of that a piece of malware with sufficient access interjects itself where the next boot will be picked up before the OS has a chance to set up it's own protection. Of course my complaint is that this vector would have easily been sidestepped without a huge firmware mess. If the OS set up access to that area as very very very very special, requiring signed code within the OS to modify that section of the platform, then the problem would have been solved..
Sorry, but no. If you knew anything about threat modelling and OS design, you would know that code running at a trust level cannot protect against other code running with the same trust. The x86 architecture does have 4 levels, but for a number of reasons (mostly portability) practically no OSes use more than 2 levels (rings): protected/kernel and user mode.
What you are proposing is using a 3rd ring - something more privileged than kernel mode. This would constitute a major architectural redesign and would trash portability/compatibility with other architectures.
The fact is that UEFI Secure Boot is a very effective mechanism for blocking boot sector infections. As Windows has grown ever more resilient against permanent infections (app/driver signing, checksum tables, strong named assembly cache etc) malware authors were forced into infecting at an earlier stage of the boot process, if they wanted to take up permanent residence.
The OS kernel mode MUST have the capability to write all sectors of the disk. It can effectively block usermode apps from writing such sectors, but if kernel mode driver contains a vuln, rogue code can bypass any security mechanisms enforced by the kernel. It can just jump to the address efter the security check or control the IO itself.
Bootkits exists for Wndows. It was a real threat. A few unscrupolous individuals (lookng at you Garett) chose to instigate a FUD campaign, deliberately misrepresenting facts and knowlingly failing to correct misunderstandings when they advanced their case.
Consider the situation where an attacker has actually compromised a server key - either it was leaked, brute forces, a vulnerability exploited. It happens and big parts of the certificate system such as revocation lists, OCSP, validity periods etc are concerned with this. Or consider the situation where a vulnerability allows the attacker to *fake* the fact that he has the private key.
Many systems are set up to warn or outright block if they are not able to check revocation for a certain time period. Seems to me, that with this extension an attacker can use the time from when the key is actually compromised until the breach is discovered/reported and gain permanent foothold instead of a temporary one.
This capability seems too dangerous to even have in the protocol - even if one can argue that it is protected. It broadens the attack surface in a significant way.
Of course, all security is a balance between risks, consequences and cost. Maybe, if this capability significantly lowers some other risk, it could outweigh the risk incurred by the increased attack surface. But color me skeptical.
Slashdot Mirror
One that implements the published specification for the platform/language? Just like MS got burnt trying to knock off java with J++ if you make a C# like languages that is broken from the standard in fundamental ways they'll come after you.
No - they can't. They have not put any clause in the licensing term for neither C# or core libraries prohibiting you from extending those. Sun did that with Java. Microsoft put the equivalent of C# delegates and P/Invoke into their Java implementation. Especially the latter riled Sun, as it allowed MS to integrate Java much more efficiently on Windows than Sun could do on other platforms. Sun sued and won and MS walked away from Java and created J++ but eventually went all-in on C#
This time around you can add anything you want. There is no non-free, licensed test suite you'll have to pass and there's limitation on how you can extend.
As I read it, it was not an issue with the developed software (although there may be issues there as well), but rather an issue with the *setup* of the machines. It was not the developers who failed (passwords not hardcoded) but rather the admins deploying the machines were braindead and the auditors obviously clueless. For something like this they shold have used an randomly generated password or simply shut themselves out of the system (which is possible on Windows).
For some time now, Mark Russinovich at Microsoft has been talking about just how bad the Windows kernel was/is in his blog.
I think you are confused. It was not Mark Russinovich, but rather Linus Torvalds, and he was talking about the Linux kernel, not the Windows kernel.
"I mean, sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse."
Glad I could help.
Microsoft has not contributed any useful code to the Linux kernel. Their "contribution" was drivers so that Linux could work on their hypervisor.
I find that immensely useful.
When Intel contributes drivers for graphics chips, it is *also* so that Linux can work on their hardware.
Maybe you should take a clue from Linus Torvalds. (hint: It's about scratching your own itch)
Microsoft has granted patents, to anyone who implements a .NET runtime. The grants were part of the standardization of .NET CLR and core libraries.
It is a misunderstanding that it is bound to Microsofts own implementation. Those grants has always extended to Mono. The anti-Mono and anti-Microsoft fanatics started a FUD campaign based on speculation that MS could just sue anyway, and the mere cost of defending against MS would force Mono underground. It was a response to that FUD campaign that MS also issued the community promise.
The patent grants also are not tied to a full-stack implementation like Java/Oracle. The fact is, the patent protection when using CLR is far more transparent and effective, compared to Oracle/JVM.
- e.g. XAML syntax is unnecessary verbose, and QML is much better in that regard. But most of those are surface issues. The core design - the notion of element tree, layout engine, layout and render transforms, data binding, styles, triggers etc - is solid, very powerful, and very flexible.
The beauty of WPF and (especially) XAML is that they really are 2 very different technologies. WPF - like many GUI frameworks - describes an UI through an object graph. You can "new" up the controls yourself, wire the event handlers and achieve the exact same result as describing it through XAML. Which also means that you can dynamically change the graph through code.
XAML on the other hand is not in any way specific to WPF. It is simply a way to describe an object graph. Only, XAML can describe very, very complex object graphs with wired event handlers etc. XAML is also used to describe workflows in Workflow Foundation. And anyone can use the format to describe object graphs of any other type. XAML uses a convention for mapping XML namespaces to CLR namespaces. That is a really, really cool.
Cases in point:
1. The ridiculous FAT long-filename patent
2. The subpixel rendering patent (despite prior art being shown)
3. Outright patent-troll behavior: Refusing to disclose a stack of patents its using to extort for-profit Linux distributors behind closed doors.
Thanks.
Which of the above illustrate Microsofts visceral hatred of open source?
(For the record: I believe that software patents should be abolished and I do not condone Microsofts patent litigation)
Problem is let's say there is a bug that is causing your web app to constantly run out of threads or restart?
Who do you call for support? Let's say you think it is mono causing it? WIth VS.NET on Windows you see the bug is not there.
Isn't that a concern with open source in general? That argument could be used against all open source projects where commercial support is not available. Yet, many open source projects thrives despite of this.
.NET is great but not if you make calls that emulate Windows.
But Mono does not make calls that "emulate Windows". In general the call upon native and/or open source libraries. Certainly you'd be hard pressed to come up with any examples of this behavior in the Mono server stack.
Winforms is an example too which uses dcom/com underneath. It would make more sense to use GTK calls if it is a Linux app.
But you are wrong about that. Winforms is definitively NOT based on COM (much less DCOM).Winforms is a thin wrapper around Win32 APIs. When you create a text box in Winforms, you'll get an actual native Windows textbox.
You may be confused by the fact that Winforms also allow ActiveX controls to be used. When you use that capability you will be using COM (not DCOM), as ActiveX controls are implemented using COM. Interestingly, the part of COM that makes this possible is remarkably similar to the object model of Gnome, almost binary compatible. Basic COM is a binary standard which can be implemented on any platform out there.
It would take a delusional lunatic not to know the long history of attacks against commercial and open source competitors.
Then you should have no problems finding a few examples that illustrates Microsofts visceral hatred of open source (your words).
... long history of attacks against commercial and open source competitors
Fear!
Microsoft isn't trustworthy,
Uncertainty!
Why risk future woes when you have no need to?
Doubt!
As I suspected: Nothing but FUD. But pretty textbook FUD, that much I have to give you credit for.
Microsoft has many times expressed its visceral hatred of open source. It is not to be trusted, not ten years ago, not five years not, not today, not ever.
BS again. Microsoft has NEVER expressed visceral hatred of open source. Ballmer has compared one open source license - GPL - with cancer, because of it's viral nature. The intentionally viral nature.
Ballmer is not at the helm any more. But even he never expressed hatred at open source, as you claim. You could construe his comments about GPL as hatred against that particular license type. And indeed, Microsoft has always opted for other OSI approved licenses when they had the choice.
But if you have any other sources for your made-up claim - say other MS top executives, maybe even present ones - then please feel free to post them.
Can you run a .NET application that currently resides on a Windows-based web server on a Linux-based shared hosting server using Mono?
In general: Yes. Need more context about the application to give a definitive answer, e.g. if it uses Windows specific infrastructure such as AD, Workflow Foundation.
Quite simply, a patent "promise" is not the same thing as a license. You see, even if they're bared by Laches, they can still drag you through the courts and you've got to prove they're barred by making the promise. If you had a license...you could make a single motion at the first hearing or in the pretrial motions to dismiss because of being licensed if they sought to sue you.
Having this crap in there means Mono's toast without a real license to any valid patents, combined with a covenant to license all tech as it becomes apparent, that ends up in this common core of stuff. Otherwise, you're INSANE for using it- because you can and most probably WILL be sued over it.
No - it is actually stronger (look up promissory estoppel). But leave that aside, because the patents have also already been granted.
The *promise* was issued because fanatics cried foul at the patent grant, arguing that Microsoft with it vast army of lawyers could just sue any OS project out of existence, patent grant or not. Hence, Microsoft issued the promise, all but ensuring that such a case would be outright dismissed since you've acted in good faith on a promise. The promise in that case is actually one of the strongest contract forms imaginable, as it is one-sided: you do not have to sign anything to be covered.
I may add:
The PATENTS.TXT (https://github.com/dotnet/coreclr/blob/master/PATENTS.TXT) also does not claim anything like that. It merely says that if *you* bring a patent lawsuit against *anyone* for using the *covered code*, any patent grant is revoked and the promise is revoked.
well considering their 'mit license' is invalidated because of the wording saying you can't use without their engine or code... it kind of is a trap. Just a bad one.
I suppose you have a source for that restriction?
Can you please help me, because when I view the LICENSE.TXT (https://github.com/dotnet/coreclr/blob/master/LICENSE.TXT) I cannot find anything like that?
Starting from scratch:
PS C:\Windows\system32> Get-Command -Noun *vpn*
(list of commands with VPN in the name - which includes an "Add-VpnConnection" command. Lets see...)
PS C:\Windows\system32> man Add-VpnConnection
(syntax and "man" page. Yup, that is the command I was looking for. Wonder if there are any examples...)
PS C:\Windows\system32> man Add-VpnConnection -Examples
(several examples with explanation. Let' try it...)
PS C:\Windows\system32> Add-VpnConnection -Name Doh! -ServerAddress 10.1.1.1 -AllUserConnection -AuthenticationMethod MSChapv2 -EncryptionLevel Required -L2tpPsk SuperSecret! -TunnelType L2tp -UseWinlogonCredential
(connection is created)
Boy, that was hard!
not all open source code is bulletproof but microsoft has proven their code is swiss cheese. so why would anyone willingly use a MS product that for something that needs to be secure? when people are shooting at you, do you want to be wearing body armor or cheese?
http://www.zdnet.com/article/t...
Microsoft has (discounting the time before the nimda and code red disasters and the security push) consistently beat the industry average on fewer vulnerabilities for comparable products.
Specifically the later versions of internet information services (IIS) - the webserver that would be roughly comparable to Apache httpd with PHP, Ruby or Java - have fared extremely well in comparison: IIS 7 has had 8 vulns discovered in it's entire lifetime, while IIS 8 still has a clean sheet.
Not a troll but a genuine question - what's stunted about ASP.NET MVC?
ASP.NET MVC along with the other "web MVC" have really little to do with the real MVC as in the original smalltalk MVC described by Trygve Reenskaugs MVC. Web MVCs are bastardizations of the original concept, often only riding the name for recognition. I blame Struts and RoR for starting this trend.
I believe grand parent was referring to the original MVC which was a way to design interactive, event-driven GUIs. The original MVC was a recursive concept: The view could itself be a "tool" that in turn followed the MVC pattern. See http://heim.ifi.uio.no/~trygve...
As far as "web MVCs" goes, ASP.NET MVC is a really good one. But real MVC it is not. But that's a lost cause. An entire generation of developers have grown up believing that RoR and Struts were examples of MVC. In actuality, the designers og Struts and RoR grossly misunderstood the concept.
This is bad. Research has shown that extra crypto operations needed for DRM will add to energy consumption and contribute to global warming. This is an immoral product!
I'll be "that other guy" and point out that Lego is not an acronym.
Uhm. From WhatIs.com:
An acronym (pronounced AK-ruh-nihm, from Greek acro- in the sense of extreme or tip and onyma or name) is an abbreviation of several words in such a way that the abbreviation itself forms a pronounceable word. ...
Abbreviations that use the first letter of each word in a phrase are sometimes referred to as initialisms.
LEGO is an abbreviation (though not an initialism) of Leg godt, danish for "play well" - or perhaps more like "have fun (playing)"
So it appears that it is an acronym
Windows 64 bit has an absolute kernel-driver signing requirement. Windows 32 bit has for compatibility reasons a more "soft" requirement - that's where you'll get the warning box instead. Reason: Windows is still compatible with drivers from the XP/2000 era and will still load those. At that time nobody had considered driver signing, and the vendor may now be defunct. An absolute requirement would render devices unusable. The signing requirement was in force when 64 bit was introduced, and MS reckons that all drivers for 64 bit must have been signed, thus the signing requirement is non-negotiable on x64.
You *can* load non-signed drivers by attaching a kernel mode debugger. This is to facilitate development of drivers without a long signing roundtrip.
Oh, that promise is legally binding? I don't think so. And CEOs change.
Yes, it is binding. Legal estoppel is the term. It is used when you act in good faith on a promise. It is in fact one of the strongest contract types you can imagine, because it is considered a one-sided contract that you do not even have to accept (like you do with e.g. license terms). If you can show that you acted on the promise, a patent case against you will be dismissed.
There is a big difference between mitigation and prevention. Secure boot is a prevention mechanism: It prevents the system from booting if the boot chain has been tampered with. You can boot from external media such as an USB key and salvage data, but the system will not boot by itself.
What you are suggesting is a mitigation mechanism. As I wrote above, code running in a security context cannot protect effectively against code running in the same security context. It can only try to *mitigate* such attacks, but mitigation are speed bumps compared to prevention, which are road blocks
Windows certainly has it's share of mitigation mechanisms. First there are all the anti-exploit mitigation mechanisms which are designed to thwart an exploit from getting foothold, even when a vulnerability exists in 3rd party code. These are stack overflow/underflow prevention, DEP/ASLR, heap encryption/checksumming, safe structured exception handling (SafeSEH) etc etc.
Then there are the built-in running mechanisms such as ELAM, patchguard etc. Patchguard will checksum central kernel tables, and if malware tries to gain foothold in the (running) system by patching into e.g. the page table, patchguard will react to the checksum discrepancy and halt the system.
Secure Boot prevents a compromised system from ever starting. Your suggested mechanism is already there - Windows will *try* to prevent unauthorized patching. But that is mitigation and far less effective than prevention.
To be loaded as a driver, the driver must be signed.
Correct me if I'm wrong but to be loaded as a driver, the driver must simply start a UAC prompt and then let the user click yes, and then yes again to the unsigned driver dialogue.
If you rely on a user not clicking yes then you have a very big gaping security hole.
Consider yourself corrected. UAC has nothing to do with drivers. Kernel mode drivers under Windows *must* be signed by a recognized authority. If a driver is tampered with, the kernel will refuse to load it. If a driver is unsigned, the kernel will refuse to load it. On x64 systems, the user can *not* opt to override this warning.
UAC prompts has to do with integrity levels - which is a way to divide processes, files, registry keys etc into "trust zones" and isolate processes running with lower trust (lower integrity level) from accessing resources having higher trust (higher integrity level). Even when your account has admin rights, the admin rights are stripped from your token at login, i.e. you are running as a standard user without any special privileges. Windows saves the "full" token, but it is not active. When you start a process based on an image that declares in its manifest that it must run as admin, Windows will issue the UAC prompt on a separate secured desktop. If you accept the elevation (that your admin privileges can be used for the process), Windows starts the new process with the "full" token - and with high integrity level.
In Windows, it's not unheard of that a piece of malware with sufficient access interjects itself where the next boot will be picked up before the OS has a chance to set up it's own protection. Of course my complaint is that this vector would have easily been sidestepped without a huge firmware mess. If the OS set up access to that area as very very very very special, requiring signed code within the OS to modify that section of the platform, then the problem would have been solved. .
Sorry, but no. If you knew anything about threat modelling and OS design, you would know that code running at a trust level cannot protect against other code running with the same trust. The x86 architecture does have 4 levels, but for a number of reasons (mostly portability) practically no OSes use more than 2 levels (rings): protected/kernel and user mode.
What you are proposing is using a 3rd ring - something more privileged than kernel mode. This would constitute a major architectural redesign and would trash portability/compatibility with other architectures.
The fact is that UEFI Secure Boot is a very effective mechanism for blocking boot sector infections. As Windows has grown ever more resilient against permanent infections (app/driver signing, checksum tables, strong named assembly cache etc) malware authors were forced into infecting at an earlier stage of the boot process, if they wanted to take up permanent residence.
The OS kernel mode MUST have the capability to write all sectors of the disk. It can effectively block usermode apps from writing such sectors, but if kernel mode driver contains a vuln, rogue code can bypass any security mechanisms enforced by the kernel. It can just jump to the address efter the security check or control the IO itself.
Bootkits exists for Wndows. It was a real threat. A few unscrupolous individuals (lookng at you Garett) chose to instigate a FUD campaign, deliberately misrepresenting facts and knowlingly failing to correct misunderstandings when they advanced their case.
And you are still part of that.
How about 'no'.
Agreed.
Consider the situation where an attacker has actually compromised a server key - either it was leaked, brute forces, a vulnerability exploited. It happens and big parts of the certificate system such as revocation lists, OCSP, validity periods etc are concerned with this. Or consider the situation where a vulnerability allows the attacker to *fake* the fact that he has the private key.
Many systems are set up to warn or outright block if they are not able to check revocation for a certain time period. Seems to me, that with this extension an attacker can use the time from when the key is actually compromised until the breach is discovered/reported and gain permanent foothold instead of a temporary one.
This capability seems too dangerous to even have in the protocol - even if one can argue that it is protected. It broadens the attack surface in a significant way.
Of course, all security is a balance between risks, consequences and cost. Maybe, if this capability significantly lowers some other risk, it could outweigh the risk incurred by the increased attack surface. But color me skeptical.