The AS/400 nowadays is called "IBM i". The note says IBM i is affected: "AIX and i operating system patches will start to become available February 12".
Since the mid-1990s it has run on POWER so if POWER is affected it obviously would be too.
I dont find something mentioning Spectre or Meltdown in the original blog post fom IBM, but POWER 6 (2007) is most probably not affected by Metdown as it is an in-order architecture.
Well, if you consider PASE lets you run AIX binaries, if it is exploitable on AIX the same exploit would probably work on IBM i. (PASE only supports a subset of AIX system calls though.)
Also, if it is exploitable from Java, nowadays the IBM i JVM is J9, almost the same as AIX. (This used to be different – the "Classic JVM" was integrated into the TIMI infrastructure, so quite different from JVMs on other platforms.)
I'm more interested in the non-PASE (more accurately, non-Teraspace) situation. The single level store maps every program into the same address space. Will POWER speculatively access another user's data before it discovers that the pointer is invalid or the array index is out of range?
Its called IBM System i nowadays, and hasn't been called AS/400 since 2000 [1].
FTA: "We will provide further communication on supported generations prior to POWER7+, including firmware patches and availability."
POWER7+ is used in since 2012. They all seem to be based on POWER architecture these days (first devices using PowerPC/POWER3 in 1997).
Also of note, the firmware patches will be available on jan 9 but they also require OS patches. The Linux patches will be available on jan 9 and the AIX patches arrive on feb 12. They don't mention IBM i (OS/400) at all.
> If this vulnerability poses a risk to your environment, the first line of defense is the firewalls and security tools that most organizations already have in place.
AS/400 attacks are a whole next level of interest after first wave of Spectre on Intel/AMD etc.
This is a much bigger can of worms than any vendor is admitting to right now. Those documented Spectre attacks were crafted by a handful of researchers - the world knows about the class of attack now - it'll be months or years before mitigation is fully understood - if mitigation is even possible.
You can guarantee there are a lot more people are looking to exploit than fix right now.
The only way to exploit these vulnerabilities is to run code on target machines. If that's not possible then the vulnerability is irrelevant. Using firewalls to keep attackers away from your vulnerable machines is a viable strategy in this case.
Conventional thinking is that if a malicious user can run code on your system, you've lost. In that sense, this is just another local exploit, of which there are many.
This includes fully sandboxed code, however, which is an important distinction. The fact that a driveby javascript exploit could potentially result in leaking every important secret from your system (logins, encryption keys, what-have-you) is why people are taking this so seriously.
I assume exploitability through javascript depends very strongly on how the browser treats it. If it's jit-ed to optimal machine code it should be easy. If it's interpreted it should be harder.
So question is, can the Javascript engine generate suboptimal but safe machine code?
Algorithmically is it possible to pass only 'safe' interpreted code to the CPU? The majority of Javacript engines (Chakra, V8, Spidemonkey and JavasciptCore) are under a security-auditable FOSS license. Browsers claiming Spectre/Meltdown immunity would be in the next release notes, surely.
I'm not discounting that CPUs should operate correctly into the future but the current sandboxes would seem to rely on whims of a CPU's microcode. And the question for browser makers is whether to trust them.
Its not about algorithms. The issue is mentioned in the paper: even if the cache-based side channels are stopped (lets say, by manually clearing any cached memory as soon as its accessed, reducing performance to 0.1% of what it is now) there are other potential side channels like through limited CPU resources. A lot of the "fixes" might just be mitigations, that don't solve the problem entirely, but make it take much longer. Maybe you can cover up enough holes, and make the timers available poor enough that it takes a few hours or days to read a single byte. In other words, mitigations to make things less simple.
I think they're imagining situations where an attacker could gain user-level access to a machine that normally wouldn't be accessible to them at all, e.g. a web server with a weak SSH login.
> and Meltdown only affects Intel processors as far as we know.
I made a post stating the same, but this is not true [1]:
ARM has reported that the majority of their processors are not vulnerable, and published a list of the specific processors that are affected. However, the ARM Cortex-A75 core is affected directly by the Meltdown vulnerability, and cores Cortex-A15, Cortex-A57, and Cortex-A72 are affected by variations of the Meltdown vulnerability. This contradicts some early statements made about the Meltdown vulnerability as being Intel only.
A large portion of the current mid-range Android handsets use the Cortex-A53 or Cortex-A55 in an octa-core arrangement and are not affected by either the Meltdown or Specter vulnerability as they don't do out-of-order execution. This includes devices with the Qualcomm Snapdragon 630, Snapdragon 626, Snapdragon 625, and all Snapdragon 4xx processors based on A53 or A55 cores.
Edit: I'm referring to the System/38 architecture that used capability-based addressing.