131–140 of 169 posts
Why then are the first lines of the STS code not something like
// server receives reliable timekeeping through the Network Time Protocol.
if (ntp_enabled() && ntp_working())
return 0;Earlier quoted context omitted.
That's the point, if you can't trust the connection, stop trying to come up with more complicated ways to use the untrustable connection and accept that there is no safe way to update time.
Ok, so the system should fail to boot, right?
But since the vast majority of them do not fail in that matter if the normal, configured methods of determining time aren't working, using TLS parameters that have been deliberately randomized by standard for like what, a decade now?, can not possibly be a more straightforward failure mode than logging errors and waiting for operator input.
If it's that critically important, embed a fixed signature for a set of known time sources and query those as a last resort. Microsoft certainly has the resources to set up a few to do this the much more obvious and predictable way.
Earlier quoted context omitted.
> ...if it has a network... But that network is not trusted. Imagine this: You boot a machine for the first time, and the system clock tells you it's January 1, 1970. You might know when your OS was built, so you could maybe hard-code some sanity checks there, but you basically don't know what the date is. You want to communicate securely with weather.gov? Sure, you can do that over SSL/TLS. You send it a list of cip…
The article says: > Because Secure Time Seeding used SSL certificates Windows already stored locally, it could ensure that the machine was securely connected to the remote server. The mechanism, Microsoft engineers wrote, “helped us to break the cyclical dependency between client system time and security keys, including SSL certificates.” But in that case, why does the Windows time service connect to a random server…
Windows Time bullshit was one of the most annoying things I dealt with during my years as an IT guy. Registering and unregistering w32time, trying different NTP servers. Trying to figure out why domain systems werent getting their time from the DC. It always felt so... stupid. Surely having the correct time on a device isnt that complicated. Turns out, its not, unless you're on Windows. Somewhat ironic that these day…
It's probably still the case that Windows will consider the firmware clock more reliable than anything but a stratum 1 (direct gps/glonas/atomic) or maybe 2 time source which can result in truly bizarre behavior if the firmwar/hypervisor drifts too far from dozens of stratum 2 or 3 active directory servers. It logs no messages about this logic fork. I don't recall the exact conditions that determine this but troubles…
Earlier quoted context omitted.
Why can't it just ask the human to provide it, either in the welcome UI or in a setup script? That's how we've set up computers for many milliseconds.
If I understood the article correctly, this misfeature is for the rare case in which the server reboots after a power loss and the real-time-clock battery on the motherboard is dead, which can happen long after the initial setup of the server.
Earlier quoted context omitted.
This is what puzzles me - while time drift does occur, it tends to be in the form of minor errors which build up over time; large jumps are relatively rare. You'd think the mechanism described in the article would have a failsafe ensuring that only minor time recalibrations are performed.
There are a lot of machines out there with a dead battery on the real time clock. Every time they boot, the time is miles out and at some system-determined zero point.
Earlier quoted context omitted.
How is the hardware clock connected? It it is something serial it could be an offset by 1 bit.
If it's an x86 laptop, it will be compatible with the MC146818 chip found in the original IBM AT, and return the time in BCD format as yyyy/mm/dd hh/mm/ss.
A bit of a tangent, but this time-checking heuristic reminds me of the game "Halo 3: ODST". The story takes place in a future African megacity before, during, and after an alien invasion. Part of the game's story is shown from an AI's perspective who controls the city's operations trying to evacuate the Human survivors. Whenever the story is shown through the AI's perspective, you can see an overlay of the AI's worki…
Earlier quoted context omitted.
> advising sfc /scannow and then reinstalling the OS. I really hate that. If there is some problem, properly diagnose it, figure out how it happened, and figure out how to change things so it can never happen to you or anyone else again. Or you could just wipe all config and reinstall everything and hope it doesn't happen again!
My work Windows server VM boxen started off life largely as 2008 R2, one was 2008. They are all now mostly 2022 and converted to EFI with secure boot - some of them put up quite a fight. Not a large setup - three DCs - one in my home attic for DR, a File n Print n NPS n CA box, a Trellix (Nee McAfee) ePO and a few more bits n pieces. sfc /scannow can fix issues but it is not a panacea and certainly not the first thin…
* broken on arrival and never really fixed
* negligently implemented that causes serious harm
* a dark pattern that no one actually wants but improves the windows margins through covert means (data harvesting, embedded adware, etc)
I’m sure they exist, but the prevalence of the badness is so striking.