undefined | Better HN

0 pointsslowstart6y ago0 comments

Since this had to run in kernel mode on Windows to power our HTTP stack, C was the language of choice. There exist other open source implementations of QUIC in C++ and Rust etc.

0 comments

pjmlp6y ago

So what measures are in place to avoid being part of the 70%?

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

nibanks6y ago

Just to pile on here, running in kernel mode was the primary reason for using C. Windows kernel does support some limited set of C++ features, but we decided to go with pure C instead because of the confusion of which C++ features were available, especially in an open source environment, where not everyone is familiar with Windows kernel.

As far as what we do to keep quality high, we have a large number of automated test (> 4000 cases per CI run) automated on Azure Pipelines. Our code is deployed on several interop servers used to test with all the other QUIC implementations out there, and we do additional testing and fuzzing internally at Microsoft.

saagarjha6y ago

Since this is going in the kernel and is exposed to the network, what kinds of things are you doing to prevent security or reliability bugs due to undefined behavior?

Love the username, by the way :)

slowstartOP6y ago

We do extensive testing including stress testing and make use of tooling that can catch bugs early. We also partner with internal security teams to do fuzz testing and security reviews for all networking code. That said, none of the networking stacks deployed widely today are completely immune to security vulnerabilities. Responsible disclosure also plays an important role.

sansnomme6y ago

Any plans to integrate or collaborate with Project Everest?

__s6y ago

You can see some of the tooling they're using, .azure outlines CI & /tools has scripts like https://github.com/microsoft/msquic/blob/6fa51a42f69c59748dd...

There'll also be static analysis being thrown at it

Kipters6y ago

I thought Rust was being considered for these use-cases. Is it (or was, at the time you started working on it) too early for that?

MrBuddyCasino6y ago

Isn’t the Windows kernel C++?

Strom6y ago

The Windows kernel is mostly C, but also parts in assembly and C++. [1] It also helps to keep in mind that back in the late 80s, when development work on the NT kernel began, C++ was still the new kid on the block. NT kernel work began even before ANSI C was done.

[1] https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...

pjmlp6y ago

Just as historical note.

Microsoft C/C++ 7.0 was released in 1992 alongside MFC 1.0, which was a bit late to the race.

Microsoft was the latest C compiler vendor on the MS-DOS space to integrate a C++ compiler into their tooling.

j / k navigate · click thread line to collapse

0 comments

pjmlp6y ago

So what measures are in place to avoid being part of the 70%?

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

nibanks6y ago

saagarjha6y ago

Since this is going in the kernel and is exposed to the network, what kinds of things are you doing to prevent security or reliability bugs due to undefined behavior?

Love the username, by the way :)

slowstartOP6y ago

sansnomme6y ago

Any plans to integrate or collaborate with Project Everest?

__s6y ago

You can see some of the tooling they're using, .azure outlines CI & /tools has scripts like https://github.com/microsoft/msquic/blob/6fa51a42f69c59748dd...

There'll also be static analysis being thrown at it

Kipters6y ago

I thought Rust was being considered for these use-cases. Is it (or was, at the time you started working on it) too early for that?

MrBuddyCasino6y ago

Isn’t the Windows kernel C++?

Strom6y ago

[1] https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...

pjmlp6y ago

Just as historical note.

Microsoft C/C++ 7.0 was released in 1992 alongside MFC 1.0, which was a bit late to the race.

Microsoft was the latest C compiler vendor on the MS-DOS space to integrate a C++ compiler into their tooling.

j / k navigate · click thread line to collapse