Posts by AdamWill 1611 publicly visible posts • joined 4 Nov 2010
"Surely standard security updates are common code across all devices?"
Nope, not really, due to the fact that the boundaries between 'what Google looks after', 'what manufacturers look after', and 'what third parties like driver vendors look after' have always been terribly fuzzy in Androidland; there just isn't a reliable shared core bit of Android in all Android phones which Google can update directly and which no one else touches. Phone manufacturers cook up their own system images from the Android sources and all sorts of other bits, and then it's up to them to re-build the things with updated Android components when Google sends updates out to the Android trees. If the manufacturers don't, you're just not getting those updates (unless you run a third-party ROM).
Android One is (in part) an attempt to address this, but there aren't many Android One devices available outside the developing world, and they aren't that desirable.
These are all good principles to apply if you're a pedestrian interested in staying alive. However, in the case that a pedestrian *doesn't* apply them, that does not automatically excuse the driver (human or robot) that hits them, if they could have reasonably avoided doing so. Death is not the legally mandated punishment for jaywalking, nor is Joe Random Person/Robot Driving By the legally mandated agency of punishment for jaywalking.
"eth0 *is* the unpredictable name"
having watched this play out for several years, my conclusion is this: there's two different sets of people meaning different things by 'predictable'.
what things like udev 'predictable' names, biosdevname etc. mean by 'predictable' - what they're trying to achieve - is something like "each specific network adapter in this machine will always have the same name". The problem they were trying to fix is something like "I have six ethernet adapters in this machine, and I can't guarantee which one will be eth2 and which will be eth5 on any given boot".
The problem is that more or less anything you can do to make interface names *more* predictable in that sense, makes them *less* predictable in a different sense. This is the sense that "on any given machine with one network adapter - I don't care what model it is, or what slot it's in, or what bus it's attached to - that adapter will be eth0". Which turns out to be a sense of "predictable" that a *different* group of people were relying on.
In conclusion, software sucks and we should all go buy yak farms.
"The famed politeness of Canadians was put to the test on Monday after the nation's largest airline suffered a massive computer outage, leaving travelers stranded."
You'd be hard pressed to identify the famed politeness of Canadians in just about anyone working for Air Canada anyway, in my experience. Much better off on Westjet...
It's hosted IRC (so you don't have to teach people to run proxies) with an API. That's about it. That's a useful thing. It's not revolutionary.
What's happening in some companies is that it becomes used so widely that all sorts of stuff which really isn't part of its job at all is being bolted into it, because it's as convenient a place as any.
This then becomes one of those "it works fine until it doesn't" things, as the article actually did a good job of covering. If not done carefully, all those random little bits getting built on top of Slack can also be seen as a gigantic pile of tech debt that's going to cause all sorts of pain a few years down the road, when there's so many of them no-one quite remembers how they all work together any more, or even what some of them were for, or what the consequences are when they go wrong, or how to fix them...
The fact that you have now tied your business to a hosted platform with extremely questionable terms of service (last I checked, they still reserve the right to delete all your data at any time with no notice and for any reason; yes, also for paid customers) is just the cherry on top.
There are F/OSS alternatives that are worth looking into if you think the basic idea is a sound one (which, really, it is: there is nothing particularly *great* about IRC, it's a creaky antiquated protocol, and it certainly *can* be done better), like RocketChat and MatterMost.
"Apologies for asking silly questions, but what are the options for Swift owners? Can it be updated from another source, or switched to a different operating system?"
There are official LineageOS ROMs for the Swift - https://download.lineageos.org/crackling - and Storm - https://download.lineageos.org/kipper .
There are other ROMs for the Swift 2 at xda-developers: https://forum.xda-developers.com/swift-2/development (Swift 2, has an unofficial LOS 14.1 ROM last updated in September)
xda-developers device-specific forums should also have instructions on bootloader unlocking (if they didn't ship unlocked, I don't know), recovery install and ROM flashing, it's not that hard but make sure to follow the instructions carefully if you've never done it before (or even if you have!)
Dunno about any other models.
waitaminute, what is this administrator bloke on about?
"...in terms of distributing monies outside of Russia, that tap was proverbially turned off."
I mean...that's a very odd placement of "proverbially", there. The turning off is proverbial, fine, but the tap isn't? Is he telling us there's an actual physical Russian money tap somewhere - and one which has only *proverbially* been turned off? Inquiring minds want to know!
"Maybe we should put the onus on asylum seekers to provide evidence to prove their cases, and stop trying so hard to help them?"
We *do* put exactly that onus on asylum seekers. This asylum seeker *did* provide the evidence. Then the immigration service decided it wasn't sure it believed them, so it sent the documents *to the government of the country the poor sod was trying to escape from* for "verification". That is what the case is about.
Does anyone know precisely how much of your soul you have to sacrifice to the devil before you'll understand this?
"Some 6,000 of GTS people (g & h) are to be moved to help IBM cut costs as it tries to in-source or eliminate vended services and in-source subK (sub-contractor) roles. The company wants to stop hiring cross-company resource and external services, a contact told us."
I mean...wot?
Just in case anyone was waiting for an update: seems that so long as this is just second-hand news about internal IBM documents, we don't want to comment on it. Of course, if you're a paying RH customer and you're concerned about the consequences of updating any of your systems, please contact the relevant support folks and they'll certainly be able to help you with it.
I'm not disagreeing with you. But what I was really commenting on here was the *journalism*, not Intel's quote.
The Intel quote isn't new - it's been quoted and referenced tons of times, including in at least three Reg articles. So anyone who's paying attention has already seen it. El Reg has also already explained, more than once, how it's more than a tad disingenuous. So when El Reg prints a *new* article, includes the quote *again*, and surrounds it with text like:
"The patches being put in place to address the Meltdown and Spectre bugs that affect most modern CPUs were supposed be airy little things of no consequence. Instead, for some unlucky people, they're anchors."
that reads to me like El Reg is suggesting something new - either that they can now somehow show that far more cases are going to affected than we previously thought (i.e. there are, for some reason, more syscall-dependent workloads out there than had previously been realized), or that Intel had claimed that the fixes wouldn't significantly affect performance for *anyone*.
Yet in the end the article does neither - it just adds some random field reports of what we essentially already knew, i.e. that there *is* a significant performance impact on syscall-dependent workloads.
That's not valueless, but it doesn't really pay off such a dramatic introduction, or justify the "airy little things of no value" line. That's what I was questioning.
Three thumbs down, yet no counterpoints. Interesting.
I'm not saying Intel's exactly being *up front*, here. But the story is more or less accusing them of *outright lying*, without backing it up. Intel says the impacts are "workload-dependent" and won't be significant to "the average computer user". Which, sure, is a very spin-ny way of saying they *will* be significant to workloads which *aren't* those of "the average computer user". But it's not actually a lie, and nothing the article presents as evidence actually contradicts it. In fact, the article agrees with it, explicitly, in the quote I pulled.
Also, this is clearly silly:
"Via Twitter, Francis Wolinski, a data scientist with Paris-based Blueprint Strategy, noted that Python slowed significantly (about 37 per cent) after applying the Meltdown patch for Windows 7."
Python is a *programming language*. (OK, it can also mean a particular interpreter for that language, but it makes no practical difference; the performance characteristics of the interpreter depend on the code it's interpreting). You can write something in it that does a lot of syscalls, or something that does very few syscalls. It makes no sense to suggest that "Python", as a single thing, can be slowed down by a single amount by these changes.
Also weird, the graph claimed to be "An example AWS CPU utilization spike after installing CPU flaw" - the change described as a 'spike' (which, uh, isn't a spike) appears to be on 2017-12-22, which is two weeks before all this stuff came out. I haven't seen any suggestion that Amazon was patching AWS in December. Also, the change doesn't look at all like something you'd expect to be caused by the Meltdown patch: it seems like the instance suddenly started "idling" at about 59% CPU usage for some reason, instead of idling close to 0%. I've no idea what'd cause that, but it doesn't seem to match the characteristics ascribed to the Meltdown fix at all.
So, uh. Intel said:
"Intel said as much in its statement, claiming "any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.""
and then you said:
"While most casual desktop users and gamers won't notice any prolonged slowdown, or any performance hit at all, people running IO or system-call intensive software, such as databases on backend servers, may notice the difference."
So...where exactly are you claiming that Intel was wrong, or misleading? Or are you suggesting that "average computer users" are running "databases on backend servers"?
...that's also terrible for VMs. you know, the things in which most of the world's really critical applications are currently running.
but don't worry, this is fine. everything's going to be fine. now excuse me while I go take all my money out of the bank and start fortifying my secret bunker in the woods...
"While Apple is no doubt super seriously considering this shareholder memo, perhaps concerned parents could, oh, we dunno, try a little parenting?"
The measures the groups suggest are actually intended to *enable* parents to parent. Right now, they have two fairly crappy choices:
1) try not to let Junior have a smartphone at all
2) let Junior have a smartphone with essentially no ability to control how Junior uses it
1) is difficult because kids really, really, really want smartphones, there are actual genuine reasons why it might be a good idea for kids to have them for *some* purposes, and given that the world is the way it is, at *some* point kids are going to have to figure out how to use one, and 18 probably isn't the best age for that. Plus lots of other reasons. 2) is crappy because it's very difficult for a parent to effectively control how a kid uses a smartphone, once they have one, without being hilariously invasive.
The measures proposed by the shareholder groups, honestly, seem pretty damn sensible to me: they're asking Apple to implement more advanced parental controls that will make it possible for parents to let kids have smartphones, but exercise more control over how and when they're allowed to use them. I don't really see how this is particularly objectionable, and it's something Apple could quite practically achieve.
"Has anyone actually tested Sparc processors for these vulnerabilities? And what about PowerPC or MIPS?"
Well, not sure about Sparc or MIPS, but PowerPC, yes:
"Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian)." - https://access.redhat.com/security/vulnerabilities/speculativeexecution
This is very definitely a real thing; we have some extremely good engineers internally at Red Hat who've spent the last several months working on this. If they say they have a PoC on Power, they do.
"It may be selecting to move a pawn, or knight, or queen across the board, but it doesn't learn the logical and strategic thinking useful for Go."
It sounds like the author is about as good at learning the actual rules of games as AI is, since you're not going to get very far in Go if you try to "move a pawn, or knight, or queen across the board"...:P
"Your both asking the questions I'm interested in !!!"
The disabling of PTI (and associated performance impact) does not happen on AMD CPUs, in the Linux kernel fixes at least (can't speak to other affected OSes).
"from what was in the article it seemed as if the researcher's were going out of their way to make it work on AMD"
Rather the opposite, at least so far as Google's team is concerned: they state in their post "Our research was relatively Haswell-centric so far. It would be interesting to see details e.g. on how the branch prediction of other modern processors works and how well it can be attacked." They did test their PoC exploits against AMD CPUs, and state how badly they are affected by each one, but they appear to have focused on Haswell's design in actually *developing* the attacks.
"A better question to ask is what other flaws has Intel been hiding from us? They apparently knew about this for awhile. Evidence from Linux sources show as much since July or so when the developers started working on the fix."
You, uh, realize this is how security *works*, right?
When responsible researchers discover an issue they don't just immediately go and plaster it all over the press. They disclose it to other relevant parties, behind what's called an embargo, which basically means everyone agrees not to go and tell the press about it.
Then all the relevant parties work together to come up with a comprehensive fix. *Then* they ship the fix and declare the vulnerability once everything is nicely lined up.
If they *don't* do this you have a zero-day vuln - where the vuln is publicly disclosed, but no *fix* is yet available - which is a very bad thing. Embargoes and delayed disclosure exist precisely to prevent this happening.
The reason this issue was still embargoed is that fixing/mitigating it is complex and requires co-ordination among many parties, because it can't just be conveniently fixed in one place. People were busy lining up comprehensive fixes to various OS kernels and to things like web browsers to try and prevent exploitation via malicious scripts.
Whichever numpty went and prematurely blew the gaff to the press has caused a whole ugly mess, particularly since they didn't really do a very good job of explaining it, leading to lots of coverage which is confusing one specific exploit variant (that is Intel-only) with the entire class of potential exploits (which is certainly *not* Intel-only; weaponizable exploits are already known to exist for Intel, ARM, s390 and PPC CPUs, and for AMD CPUs with a non-default Linux kernel configuration, and it seems extremely naive to believe there won't be *more* along very soon).
It doesn't really matter that they're single user, since obvious attacks for something like this include root privilege escalation, and escape from isolation mechanisms like VMs and containers. And simply apps reading stuff from other apps which they're not supposed to be able to (like some Javascript in your browser being able to poke around anything else that happens to be running on your system).
"Fedora has gotten increasingly buggy / hard to install / hard to get updates for several months now.
It has gotten where I keep thinking they are going to make some awesome new release, but really it is that they are focused on commercial customers- aka "paying" customers."
I'm sorry if you've been having trouble, but I can tell you your diagnosis of the cause is not accurate. There hasn't been any significant reduction in the resources RH devotes to Fedora for the last "several months" (or in fact, years); the number of folks working on Fedora is actually growing modestly. It's a fairly small team, but it's certainly not worse than it used to be.
So far as "hard to get updates" goes, there *has* been a change here which may be what you're seeing: we have been implementing a policy called 'batched updates', which is basically aimed at reducing the frequency with which non-critical updates appear, so you're not constantly being prompted to install updates. In practical terms what's changed is that the 'default' flow for package maintainers is now that when you think an update is ready to go, you "submit it to batched", which means it goes into a sort of queue; once a week (I think it's once a week) all the updates in the "batched" queue get sent out together. Previously, as a package maintainer, when you thought an update was ready to go out, you would "submit it to stable", meaning it'd be sent out with the very next update refresh (these usually happen once a day).
Maintainers *can* still submit updates directly to stable, and security updates and other critical fixes are still sent out this way. But we're sort of 'nudged' to submit to batched by default in the tooling.
Beyond that, if you like, please do feel free to drop me a line (awilliam at the domain you'd expect for a Red Hat employee...) about whatever bugs you're running into, and I'll see if I can help out with any of them. Sorry again for any trouble you're having.
"Then perhaps you should start taking the Apple route, at least partially, and say only such and such hardware can be certain to work and the rest are just CE-YOYO. If you can't test everything, say so and say so VERY CLEARLY so they either get it or get classed as Darwin Award candidates."
Well, this sort of is what happens, at some levels: mainly the levels where people pay distributors money :) The major enterprise distros like RHEL and SLES do have hardware certification programs, and those certainly are backed by testing: if a RHEL or SLES release is certified on some piece of hardware, that isn't just an empty sticker, it means RH or SUSE really did do some pretty extensive testing on that hardware (and of course there are very real, contract-based consequences if stuff goes wrong very badly on it).
At the level of a distro like Fedora, though, things aren't really that clear. There's in fact an idea to take a modest step in this direction; there's a group of folks who would like to nominate some particular laptop model (or series) and commit to doing much more extensive testing on that specific model, then publicize this effort and say "if you want a better chance of everything working really well, buy this laptop". But I don't think (personal opinion, here) distros like Fedora can ultimately go too far down this path. It's just not what people seem to really _want_ from a typical community Linux distro; it seems like people really do want us to ship them all the bits relatively quickly, do whatever level of testing we can fit in, and then run it on absolutely any old bit of hardware they have lying around. You've got to adjust your approach to what it is people actually seem to want of you. And of course it's not practical for a community Linux distro to go *full* Apple and actually build and ship hardware, or even tie up very tightly with a hardware manufacturer, so you're always going to be somewhat at the mercy of a party that doesn't have much interest in you, trying this approach; what if you go all-in supporting some specific hardware model line, and then the manufacturer discontinues it?
I - again, personal opinion - generally agree with you in terms of being clear about stuff like this...which is why I write comments like this. I generally want to level with people, including when we just flat out screw stuff up, or when a task is just too big to be realistically possible. On a personal level, I hope if you check what I've written around the net before, I'm pretty open about things like this.
Well, I'm not sure that's the full story. It sounds something like the affected hardware has an issue where once the flag is flipped to non-writeable, *it can't be flipped back*. I'm not 100% sure on this, but that's what it sounds like from the description.
So these two issues combine in a rather...unfortunate way on the affected systems.
Depends if the kernel includes the intel-spi driver (either builtin or as a module). The config item is called 'SPI_INTEL_SPI_PCI', you can check the kernel config for that.
Ubuntu built it as a module and shipped it in their kernel package. Fedora does not enable it on any branch at present. I dunno about other distros.
I can speak to one of your questions with some authority, this one:
"2.) How can an OS (or any other significant s/w) update get into release without it having been tried on a good range of commonly sold machines?"
as I'm more or less in charge of QA for an OS (Fedora).
So, there's two key points to make in answering the question. One, what exactly is "a good range of commonly sold machines"?
The number of bits of PC hardware out there is probably literally uncountable. It's difficult to overstate just *how much goddamn hardware* is out there. Even if you say "well, Lenovo laptops seems like a reasonable subset to cover, how many of those can there be?", the answer is *still* tens of thousands, counting all the variants on all the base models they've sold in all geos over the years. So even just this part is...incredibly difficult. Especially for a relatively small OS, like Ubuntu or Fedora, which releases rapidly (we both release every six months). It is, practically speaking, an inescapable truth as a small QA team for a rapidly-releasing OS that there will be quite popular hardware you don't test on. There's just too damn much PC hardware out there.
I dunno the specifics for Ubuntu, but for Fedora for e.g., we have about 10 full-time paid QA staff, plus community volunteers. At a very rough guess, I'd say each Fedora release has probably been run on a few thousand different systems before it's released. But after it's released, it probably gets run on something like 100x or 1000x more hardware than it was tested on. There's just no realistic way to 'solve' this. It's always going to be a problem unless you make like Apple and say "we are only going to support a very small number of systems that we engineered ourselves".
Bigger, slower-moving OSes like Windows and RHEL can do *better* here, but they still can't be anywhere close to perfect.
Secondly, there's the specific failure mode here: what happens, AIUI, is that the system firmware effectively gets placed in a read-only mode, notably meaning EFI variables like the boot order can't be changed. But that's not a particularly *obvious* failure mode. If your test is "install the OS, check it works", then your test would *pass* on an affected system. You're only going to catch this failure if your test is "install the OS, check it works, then try and change the system's firmware settings in some way".
Which sounds like a reasonable test, and sure, it *is*. But there are thousands of potential 'reasonable tests' you could perform on any given bit of hardware - work in QA for six months and you personally will have a list far longer than you'll ever have time to run. And again, an OS releasing on a six month cycle with a QA team that doesn't number in the hundreds of thousands *absolutely does not have the ability* to perform all those 'reasonable tests' on all the hardware the OS might get used on. Or even a reasonable subset of the tests, on a reasonable subset of the hardware.
Frankly, trying to QA an operating system at all is like trying to bottle the ocean in an eye-dropper. Trying to QA one that releases every six months with a small team is more or less an exercise in futility. I have an awful lot of sympathy for my counterparts at Ubuntu on this one. We (OSes) have all had fuckups like this before - Ubuntu, other Linux distros, Windows. I remember the kernel code that could brick some CD/DVD drives, thanks to a bad interaction between some perfectly reasonable code in the driver and an appalling choice made by the firmware implementation for those drives, for instance. To be entirely frank, I'm really only astonished this stuff doesn't happen *more often*. (I have a theory that the longer you work in QA the more surprised you are that anything works at all...)
"If it's Lenovo's crappy implementation of the UEFI standard that triggers this issue, then they certainly should be liable for it."
AIUI this has nothing to do with UEFI or any particular implementation of UEFI. This is about SPI, which is an Intel mechanism for messing around with the firmware on Intel hardware, regardless of what that firmware actually *is* (it doesn't matter who wrote the firmware, or what the contents of the firmware are, or what firmware standards the firmware does or does not implement). IMBW, but that's what I got from reading the docs.
Intel created this SPI thing, and Intel wrote the kernel driver for it. Canonical then chose to build and ship that driver in Ubuntu; at least some other distros did not choose to do that (I haven't checked any except Fedora, which does *not* include it).
"However, the fact that it's not a part of the default configuration and that it warns you explicitly not to do it is a defence however, which seems to be what has happened."
That's written in reference to *Ubuntu*, not the user, AIUI. It was Ubuntu's choice to build the module and ship it in their kernel package. Once the module is built and included, it will be automatically loaded on hardware it supports. The user would have to explicitly remove or blacklist the module to prevent this, and there's no reason why any typical Ubuntu user would have done that.
The driver is in the upstream kernel tree, which means it's up to distributions to decide whether or not to build it in their kernel package build, and if they decide to build it as a module, how to ship that module (in the main kernel package, in some sort of optional package, etc).
A large part of the job of distro kernel maintainers is keeping track of all the things like this that are in the kernel and deciding how to handle them.
At the upstream kernel level, I don't think it *is* enabled 'by default' (though exactly what 'by default' means can be a complex question when it comes to kernel compilation). It was Ubuntu's decision to build the module and include it in their kernel package. At least some other distros don't (e.g. Fedora, I just checked).
"That said, I don't think this is a really either Windows or Linux issue. I think the blame rests squarely with bloated UEFI design"
This isn't actually about UEFI at all. It's a level lower than that. This is a mechanism Intel designed to allow modification of the firmware from the OS *regardless what that firmware is* - it could be a UEFI firmware or some entirely different type of firmware. This SPI mechanism isn't part of the UEFI spec, nor (AIUI) can the implementer of the firmware *itself* really affect anything the SPI mechanism can do.
There's an explanation of SPI in the documentation for it in the kernel: https://github.com/torvalds/linux/blob/master/Documentation/mtd/intel-spi.txt
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
