250k is not a bad investment for a company doing "reverse engineering as a service" - say 1k a pop to extract the firmware. Naturally, a good business idea for somewhere in the world with less regulations...
> Sure, but if you’re defending against a nation state actor hopefully you aren’t expecting a raspberry pi to keep you secure.
Is there anything about these techniques that are raspberry pi specific? It seems like they're using lasers to identify and flip particular bits in registers.
There are HSMs that are effectively immune to this attack by way of their construction and packaging. You need an optical path to the secure device. The only way to get at this is to tamper with the tamperproof part of the system.
Some very high end HSMs must be actively powered at all times which makes disturbances in their local environments detectable at all times as well. Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
> Getting lucky and drilling through a part of the enclosure that isn't directly protected won't help you if a barometric pressure sensor is tripped as a consequence of breaking the hermetic seal.
That's interesting. I suppose if that technology is in use, the attack would have to occur in a pressure-controlled chamber, so breaking the seal wouldn't cause a change in pressure.
In 5 years, either $400,000 or $50 and a hammer, depending on whether the core piece of the process aligns with the needs of some fast-growing consumer tech product like e.g. drones.
Very interesting. I spent a large part of my career in aerospace and never considered this failure mode before. It makes me wonder: how long is the pathological code allocation time? A few seconds, at most? We're talking about flight identification codes that are normally assigned upon takeoff and change at most a handful of times during a flight.
I assume the "manual request" is an aircraft squawking 7700 or similar, but why does the system need to interrupt an in-flight allocation in the first place? Any controllers here have insight?
One would think it would be sufficient to do something single threaded like
there will be some other tasks in the system that need time guarantees around when they get scheduled for very important (safety?) reasons. so when these higher priority tasks show up the lower priority tasks get suspended.
if they could guarantee hard bounds on how long low priority tasks take to complete they could implement your scheduling algorithm. but i think in reality the low priority tasks are either not boundable or they if they do have a provable bound the bound is too high.
In the Before Times, the vast majority of software was written in garbage collected language where a working knowledge of the relative merits of C memory allocators is not useful or particularly relevant.
Why would the scads of people writing JavaScript, Java, python, go, rails, etc need to be aware of jemalloc?
Memory allocation behaviour has visible impact also for users of managed languages, and the behaviour of software for end users.
In our Python program, a bit of numpy processing of large pictures led to 100 GB not being returned to the OS by glibc's default allocator and the machine running out of memory shortly after. With jemalloc's reliable memory return settings, those problems disappear.
I'm in the same boat, I just switched to using it for Kavita, which only does some basic open Image -> Thumbnail to smaller size -> write to disk when importing new comics/books and on linux, memory could swell to 10GB and never get released. Switched to jemalloc and instantly memory stayed well below 1GB.
Generally yes, but the wording of "instantly" begs for the following pedantic remark:
This is controlled by jemalloc settings `dirty_decay_ms`, `muzzy_decay_ms`, and their interaction with `background_thread`.
`dirty_decay_ms` currently defaults to 10 seconds, so it's not that instant.
That is important e.g. for single-threaded programs that start other programs, such as my Python example: If it starts a subprocess before the 10 seconds elapse after `free()`, Python (and jemalloc) do not run, and get no chance to return memory to the OS.
In such cases, either enable `background_thread`, or set the `_decay_` values to `0` to ensure immediate return to the OS upon `free()`. (This costs some performance.)
>...the vast majority of software was written in garbage collected language
and even then recently it costed (us) quite a few months to blame JVM and later the default glibc memory allocator for running out native (not java heap memory) - had to exclude all possible native libs (zlib, zstd via jna), direct buffers, sockets, thread stacks and so on. Changing the malloc to jemalloc solved the issue, even though initially it was done for its debugging capabilities.
I'm never sure if I should be upset or happy when I've been debugging a problem for long enough that I finally decide to switch something out in order to improve visibility and that immediately solves the problem for entirely unexpected reasons. Particularly all the times when I couldn't readily discern why.
Because unfortunately, the runtimes belonging to all or at least most of those languages perform a lot better with jemalloc than with the system default.
TL;DR: Because the runtime of most GC:d languages uses malloc for its internal data structures.
I work for the runtime team of JPG @ Oracle. We use malloc in Hotspot, quite a lot actually! Providing your JVM with a good malloc can improve the performance of the runtime, both in terms of CPU and memory, by quite a bit.
I don't think you need the details, but it's good to be aware that some mallocs are better than others, and there are multiple of them. Being aware of jemalloc is a good way of being aware of the facts I just mentioned :-).
The vast majority of professional developers are not in a position where they can just swap out allocators willy-nilly. They take what they get, and write the code they're assigned to write on the platform the CTO or their product lead or whoever has decided upon.
Okay, well, I guess all I can say is that if you strive to be one of the developers who do get the chance to care about this stuff, then you should know this stuff :-).
Because it's literally the least impressive thing you can build and in a world where I don't write the code anyway, a "hello world" example has lost its place (at least for human viewers).
It demonstrates CRUD at a small scale and is familiar, so we don't need to figure out what it's trying to demonstrate. It allows us to see how large the final product is and how much memory and CPU it uses.
It's not meant to be a showcase of what you can build with it; it's meant to give you the smallest complete application so you can get a good idea of what you need to know.
The thing that's meant to be a showcase is usually referred to as a Showcase or a Gallery.
Can't vouch for that but I can vouch for `Dreyer's English` as both hilarious (if you're the sort of person who relishes finding le mot juste, like me) and excellent as a style guide.
There are two visually similar sails. Some are rotating tubes that generate lift via the Magnus effect and even though they create low pressure zones, those are not “suction sails”, strictly speaking.
A suction sail is a more or less conventional airfoil that houses an axial compressor to basically suck in air which causes the boundary layer to stay attached which generates lift via the same mechanisms as an aircraft wing.
From a distance and to a casual observer they’re pretty similar.
TFA is the aerospace equivalent of rolling your own crypto. Outsiders often don’t know what they don’t know, resulting in fatally-naive “solutions” to the problems.
No it's not. It's an interesting article on how to use scikit-decide to optimise a problem. Nothing more.
Rolling your own crypto is considered bad practice because there are countless battle proven open source alternatives. Where are the open source alternatives for aircraft route optimisation that the article could talk about instead? And it would be a totally different article if it was talking about how to use them. This is an article about using optimisation tools to target a specific problem. Aircraft routing is just the example.
Not super practical, but neat attack
reply