Posts by fg_swe

Arm rages against the insecure chip machine with new Morello architecture

Avoiding Side Channel Attacks

The main guy behind the SeL4, Gernot Heiser, explained how to rid of the SPECTRE style side channel attacks in a video (he has lengthy videos online - cannot find the right one; please look at them for your enlightenment). Essentially, what must be done is to flush/invalidate all kinds of caches, TLBs and similar mechanisms before you perform a task switch.

SPECTRE definitely is an issue, but it is orthogonal to memory safety.

Similar to ABS brakes, automatic video/radar brakes and safety belts. All are important measures in their own right.

Hamburger Computing

Hamburger computing is to focus on cost and execution speed only. Disregarding safety and security.

Like eating fast food and being amazed about cost efficiency, while wondering where all the health issues come from.

Null Pointers Are Not The Worst

A null pointer will result in a deterministic crash. What is much worse is heap corruption from invalid pointers, which can modify program heap in all sorts of weird ways. Attackers also love these pointers.

Production Runtime Bugs

Typically, programs can not be exposed to all theoretically possible inputs during the test+validation phase. So some programming errors will only show up during productive runtime. For example, when little Ivan from Tomsk enumerates all possible inputs.

See Sir Tony Hoare on the issue of runtime checking.

Re: Very Expensive Approach / Details

If I understand the ARM concept correctly, they need very fat pointers to store all the safety information.

Compared to that, a Sappeur program needs just the native pointer size(can be anything from 16 to 64 bits) plus a reference counter(typically 4 octets plus pthread_mutex for multithreaded objects) at the targeted object.

ARM seems to consume 16 octets for a safe pointer. That is a lot of cache bloat and a lot of excess memory transfer bandwidth spent.

Compile this sample to see it yourself: http://gauss.ddnss.de/

Pointers Are Fine For Code Generators

...but very bad for 100% of human developers. See the CVE database and all the exploits in the code developed by "seasoned" kernel developers. Or Mozilla, Oracle, MSFT, QNX, ...

ICL, UNISYS, MOSCOW

They all had mainframe computers with plenty of runtime checking. Then came the "cheap" Unix+C. "presented" like a Trojan Horse to the computing world.

https://en.wikipedia.org/wiki/ICL_2900_Series

https://en.wikipedia.org/wiki/Burroughs_large_systems

https://en.wikipedia.org/wiki/Elbrus_(computer)

Sir Tony Hoare

We already had very nice Algol mainframes completely with lots of runtime checks. Then came the Hamburger Approach to computing in the form of Unix+C.

https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

Valgrind

A valgrind program execution takes 10 to 100 times more CPU time. Use an efficient memory safe language such as Sappeur and the penalty will be in the order of 10%.

Re: Pointers to failure

Smart pointers cant help you in case of multithreaded race bugs. A proper programming language can. See my other post.

Very Expensive Approach

Software-based approaches are much more lightweight and powerful than doing it by means of hardware. The compiler's type system has a much better view of the entire program than a CPU can ever have at runtime.

See this language of mine:

http://sappeur.ddnss.de/SAPPEUR.pdf

European silicon output shrinking, metal smelters closing as electricity prices quadruple, trade body warns

Re: Uranium

Yeah, sure big mouth, no substance. You must be a greenie.

Uranium

Everybody burns U235 and some a bit of Plutonium. The U235 is usually mixed with U238. The greenies and their lackeys from CDU to SPD disabled the Uranium based power generation without organizing a methane replacement.

You point was ?

Idiots At The Wheel - Germany

The Maoists ("greens") who currently run the energy show in Germany managed to shut down Uranium power and have all intentions to shut down all coal plants, too. They never bothered to organise the delivery of Methane replacement for U235. Instead, they double down on their lunacy by slow walking the approval of the second pipeline from Russia. And they complain all day about supposed Russian blackmail via Methane.

This is actually very hard to wrap your head around: first they want to shut down any reliable German energy production, then forget to order replacement Methane and finally complain about increased dependence on Russia.

All of this makes sense if you are a childish Romantic or if you look at it from Beijing's perspective. Or if you are a Romantic COMINTERN asset trying to please Beijing.

In China, they have the largest fleet of coal power stations and the second largest nuclear reactor fleet. Based on this cheap energy, China has by now amassed the largest industrial capacity of any nation.

Well done, Mao. China is proud of you.

The opposite must be said about those who enabled the German Maoists.

Joint European Torus celebrates 100,000 pulses: Neither Brexit nor middle age has stopped '80s era experiment

Their main nation is rooted in Germanic and French tribes, but they hate their roots from the bottom of their heart sometimes.

Fujitsu wants technology to shape a better future – its technology, of course

Re: SOS

That could very well be the case, IF we manage to get moneygrubbing oligarchy off medical policy. If not, truly dark ages of quick+dirty injections ahead.

Compared to Boeing

At least they did not kill 250 people.

WebSpec, a formal framework for browser security analysis, reveals new cookie attack

Re: Server Load

I already do this type of work by using my fixed PC as a compile workstation, 30kms away. That is much faster than compilation on the laptop I have at home.

Once I even used RDP to work in one European captial and use a computer in a different European capital. Worked quite nicely. That was in 2016.

So, bitmapped terminals are a real, feasible thing. They must only be made available in a WWW-style fashion, as was BTX, Minitel etc.

Server Load

Shifting load from client to server is probably in many cases advantageous, as the server computers are shared between the entire user population. Sharing will drive up utlilization rates on this server CPU+RAM.

Running an app on the client side means the clients must be powerful, but the client hardware will be unused more often than used.

From a national economic point of view, this means that much more expensive (read: consumed loads of energy+CO2 to produce) semiconductors must be produced.

Time For a Systemic Reconsideration

1.) Do we really need so much stuff in a web browser ? HTML, CSS, JavaScript, Video Codec ?

2.) A kind of secure X11/BTX/MiniTel can be realized in probably 1/100th the lines of code. For many applications, this would be a workable solution.

3.) The untyped JavaScript language is in many ways a security risk, starting by the complex JIT compilers and ending with browser HW fingerprinting. Why run a script in the terminal ?

Rocketing chip sales growth to ease off this year, reach $680bn, say analysts

Spare Parts Business

Note that this would be a massive raise for the spare parts business of the auto companies. Spare parts can be a highly profitable business, if correctly run.

Refurbish Instead Of Produce New

In countries such as Belarus, where wages are low compared to western Europe, they will repair a car even when it has 250 000km and 15 years of age.

One could make a business model of shipping cars to Belarus, refurbish them there and ship back to western Europe, sell them as refurbished (brakes, clutch, ball bearings changed).

The huge Japanese transport ships could be used to bring the cars to Vilnius, from where they could be transported to Belarus.

And The Consequences Are ?

1.) Don't recycle cars as early. Spend more effort and money into repairing old cars. Do we really need the chrome blink as much as we think ? This maintains very good jobs in every local economy.

2.) Boneheaded Auto Managers should use their brains and dont shut down their demand of components totally. This would signal the components/chips/resistor/etc producers that this business is real. If there is not enough money in a crisis, go to national leaders and demand special credit for this purpose from banks like KFW.

3.) The enormous monetary expansion we had in the last 15 years will create "shortages" at the "current" price points. Who would have thunken that ?

4.) Instead of throwing more CPUs and more RAM at any problem, maybe we developers should aim for better algorithms and generally more efficient approaches. Ditch PHP, use Sappeur, Rust. https://sappeur.ddnss.de

5.) Due to monetary expansion, raw materials such as sand for concrete is running out. Yes, sand running out. Maybe we should not expand money at that breakneck speed ?

6.) When fuel is getting short/expensive (as it has been in the last months), maybe we should all take local vacations instead of a flight to Mallorca or Florida ? Airbus and Boeing are going to hate this idea, but these corporations are there to serve the public and not the other way around. Maybe they also should do more repairs than crazy production numbers.

7.) In general, a well-managed money system will handle any shortage. People will become very creative when something (say a CPU) increases in its price tenfold. Then they will tell the engineer to use a more efficient programming language (see 4.)

After deadly 737 Max crashes, damning whistleblower report reveals sidelined engineers, scarcity of expertise, more

Covid Vaccine Trials Testimony

You might have a look at this

https://rumble.com/vqwdp6-how-many-more-adverse-effects-have-been-covered-up-during-the-trials-maddie.html

There you can see that we are missing basic ethical foundations. It is no longer about the fine points of testing, it is about deep-seated corruption due to monetary concerns.

Re: The People ARE The System.

Given the 787 battery debacle (which was a near miss to hundreds of passengers killed), it seems the FAA and EASA is a bunch of useless whimps. Somebody should have walked straight into jail.

Re: In Case of MCAS: Logical Reasoning, Calculus

I come from the auto side of things and we cannot have large numbers of sensors, if anyhow possible.

So, two sensors are mostly OK:

[numbers guessed]

Rate of failure of one AA sensor: 1/100 000 [1/flight-hours]

Rate of failure of two AA sensors at same time : 1/100 000 * 1/100 000 = 1E-10 [1/flight-hours]

That 1E-10 is already a very "good" number.

Now, the really interesting number is

"Rate of double AA sensor failure with identical reading" = (rationally thinking, guessing) = 1E-13 [1/flight-hours]

That is prolly already small enough to be an acceptable risk according to methods such as (A)SIL or DO178.

This is how the auto folks think and it seems it is a quite reliable method.

No

They already had two sensors and two computers. Only SOFTWARE was missing to check both sensors against each other. Disable MCAS in case of implausible reading. And another little piece of SW to display the malfunction to the pilot.

What this means is that entire coporations can come into a state of deep dysfunction, due to corporate psychological failure aka. GroupThink.

There was no money to save from hardware and there prolly was not enough balls in the engineering side of the corporation.

In Case of MCAS: Logical Reasoning, Calculus

Depending on a single sensor (or any other component) to make the potentially life-threating decision to steer the aircraft into ground direction, is a rookie mistake. There exist well-established methods of statistical analysis down to the level of single components such as a resistor, to calculate the total failure rate of a system. There also exist threshholds about total failure rates. E.g. see the "SIL" approach.

Single components, and especially exposed sensors will fail. Think of bird strikes, debris blown over the runway, cables corroding etc.

This type of problem must be caught by functional safety engineers.

It would also have helped to perform simulations with a faulty sensor, but that requires the intution that the sensor WILL fail, too.

The fix is also quite obvious: have a second sensor to check the first one and disable the system if sensor readings dont match. Signal problem to pilot or another strategy to work around the failure mode.

How's 2022 going for you so far? Hopefully better than it is for IBM Cloud

Re: FALSE

The same reasoning goes with Oracle; if you also have DB/2 in your company you can compare the offerings of these two vendors. That usually keeps them more honest.

These days you can also rent DB/2 instances in the IBM cloud.

FALSE

In the IBM Cloud you can also rent x86 and Power machines.

Power still seems to be a highly competitive CPU architecture in terms of raw performance and they still invest in it.

Smart customers will not put all their eggs into the Amazon basket, but have multiple service providers. Then they cannot be blackmailed by one vendor.

RISC-V CTO: We won't dictate chip design like Arm and x86

Other Domains

Maybe you are correct for phones, because of the logistics of binary code (as opposed to portable Java code). But, there are plenty domains which can easily switch:

Data Centers (they run various Riscs since 1992 or so, Now Amazon has ARM)

Apple Devices

Automotive

Telecom infrastructure

GPUs

Medical

Rail

Aerospace

TV, Radio

Many of them currently switch to ARM from much more exotic stuff such as japanese Hitachi PDP11 and can do another switch to Risc-V, if ARM plays too complicated.

Apple ARM Performance

Apple has thrown their huge money and manpower behind ARM and have created the world's fastest (publicly know) CPU. ARM was slow in the past because it came from the phone world, where you can waste so much Joules as in the data center or the always power connected PC world.

Automotive MCUs

The auto world already uses plenty of different instruction sets: Power, ARM, Aurix, STM 16 bit, japanese Hitachi-PDP11 (no joking), japanese Mitsubish and probably 25 other instruction sets. It looks like the japanese now switch to ARM and use these controllers also in cameras, TVs etc.

That is possible, because automotive control units are custom-developed from pcb to housing to connectors to software. There is now some standardization from the AUTOSAR operating system, which is typically delivered in source by Vector Informatik. Modern auto software is fully done in C and is (to 99,99% of code) only a recompile away from a new mikrocontroller, if Vector Informatik has ported the OS to this MCU. Drivers are a different story, of course as they must fit to the MCU registers.

The control unit developer company must then demonstrate that the unit will meet all requirements defined by the auto company for the unit (including timing requirements). Unit and software testing should be done on the new controller to see that the compiler and the processor dont have funny behaviour. There is no additional effort for a new instruction set to perform this. Rather, the big effort is to define, create and debug all of these test cases.

In the IT sphere, a properly developed C++, Rust or Sappeur program will simply rebuild and run nicely on any major POSIX platfrom and CPU. If not, it is almost always due to a hidden bug. I have done this with great success from SPARC to ARM to ELBRUS:

http://sappeur.ddnss.de/

http://gauss.ddnss.de/

For example, the ELRBUS instruction set is a secret, but there exists a nice tcc C++ compiler. I never bothered to look at the generated binary code, it just runs quite nicely at approx RPI speed.

Azul lays claim to massive efficiency gains with remote compilation for Java

That will reduce RAM consumption by 50%, given equivalent algorithms.

Re: 80-100 per cent faster than what you can do with static compilation

That was exactly the original posters point.

Rusty Linux kernel draws closer with new patch adding support for Rust as second language

False

C++ Compilers have no support for memory safety built-in. All you can do is to try to be a disciplined user of smart pointers, index checked arrays and static checker tools. There is no coherent idea of memory safety built into C++, and Mr Stroustrup apparently considers this not a priority. He says it would be an all-or-nothing change and would break old code, so he does not want to tackle the issue.

Of course that is not the exact truth - one could think of a Compiler command line switch and some sort of "unsafe" keyword to gradually bring this into the C++ standard. And to gradually transform an existing C++ system into a memory safe system.

Diversion

You are saying we can forget the high-grade security risks because there are plenty of incompetent people around ?

On page 3 of this you can find why this is a very weak argument. The weapons-grade actors will use exactly such weaknesses to flatten entire corporations, complete with dedicated, full time IT security staff.

MTAs, Email programs, EDI systems, web servers, TCP/IP stacks - they are exposed to ALL bad guys of the planet. As soon as they have a foot inside your intranet, all the funny service ports of your PCs (of services mostly running inside the kernel) will be exposed too. And all the half baked database listener processes.

Plus

You can always perform an assembly code review of the most critical subroutines (e.g. those that are ASIL-D) and thereby gain confidence in the correctness of the compiler.

Embedded developers do indeed look at generated assembly code very often.

Re: Standardization?

The optimizing C compilers used in automotive, medical, aerospace and rail are being "qualified" for use by large test code batteries and essentially "old age" and "widespread use with small problems".

There have been cases of compiler and MCU bugs, because the approach above is NOT mathematical correctness proof.

The same can soon be said about the Rust compiler.

Also, functional safety requires very extensive test efforts including unit tests for each subroutine, which would most likely expose compiler bugs.

In the end, there is no absolute safety, but only a "best effort, according to state of the art".

Re: Is it just me ?

1.) Nobody forces you to use Rust.

2.) Cyber Security (more precisely: a lack of) is a very real problem. Memory safe languages are an important security measure. See presentation

3.) As stated in the presentation above "Other measures such as proper scanners, parsers and strict input validation are still required"

Re: earlier statements from Microsoft

They have grown smarter by now.

Spar shops across northern England shut after cyber attack hits payment processing abilities

Cash Is King

One more reason to use cash - the brittle state of computing in the year 2021.

Imagine what the attackers can do when they have all the cash card processing data !

MySQL a 'pretty poor database' says departing Oracle engineer

Re: Only 16 more years

We all know the company will be sold to the Americans by 2025, why bother ?

Make sure to be buzzword compliant with some AI and blockchains mixed in and diverse multigender. That will do.

At least you have a log server, which can be used to replay all transactions !

I have heard horror stories of small banks running on MS Access databases, so maybe MySQL is not the worst thing you can do.

Can Rust save the planet? Why, and why not

Unsafe Code Parts: Great

There exist valid reasons for using small parts of unsafe code in a larger memory safe system. For example, the Sappeur standard library will eventually call the POSIX API using the inline_cpp[[ ]] mechanism.

By doing so, the error-prone amount of unsafe code will still be a small percentage of total code and we can assume we will (statistically speaking) have very few memory bugs. inline_cpp[[ ]] should only be used by experienced C++ developers and it should be reviewed by another seasoned C++ engineer. Unit Tests should be created. Valgrind should be used with the unit tests.

So, it is not an all-or-nothing proposition, but rather an attempt to squeeze out the exploitable bugs related to memory safety.

Non Trivial C programs

..do indeed have exploitable memory bugs. That is what the CVE database tells us.

Multithreaded Memory Safety in Rust, Sappeur and Go

1.) Sappeur and Rust will force the software engineer to think about thread-shared data at compile time. Go does nothing of the like.

2.) Go assures the integrity of the heap, just like Sappeur and Rust do. C++ does not.

3.) You can have nasty data races in Go at a low level. For example, you can create a global counter and attempt to update it from many threads. Result will be undefined. With Sappeur, you will get the accurate value, because the compiler forces you to create a "multithreaded" class* for the counter.

4.) Go will typically consume 2x the RAM of an equivalent C++, Sappeur or Rust program, assuming something now trivial which performs heap allocations in a loop.

*each method of such a calls is protected by mutexes

No

The main reason for the creation of Sappeur and Rust was to eliminate the nasty bugs which come from a lack of memory safety. Also in multithreaded programs.

As cyber crime/war is now a very real thing, memory safety is an additional, very valuable security measure.

AWS unveils Graviton3 Arm chips and more. But the real story is the slide from IaaS to packaged solutions

A part of the cloud should be located in a fleet of microsatellites.

Alternative Clouds

Hetzner

OVH

1und1

Scaleway (Apple M1 !)

Oracle (x86, ARM, SPARC)

siteox (AIX, HPUX, Solaris)

IBM

Microsoft

Just to name a few. User should not shackle themselves to one corporation.