sophac...@gmail.com said: > So what I am trying to understand today is ways we can affect the > reliability of the clock, having affects on everything mentioned above.
There is a big overlap between maliciously attacking the clock and the clock doing something crazy due to bugs in hardware, firmware, software, or wetware (people/operations). If I was working in that area, I think the first step would be to collect a data base of interesting events to make a checklist of things to think about and/or feed to regression testing. I don't know much about power grid control. Is there a good overview web page? What level of time accuracy do you need? ms? us? Do you need absolute accuracy or just stability? What sort of network environment are you using? Are you on a well run lightly loaded private net or running on the big bad internet? What sort of OSes are you using? Does each control room have it's own good source of time (local GPS) or do some of them get time over the net? ---------- > * Is the method for reading the clock a directly wired GPIO pin, or is it on > a shared bus like I2C or SPI? (If so, other things on the bus could be > compromised instead to not play nice with bus and affect readings) I think you are missing a key idea. Most OSes maintain the system clock in software. Once the system is up and running, there is no off-chip hardware involved to read-the-clock. Most systems read the RTC/TOY clock once at boot time and use that to initialize the internal clock. Details vary with OS and hardware. Most modern CPUs have a counter that runs at the CPU clock frequency. Intel calls it the TSC. If you can adjust the CPU frequency (to save power), there is probably some counter that runs at a fixed frequency. Timekeeping is just read that counter and do some math. Very old systems used to bump the time on every scheduler interrupt. That interrupt often came from the RTC chip. Not quite so old systems did that, but also interpreted between scheduler ticks using the TSC. The crystal that drives the CPU and/or the calibration software is often off by 10s or 100s of ppm. Most OSes have a system call to adjust the calibration factor. ntpd calls it drift. This makes a huge difference. If you have a local PPS source, you can use it and ntpd as a thermometer. http://www.ijs.si/time/temp-compensation/ Changes in self heating when the workload changes makes this area very interesting. ---------- > Specific attacks (e.g. Device X has software bug Y allowing $Algorithm to > cause $Result) should be reported to the vendor quietly to allow them to fix > it, and once a fix is available, it should be publicly disclosed to allow > people informed decision on upgrades and mitigation, as well as to provide > understanding and examples for future defenders. Some vendors have a history of ignoring reports of serious security problems. I think the "allow them to fix it" needs a timeout. That whole approach assumes that everybody can just blindly install all the vendors software updates as soon as they are released. That's not likely to be the procedure in any high reliability environment. -- These are my opinions. I hate spam. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.