The NT kernel is incredibly high-quality work. It was developed in 1993 and 28 years later is still powering billions of devices. Windows did have a lot of security problems, granted, but many (if not all) were in the upper layers - of which there were many.

> Windows did have a lot of security problems, granted, but many (if not all) were in the upper layers - of which there were many.

Some (most?) of it was by design so Windows 9x apps could run on NT without modifications.

He did the very best that could be expected in the early '90s.

It was exemplary coding, and very little of its fundamentals have changed. I have some assertion on this from an interview in the late aughts - most of the problems were in layers above the kernel.

That being said, even VMS is not without flaws (we still run it for our manufacturing floor):

https://www.theregister.com/2018/02/06/openvms_vulnerability...

Nobody's perfect.

No, the best that could be expected in the early 90’s is formal proofs of security enforcing multiple independent levels of security (MILS) allowing the execution of arbitrary, malicious programs on the same systems handling TOP SECRET data in complete safety as achieved by TCSEC Class A1 certified systems contemporaneously.

In contrast, OpenVMS only ever achieved C2, security enhanced VMS B1 [1], and the NT kernel C2 [2]. NT kernel based systems subsequently maximally achieved EAL4+ indicating independent verification that it is adequate to protect against “casual, and inadvertent attacks”, but failed to demonstrate resistance against attackers with a “moderate” attack potential.

So, no, it is not the very best that could be expected in the early 90’s.

[1] https://web.archive.org/web/20151119105617/http://h71000.www...

[2] https://www.microsoftpressstore.com/articles/article.aspx?p=...

What commercially available A1-evaluated systems existed with an evaluated TCP/IP stack?

If you are not asking that rhetorically, then the Gemini Trusted Network Processor (GTNP) using GEMSOS achieved a Class A1 certification in 1995 [1] and included ethernet device support in its specification. This is adequate to implement a TCP/IP stack in a unprivileged context. My quick read of the report does not allow me to confidently assert that they do simultaneous ethernet device multiplexing which would allow a trivial implementation of multiple independent data streams over the same link, but they do appear to provide at least a generic time-partitioned device multiplexing solution which would allow multiple programs to transmit and receive serially rather than just being bound to a single program at boot time. This is adequate for a large number of use cases and removes the TCP/IP stack from the TCB and thus requires a lower degree of scrutiny as its failure modes do not cause whole system failure.

If you are asking rhetorically, then what NT kernel, NT kernel derived, NT kernel component, or even any code associated with the NT kernel in any context has been evaluated to Class A1, Class B3, EAL6, EAL7, or equivalent demonstrating proofs of security adequate for usage in high assurance systems? Arguing the NT kernel has achieved less security as a tradeoff to allow it to solve a broader use case is only valid if they have demonstrated the ability to actually make a tradeoff by achieving high security in a narrower use case nominally or at least qualitatively similar. If they can not actually demonstrate the ability to achieve the alternative, then they are not making a tradeoff, they are choosing the only option they can do.

And this is what they have demonstrated. At no point have they ever demonstrated a equivalent, or even qualitatively similar level of security at any scale within orders of magnitude of the scale demonstrated by the Class A1 systems. And it is not like they have not tried. They have attempted numerous times to certify, demonstrating a desire to succeed and at least meaningful effort to do so, and have failed to certify at anything more rigorous even in highly constrained configurations to the extent that they have given up.

To use a analogy, this is like having two energy companies and one of them says, "We have chosen a fusion energy solution that does not generate net energy because we believe that only fusion will be adequate when we have a interstellar civilization that needs to operate in the interstellar void." while the other has a working, economically efficient, solar energy solution that generates energy on the Earth today. Asking, "Can you point to a solar energy system that could generate adequate energy in the interstellar void?" as a counter argument is just plain silly because the existing fusion energy solution also does not work there and in fact does not work anywhere in any context.

[1] http://www.aesec.com/eval/NCSC-FER-94-008.pdf

Not only was I not asking rhetorically, but I saw the Gemini TNP and am aware that it never had an evaluated TCP/IP stack, only, as you said, the potential for someone to write one.

For about 4 months I was in charge of a Harris NightHawk running a B1 version of SVR3, which was two and a half pains in a half-pain glass.

I'm not an NT kernel fan, either.

Saying he doesn't want to produce any code that has bugs is not the same as doing it. Given how accomplished he is I'm sure he is well aware that sometimes bugs slip through.

Don’t mix up the core of Windows kernel with what rides on top of it.

A lot of NT hardening happening over last ~20 years was effectively enabling access controls that were set too lax previously or even disabled, all due to performance issues (GDI being moved in-kernel, with all the security issues, was also due to performance problems of NT3.x)

The NT kernel is quite nice and solid, the problem is that not everything built on it followed all of the design rules.