Posts by Julz 1004 publicly visible posts • joined 23 Oct 2009
Arguably part of the runtime environment but yes, the logic that is used to process your code is itself a security concern. Ken Thomson's essay is a good start down the trapdoor of paranoia into the land of the queen of hearts.
I was just trying to point out that having visible source code isn't any real form of security guarantee and that saying so is at best disingenuous but most likely downright dangerous as people might actually believe that it is.
Statement is at the heart of a great deal of peoples faith:
"You can't hide a back door in open source because it would be immediately visible and removable"
But it isn't true. You also need control, and trust, the rest of the compile time and runtime environment.
Only a very naive infiltrator would put a piece of malicious code in plain sight.
Preemptive execution and huge caches strikes again. Given some situations, you can have a lot of rolling back and invalidating of cache lines to do on a context switch which has caused all sorts of design decisions to be made including the one to move away from micro kernels which, I feel, is a poor one. When I was doing such things, I measured Ultra SPARC CPUs using an average of 4 clock cycles to perform a context switch in and out of kernel space. That figure on modern CPUs and kernels is in the order of hundreds and even thousands of clock cycles, and no, they are not clocked that much faster. The quest for straight line CPU speed and marketing bragging rights amongst CPU manufactures has had many consequences in both the security of and the real world speed of systems.
Think a more interesting question is; why are there so many patches? A combination of poor release and testing systems combined with a high threat area and intensity are probably two of the main factors. Perhaps those areas could be improved upon which would lead to a much happier life for both the poor sods applying the patches and the end users experience of the system.
StewartWhite: just read your post. I agree, we should not just tolerate the current mess.
Software is a goods (that sounds awful). There are services around the goods such as maintenance, installation etc. but the delivered software is most definitely a goods. It does have a physical instantiation, it does have set of delivered features, it must deliver on those expectations. The instantiation is the material that it is delivered upon. In ancient times that might be a tape or a disc but nowadays it's more likely to be a download, which is instantiated on the receiving device. The set of features is the definition of what the software is expected to do. The expectation is that it delivers those features correctly and without prejudice.
The rules that apply to goods apply to software, it's just that most don't seem to know or care. Mostly the problems around fitness for purpose stem from a lack of clear definitions or changing expectations. We have been bludgeoned over the years into accepting very poor quality software. Free software has also muddied the waters and lowered expectations. To use your example of cars. There are well defined systems for recalling cars to fix defects that have caused the delivered goods (the car) from not performing to either the expected specification or to regulation. This includes the software components of the car as well as the more physical components. Such pathways should also be available for software only goods.
We just live with poor software and throw our collective hands up as if saying. "it's all far too complicated" and "what do you expect". Well, how about expecting well engineered software that correctly deals with the complexity. Oh, you would probably have to pay for it but who expects a free car?
/EndRant
Not just for chasing media formats. One of the background tasks that computer operators (remember them :) ) did when things where quiet was Forth Bridging tapes. That is, copying and old archive tapes onto other tapes so that the archive remained viable. If I remember correctly, the operating system (George 3 at the time) had a built in job to keep track of everything and prompt which tapes needed to go on which drives etc. Just leaving a tape to molder in an archive is a sure way to have a write only backup.
The ICL Technical Journal, 1987:
"The present 5G programme has been designed to respond to a number of pressures, some recent and some visible within the industry for many years. The main drivers have been:
The high cost and unpredictability of software development and maintenance, coupled with the shortage and mobility of trained programming staff. This has been a constant problem within the industry for two decades in spite of significant advances in software engineering methodology and more recently with the widespread adoption of fourth generation systems. It used to be called the “software crisis”, but the word “crisis” seems inappropriate for a phenomenon of such longevity. “Limit to growth” is a more durable phrase which better captures the effect of this problem."
This was the justification for a number of workbench (old name for IDEs) style 5G products within ICL to improve programmer productivity most of which tried to autocomplete and suggest boilerplate style code. It would seem nothing much has changed...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
