Re:MsQuic – QUIC Implementation from Microsoft
by slowstart on Wednesday April 29, 2020 @12:28AM
(#23015363)
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.
[ Parent
| on HN ]
Re:MsQuic – QUIC Implementation from Microsoft
by pjmlp on Wednesday April 29, 2020 @05:49AM
(#23017309)
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...
Re:MsQuic – QUIC Implementation from Microsoft
by nibanks on Wednesday April 29, 2020 @10:41AM
(#23019813)
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.
Re:MsQuic – QUIC Implementation from Microsoft
by saagarjha on Wednesday April 29, 2020 @12:41AM
(#23015443)
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 :)
Re:MsQuic – QUIC Implementation from Microsoft
by slowstart on Wednesday April 29, 2020 @12:55AM
(#23015523)
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.
Re:MsQuic – QUIC Implementation from Microsoft
by sansnomme on Wednesday April 29, 2020 @01:40AM
(#23015769)
Any plans to integrate or collaborate with Project Everest?
Re:MsQuic – QUIC Implementation from Microsoft
by __s on Wednesday April 29, 2020 @12:57AM
(#23015532)
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
Re:MsQuic – QUIC Implementation from Microsoft
by Kipters on Wednesday April 29, 2020 @04:56AM
(#23016963)
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?
Re:MsQuic – QUIC Implementation from Microsoft
by MrBuddyCasino on Wednesday April 29, 2020 @12:45AM
(#23015463)
Isn’t the Windows kernel C++?
Re:MsQuic – QUIC Implementation from Microsoft
by Strom on Wednesday April 29, 2020 @04:27AM
(#23016793)
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...
Re:MsQuic – QUIC Implementation from Microsoft
by pjmlp on Wednesday April 29, 2020 @09:51AM
(#23019162)
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.