* Posts by Robot W

12 publicly visible posts • joined 2 Oct 2015

Campaigners claim 'Privacy Preserving Attribution' in Firefox does the opposite

Robot W

They are trying to do the right thing here

I know some of the senior technical folk who work (or worked) at Mozilla from their participations at IETF and they always seemed very privacy focused to me.

E.g., they wanted to use things like private relay when uploading telemetry data from the browser so that even their own backend systems cannot know where the data is being uploaded from (to mitigate the risk of a rogue employee being able to identify the source).

I think that these guys are genuinely trying to do the right thing and trying to find a fair balance between end users and the advertising industry. E.g., generally know how your adverts are performing without being able to track and individuals.

Dump C++ and in Rust you should trust, Five Eyes agencies urge

Robot W

Re: I must be a bit thick

For safe languages, at compile time, the compiler will either warn, or refuse to compile if the code is obviously incorrect or exhibits unexpected non-deterministic behaviour.

For quite a few of these languages, if the algorithm is fairly short/simple, perhaps say 30 lines or so, then there is a good chance that if it compiles then it is also correct.

But when you take an unsafe language like C, the programmer doesn't get those checks (although linters can help). The programmer *might* want to:

- read that uninitialized memory (maybe because they mistakenly believe that will inject some randomness)

- read the entry just before or after the array end.

- convert that pointer to a struct to a pointer to an Integer instead (I can't recall if the C standard mandates the structure layout, or if this is also not deteministic)

- concurrently modify that block of memory that it actually allocated and used by another part of the program (e.g., as a broken effort to signal some completion between threads)

- free that memory, but keep using it/accessing it anyway (perhaps they can just share it with another part of the program).

C gives you great power by very easily allowing you to achieve all of these things. Sometimes this may be want you want to achieve, but probably 99% of the time, this isn't what you want to do, and if you really do want to do that (e.g., memory map some hardware registers) it would be better to explicitly call that out in the code rather than just make it the assumed default behaviour.

I also often see the argument that smart people can be trained to write safe C code if they are good programmers, however there is statistical evidence that this is simply not the case, even the very best programmers make mistakes, and those mistakes can be very costly in the amount of time and effort it take to debug them, and also the cost to the poor person or organization that experiences the error. Errors that a safer language prevents you from ever making.

I've also only mostly listed some of the simple common issues in languages like C, as soon as you start trying to write and debug concurrent code your problems get magnified.

So, given the choice, I strongly prefer writing in a safe language, because more of my time and energy can go into solving the problem, and less time is spent trying to think about array bounds when compilers can reliably do that for you with no effort, and minimal runtime cost.

Robot W

Re: Capability

In the case of Java (or probably most languages targeted to the JVM), you could just get it be compiled to native code ... e.g., using GraalVM.

The resultant executable is normally a bit slower than running Java on the JVM (because you lose out on some of the JIT optimizations), but it greatly decreases the start up time and memory usage.

The biggest issue with Java is almost everything has to be an object, so it is less efficient in its memory usage, but there are efforts to improve that as well (see project Valhalla).

IPv6 is built to be better, but that's not the route to success

Robot W

Re: Won't happen in my lifetime

Its unclear what you think won't happen in your lifetime:

If the question is whether IPv4 will be turned off and not used anywhere then that seems unlikely.

If the question is whether the majority of public internet traffic runs over IPv6, then I suspect that is quite likely to happen over the next 10 years.

If you look at Google's IPv6 traffic over the last 10 years then it has gone from 0.4% in Jan 2012 to approx 36-38% in Jan 2022. Perhaps further growth will be slower, but it still seems likely that in 10 years time we will be at 65-70+% of Internet traffic reaching Google being over IPv6.

In terms of IETF, they work by rough consensus, so it would need an individual to submit a draft that states that IPv6 is a failure and that the IETF should work on an alternative internet protocol instead. Several individuals have tried (and some entities are trying to build "NewIP") but so far they seem to be a long way from gathering the sort of consensus that they would need to progress that work within the IETF, partly because it isn't clear what they are really trying to build or what problem they are really trying to solve.

Decade-old bug in Linux world's sudo can be abused by any logged-in user to gain root privileges

Robot W

Re: How is this possible?

I doubt that the mistake here was that the coder didn't know that they should be doing bounds checking.

The problem here is that:

(1) It is hard to to always get it right every single time.

(2) It is hard for a reviewer to easily spot whether or not the coder got it right. [Noting that nobody had spotted this bug for 10 years in security critical code!]

(3) You only need to get it wrong once and you potentially have a severe security flaw.

Note, there is an assumption that the language doing the bounds checking makes it slower, but it doesn't. It just means that the compiler always puts in the bounds checking code that the programmer should have been writing anyway. I.e. a decent compile will spot that the coder has already checked the bounds and hence it doesn't need to do it a second time.

It is also a fallacy to think that it is only poorly trained, or inexperienced, programmers that get this wrong, or folks that aren't smart enough. Everyone gets these sorts of things wrong at some point, the only difference is how often they make the mistake, and whether they find and mitigate the bug before attackers do. Otherwise the penalty is the same in all cases - your code is no longer secure, all for an issue that compilers can trivially get right for the coder.

Robot W

Re: How is this possible?

The fact the your comment has only 2 up votes and 18 down votes highlights the problem.

How can this not be a problem with the language? This bug was generically fixed at least 25 years ago. I.e., when was the last time that a programmer had memory corruption due to going past the end of a String (or Array) in Java, Go, Rust, Scala, Kotlin, Python, etc. They can't because the language/runtime prevents it from happening or raises an exception.

Where as in C, programmers (and code reviewers) are expected to get this right every time, further hampered by the fact that the standard C functions have different semantics as to whether they will null terminate a string, you don't know whether there should always be a null character to account for, etc.

Giving freedom to a programmer to write highly optimized code in the necessary places is okay, but making programmers manage string lengths in the mainline code is just poor design by modern programming language standards.

Most of the languages above would have allowed the argument checking to be written in shorter, more correct code, and given that the arguments are parsed once on program start they would have no meaningful performance impact.

The world has moved on, unfortunately C has not. It is perhaps also worth noting that the bounds checking C APIs don't really help solve the problem, e.g. see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm, where the concluding recommendation was they should be removed from the C standard.

Fuzzying, etc, can help, but still is not as good as making the problem impossible to happen in the first place.

But making a language that is really hard to always get right and then blaming the programmers when they occasionally get it wrong doesn't seem like a good path to reducing the frequency of severe security bugs in our programs.

When two tribes go to war... Intel, AMD tease new chips at Computex: Your spin-free summary

Robot W

Re: Definitely of Interest

Exactly. Because there is no market need to ship a 16 core part at this time.

It also allows them to release the 12 core part at $499 now, which also allows them to release a 16 core part at a slightly higher price later, perhaps $599.

Robot W

64 core Rome is expected to ship with 256Mb of L3 cache (32Mb per chiplet) + 512Kb/core L2 cache.

Microsoft pulls plug on IPv6-only Wi-Fi network over borked VPN fears

Robot W

Re: "IPv4-only hosts are unreachable without either a dual stack or an address translator"

My impression is that most (perhaps all) of the alternative ways to solve the IPv4 upgrade problem have been discussed extensively in IETF over the last decade or so. I'm pretty sure that your suggestion has been considered and already discarded for technical reasons, maybe because it has to retain a global routing table that is bloated with all the v4 entries.

Google to relieve HTC of its phones biz – report

Robot W
Alert

Re: Screw HTC, buy Wileyfox instead

Unfortunately, Google only promise 18 months of security updates after they stop selling a given phone model from their website.

I think that they should really provide a minimum of 4 years of security updates at the point that they stop selling a particular phone model.

I don't care if I'm not running the latest OS, but I do care if my device can be easily hacked.

At the feet of the Great Monad, or, How the functional programming craze plays out

Robot W

Re: Highly amusing to the cognosenti but utterly baffling to the rest of us.

I think that Functional Programming means different things to different people. I don't go in for the really abstract stuff.

As someone who has 20+ years of successfully writing professional C in embedded systems, then my view of functional programming is that it is generally a better way to more quickly write programs that are easier to understand and have far fewer problems.

If I try and sum it up in a nutshell, then it feels to me that imperative programming is generally about telling the computer *how* to manipulate some data, but functional programming is more about telling the computer *what* manipulation you want it to perform on the data.

You might think that this makes functional programs really slow, but its speed is comparable to imperative programs, e.g. A reasonable Scala program is generally within 3 times the speed of highly optimised C. And, by highly optimised, I mean that most professional C programmers would not choose to write the code that way, and other programmers needing to maintain it wouldn't be thanking them for it either.

Further, it is also my belief that it makes me a better C programmer because I start to think about things in different ways, and I try to write my code differently, so that it doesn't just work today, but so that it will work reliably (even when extended) in 20 years time.

Finally, I see that the best techniques of functional programming are making their way into main stream languages like Java, and the new crop of languages like Swift, Rust, etc are adopting even more functional principals, just because it makes programmers lives easier.

Perhaps google for "Programming in Scala" by Martin Odersky, Lex Spoon, and Bill Venners. The first edition is freely available online, and gives some access into functional programming from one of the people who is very much at the forefront of modern program language design ...

WIN a 6TB Western Digital Black hard drive with El Reg

Robot W

Computer scientists get close to solving the question: "If a tree falls in a forest and no one is around to hear it, does it make a sound?"