ATM operators eye Linux as alternative to Windows XP | Hacker News Reader

ATM operators eye Linux as alternative to Windows XP

computerworld.com

136 pointsgphilip124 comments

The main factor here is probably not the technology of Windows XP (which certainly is up-to-par for the problem at hand), but the possibilities of vendors to absolutely custom-tailor a computer OS, stripped down to the bare minimum of running the ATM, and, if necessary provide all the service needed, down to the kernel.

And currently it's pretty easy to do this, with build-scripts and infrastructure in place. Maybe even using a tailored Android?

But then I somehow doubt that the industry would take that opportunity: I've seem my share of "embedded" devices (signage, control-room-displays) where the vendor just slapped their proprietary .exe in Autostart and left the Vendor supplied Win-XP + Nagware + never-updated-virus-scanner + ... intact.

Why? Because people in industry are lazy (they should be, maximizing their ROI, doing as little own work), and so going the same route, but with an 8 year old Ubuntu will not gain anything.

The main factor here seems to be hardware cost of upgrading to a newer version of Windows. Since Linux can run on older hardware, it is a cost-effective solution (in spite of the cost of developing a new solution).

Also, I didn't get your remark about "8 year old Ubuntu". Why not a newer QT based Ubuntu?

Embedded systems are typically not upgraded. There are still plenty of PoS terminals, ATMs etc out there that still run OS/2.

Whether that's a serious problem depends on how connected they are. If they run only a application-specific set of services on an isolated network, that's not a problem. but if you propose to sell POS terminals in an Internet SaaS model, you can't leave them unpatched.

It's always amazed me that they used Windows. Why would an ATM ever need a full blown OS like that? The requirements are totally different from a desktop PC.

Largely because many of them need to display advertisements these days. I've seen ATMs in gas stations that were displaying ads for the type of stuff you'd find in a gas station/convenience store. The rest I've seen advertising services of the bank they are attached to.

Assuming the developers had half a clue, they don't. They run Windows XP Embedded which can be stripped back to just the kernel and a serial terminal if necessary. It's not like they take a retail XP CDROM and installed it (of course, in the absence of clue this works too...)

I guess that's because back in the 90s there were no practical alternatives to NT and OS/2, then NT4 won. XP was an obvious migration path for the old NT embedded software.

I've done that with hardware that got installed in a factory.

Why not? You pay a one-time, small license fee, you get years of free support from a major company, I don't have to document all the details of my stripped down kernel and how to recreate it, you can hire anybody off the street to work on it long after I am gone (and I am long gone from that company, but the hardware lives on), they didn't have to pay me to build out a unique OS, the low power computer we had could more than handle XP, there was (and continues to be) continued new, unknown requirements and upgrades, the people required to occasionally touch the interface had more PC experience than for any embedded or linux OS, and on and on.

Why wouldn't I slap a copy of XP on there? Well, this story is the counter-argument, of course. I still think it was the right decision.

They took the path of least resistance and it paid off until now. Now that path is a dead end and they face a painful upgrade. But arguably it was still worth it in the long run.

This seems the most salient point. At some point someone said "What if XP isn't supported?" and someone else said "Well we'll deal with that when it comes, but for now we've got a product to ship."

It is not necessarily a full-blown XP - it might be XP Embedded, which looks like XP, but is highly componentized to reduce requirements to the hardware or improve on security.

In either case, I don't understand why ATM industry should be pissed - it's not that they were patching ATMs on a regular basis... In case of XP Embedded the patching story is even more convoluted.

I'm torn between this. On one hand I think you're absolutely right about the possibilities of ATM's and other vendors running a custom tailored OS. On the other, I know first hand how big companies screw up security on very basic levels -- And I don't think I trust the same people who still have an infrastructure built on Windows XP to custom tailor that OS securely.

>> I've seem my share of "embedded" devices (signage, control-room-displays) where the vendor just slapped their proprietary .exe in Autostart and left the Vendor supplied Win-XP + Nagware + never-updated-virus-scanner + ... intact.

This is what scares me. This happens so often and so frequent. I know it may be a shock to HN, but huge amounts of "embedded devices" are built this way. I for one would love to see custom tailored Android or linux -- but I'll say it again -- I really really do not trust them to do it right. Sorry to start the day pessimistically. :)

If they would work together on some FOSS frontend ATM software, probably on top of boot to QT, they could easily have one mutual firm package installer images for some minimalist system that just auto updates itself in the background as a rolling release. It could even use those "hot kernel" patches from Red Hat and the auto-reinit cycle of systemd to always keep those two up to date as well without rebooting.

Embedded manufacturers have to deal with parts going out of production all the time. Say that Chinese LCD display you were using has suddenly gone end-of-life and hey, here's a replacement that fits our housing exactly but - oops- it looks like the driver needs a slightly different timing spec and color layout.

The WinXP users are in the same boat as the Ubuntu users - someone is going to need to update that video driver and smooth that new software into the production run without tanking machines that are already out there. Service techs HATE having to deal with 24 different flavors of the same circuit board and crossing their fingers they updated the right file onto the correct board.

So yeah it's lazy that relying on Windows to handle all that lifting but, hey guess what, there's a lot better chance someone has a Windows driver for that new display that the Ubuntu crowd does.

Android has a lot of potential for embedded GUI usage (I'm doing it myself) but the driver stack integration is a LOT tighter than slapping another DLL into the mix.

They should just go straight to Android - nice touchscreen drivers, 3G, that Dalvik thing - what more is needed apart from a few device drivers to spit the money out?

I must say I really agree on this one; solid coding environment made for touch, energy friendly, small footprint, easy to use, lot of programmers. But... Is there actually a company who does support for it? As I understand that's not Google. I mean they develop on it, but who can I call/contact 24/7 with issues? So someone needs to do that anyway.

If I would be into POS systems still they would be Android anyway. Makes all the sense in the world.

Yes, there are multiple systems integrators who can create and support embedded Android devices. It's not too complicated to keep up with AOSP if you didn't go overboard with OS mods.

Clever suggestion! Android seems perfect, almost as if it was made for ATMs. Plus, it is based on Linux, which is extremely secure.

> Plus, it is based on Linux, which is extremely secure.

Linux the kernel, I would say, to avoid ambiguity. And second, I'm not sure what you refer to when you say "extremely secure" but even Linux had its share of issues recently (GnuTLS library).

The beauty about Linux (and a lot of well-maintained open source software) is that security flaws are usually patched rather quickly -- with the possible exception of the disaster that is X, but Wayland is coming along nicely.

> patched rather quickly

For offline equipments, not sure how likely they would be patched, though.

I don't know why you are getting downvoted - ATMs are never connected to the Internet directly, they connect to the bank either using a built in modem(yes, the dial-up variety) or their own VPN systems. So it's extremely unlikely, if not just impossible for them to be downloading their own software updates, unless they are published by the bank for the machines to download.

I didn't downvote, but I'm guessing it's because the majority of vulnerabilities are irrelevant if the thing is not connected to the Internet.

There have been a few bugs that have been patched, but turned out to have been introduce quite a while before they were reported and patched. That doesn't mean they were not found long before they were reported/fixed, though.

I agree that free software seems to be very much responsive to disclosed issues though, and while many vendors (perhaps especially Microsoft) have gotten a lot better lately, the image remains (rightly or not) that closed source companies move (too) slow when it comes to patching security issues.

(Part of that is quality control, patching one bug tends to introduce/expose more)

Not to be too pedantic, but the GnuTLS library isn't "Linux the kernel".

How well does Android fair on x86? (I'm assuming that's what most ATMs use)

Very well. It does better than most version of both Windows and Linux as far as smoothing and responsiveness goes. It runs well on much less resources.

It does have some quirks when trying to use it with software designed for swiping in mind and a keyboard and mouse, but that's probably not going to be an issue here.

I say Android could be a good choice, and it will also give them a migration path from X86 should they later on want to.

There is plenty of phones and tablets which run ultra-ultra low voltage of intel x86 CPUs and run Android - they are almost always faster and more energy efficient than their ARM counterparts.

I wasn't aware Android had drivers, I thought Linux had drivers, and Android was mostly a userland?

I think you are misunderstanding something here. Android runs on a modified linux kernel - and that kernel can load drivers like any other. You make a distinction here as if Android was just this thing running on top of the kernel - it's not, the kernel is absolutely essential and part of Android. So yes, following the logic of this, Android absolutely does support drivers.

The kernel is GPL, drivers for "Android+Linux" are also available under Linux -- afaik there isn't an "Android ABI" making the porting of "Android" drivers much of a port at all?

[edit: I suppose things might be a little (but only a little wrt drivers) worse than I thought, given eg:

http://lwn.net/Articles/481661/ ]

No security updates after next versions ships...

Easy! Just run CyanogenMod nightlies on the ATM...

Haha yea, that was my first thought when someone suggested android ;)

I'm an android fan.. But, I just don't see it for something like ATMs.

ATMs need physical buttons for disabled users, so the whole touchscreen thing is a no go. They need experienced, stood the test of time, companies to provide support over the 10-15 year lifetime. They need reliable and auditable source code, so the less code, the better. In other words, they need something that's not android.

The Linux kernel makes a lot of sense given these requirements, paired with a bare minimal userspace and graphics stack, they can likely make good on their existing hardware until it either ceases up or simply can't support new standards like Chip+PIN.

NanoBSD would be easier to audit than anything Linux based. Once it's booted, you can physically disconnect the write pin of your storage device. If you can manage to dump the contents of it externally to the host, you can then compare checksums to see if anything has been compromised.

> Once it's booted, you can physically disconnect the write pin of your storage device.

Does this mean it requires someone on site to boot the machine? I could see that might not be an issue for ATMs, as they are usually located near banks. It might be an issue for remote locations, though.

You can use a write-once hardware register at the end of the boot sequence for similar effect.

But you can actually just leave the entire sector write only, even on boot. This is what most embedded Linux systems do - the entire rootfs is read only, /tmp and the like are on a ramdisk, and only a small writable partition remains for things like logs. In fact, Linksys routers didn't even have a writable filesystem - they stored all their settings on a separate EEPROM.

> You can use a write-once hardware register at the end of the boot sequence for similar effect.

Or use a turn-key switch. First put it into II, wait for the boot sequence to complete, switch back to I. Yes, that does require someone to be on site but that tends to happen anyway when someone restarts the ATM in the first place. If you want to update the software remotely, you could download it into ramdisk and run it from there. For the base system, you'll want something robust so it's more or less guaranteed to get to the point where you can manage it remotely. And you could verify the downloaded application bits against a locally installed root certificate.

The old MS-Windows-based ATMs may be rebooted daily, but let's face it, that's just because Windows. When the base system has to be updated for some reason, a service technician will have to physically replace the storage device for it. If that happens very often, they're either doing it wrong or I'd recommend against such a setup. But perhaps the vendor can charge for the service, in which case /care ;)

Or they could turn the key into II every last Monday of the month for example (the ATM would go into maintenance mode) at a certain time and let the big maintenance server do its work overnight, avoiding the situation altogether at the cost of a slightly greater risk that the machine becomes defective.

In any case, a tiny embedded OS would be perfect for the job.

Tooling to integrate with a COBOL backend?

Bankers and ATM manufacturers ain't morons. They aren't using Windows XP out of ignorance. ATM's have been widely deployed in the US since about 1980 and it's the last version of Windows that runs old 16 bit code directly.

It is not as if banks have an aversion to Linux. What they are averse to is risk. Reimplementation requires testing for a level of robustness well to the north of MtGox. Multi-touch pinch to zoom doesn't matter- ATM's require physical buttons for handicap accessibility [by law in the US].

Disrupting banks isn't about ATM's. It's about new financial structures.

> Bankers and ATM manufacturers ain't morons.

Moron is perhaps a harsh word but it's been known to the public when Microsoft will stop supporting Windows XP. They had years to prepare. And they are multi billion dollar corporations. How can they have dropped the ball with this?

Time taken to certify a more recent version of the OS? Time needed to sort out a 16bit backend?

I don't know, I'm just thinking of possible reasons. Same as in the good old NHS in the UK [1] and especially the comment at [2].

[1] http://www.theregister.co.uk/2014/03/20/doh_microsoft_nhs_on...

[2] http://forums.theregister.co.uk/forum/1/2014/03/20/doh_micro...

and

http://forums.theregister.co.uk/forum/2/2014/03/20/doh_micro...

No one's dropped the ball - everyone's ignored it as someone else's problem as it's a maintenance issue, not one for direct profit. Same as for the y2k and and IPv4 problems. Outside of IT, it's probably the same for global warming. There's probably a special/psychological term for this.

Procrastination?

What is the ball they dropped?

Please show me the comparative risk analysis of sticking with XP after support ends versus rewriting an existing code base across fleets of machines that not only spit cash but are also hardwired into the electronic transfer systems.

I''ll stipulate that coming across as a brogrammer friendly workplace doesn't count.

The thing is they weren't updating their ATM software anyway, and they were always on isolated subnets. Why would you care if support is dropped?

XP Embedded != XP Retail

They didn't drop the ball.

Every single manager did a quick analysis, worked out that the upgrade would cost "Holy shit, how much of my budget?", and punted down the road in the hope that someone else would have to eat the cost.

And, Microsoft will probably extend support (for a big chunk of money) after the big companies scream enough.

Sounds like a great idea. One question whether Android would need to go through some type of certification for financial applications?

April 8 is the EOL date for standard XP, XP Embedded (which is what most ATMs run, the article suggests it too) is Jan 2016.

With less than 2 years to go, they have to look for alternative now.

Indeed. Yet the article claims that April 8 is the EOL date.

What about the possibility that these machines are actually running vanilla XP?

Well this quote from the article suggests otherwise

"If I were Microsoft, I would have kept XP embedded alive for a few more years, and charged an escalating support fee" for it, he said."

...but then, this article, as most others on that topic, and the Wikipedia page on ATMs write "Windows XP and Windows XP embedded". So I guess the "Windows XP, non-embedded" market share is significant.

Part of this is confusing for me. Standard XP support ends on April 8th, so no more bug/security fixes. However, I imagine most of the bug/security fixes for Embedded XP will more than likely still apply to Standard XP. What is there to stop people continuing on Standard XP with Embedded XP fixes?

Because they won't have been tested on standard XP. Microsoft will no longer be doing all the hard work of validating OS patches to ensure that they run correctly and have no unwanted side effects.

You could install one of these patches and it totals your machine. Now what do you do?

But the thing is that XP Embedded is still XP, in fact it's just a modular version of XP Pro... http://en.wikipedia.org/wiki/Windows_XP_editions#Windows_XP_...

As for totalling your machine, you'd do the same thing you'd do if you installed a flaky update now, i.e. a system restore.

And then what? Not install the update?

The difference is, if you were running a supported version, then you could get MS to help you solve the update installation. But with the unsupported OS, all you can do is skip the update. And then you're back in the realm of an unpatched, insecure OS.

The updates are being applied to the same components found in XP Pro. XPe is essentially a nLite-customised XP Pro with a support contract. If Windows Updates worked for nLite-customised XP, then I can't see XPe updates being majorly different.

The news should be about anyone serious still running Windows (XP!) in ATMs. Why hasn't everyone switched to Linux or BSD 10 years ago is a wonder.

I've seen last year an ATM stuck in a reboot loop of some kind running OS/2. Was the first time in my life I saw this OS and probably the last.

Even more scary; why do almost all consumer and non-consumer screens like airports, train station, info screens, army rugged laptops, missile guidance systems, most nuclear reactor systems, medical equipment etc run some form of Windows? That's really what I will never get; I hear the excuses from people which I already typed out elsewhere and I know these are bullshit these days. So it must be some kind of MS infiltration tactic? What can they actually offer I wonder besides a 'safe name'? Maybe that's just all there is to it?

I think support. You have to remember that the first Red Hat Enterprise Linux is from 2002. Back then, the old UNIX vendors were in steady decline, but the freshness of enterprise Linux probably made potential customers weary.

Nowadays, things are really different. Red Hat is large and has a solid track record. IBM has shown its support for Linux over an extensive period. SUSE is now in the hands of a huge IT company.

Consequently, I don't think there is a good excuse in 2014 not to seriously evaluate Linux. In fact, it should be (and often is) the standard option for embedded devices.

> SUSE is now in the hands of a huge IT company

Which one are you referring to?

http://en.wikipedia.org/wiki/Attachmate

Ah, I thought SUSE was split off into its own company back when they acquired Novell.

If windows is so bad, we should by now have had a lot of missile disasters, airport disasters, missile guidance disasters, train station disasters, nuclear reactors disasters, etc etc... I have had my share of sightings of crashed ATMs running windows, but I also seem to remember that sometimes the way things are coded crash the OS, and it's not only a windows issue is it?

I'm not saying/did not say Windows is so bad (it was, from a stability standpoint, horrible, but that's a while ago; still people used it then for theses purposes as well...); I was wondering why it's so one-sided. There seem to be little tech reasons to choose one OS over the other currently, so like everyone says, it must be support. But that's moot now as well.

The 'bad' thing now about Windows (and iOS, OS X) I can think of technically at this moment is that it is closed. I would not like to run my company on something closed, especially if there are nuclear reactors, missiles, airports, airplanes, medical crap involved. I want to be able to dive down to the line of code instead of having to ask a vendor why it does what it does. So again, from a tech point of view, I do not understand why any CTO would pick a closed solution over an open, especially when lives are at stake besides him/her covering his/her ass. And that's probably what it usually is; no balls to pick the best thing for humanity (...) even if it's an uphill battle.

I see your point. How many lives would you estimate are lost/saved because of what OS is being used? Wouldn't any vendor have a "military" version of whatever OS they would use anyway? Which would make it a lot safer to use.. The NSA probably cracks as many windows machines as they do Linux/Unix all over the world, I would think that it's all the same if you know where to go and what to do to get in.

> I would think that it's all the same if you know where to go and what to do to get in.

It isn't. You have to find completely different loopholes in each implementation of networking stacks to exploit them. Anyone running outdated software is always vulnerable to newer exploits, but the thing with Linux is that is audited by thousands of businesses around the globe, whereas Windows probably has back doors for the NSA through some backdoor dealing with the US gov't and nobody can audit that.

I see. I get it now, it does make a lot of sense.

You are criticizing 10-20 year old decisions on the basis on what is available today (I am referring to your "currently" phrase)?

Most non-startup companies have a huge tech stack in place. That stack depends in many ways on the OS. If today you win/make a bid for a display in an airport, the first thing you should be asking is "how do I leverage my existing code base". The answer is almost never "by completely switching my OS". Especially in the scenerios being discussed in this sub-thread - lives at stake. I'm going to throw away my multidecade tested code for new code, and call that safer? No, never.

Much (not all) of the code at the company I work at now is Windows based. I'd like to switch away, sort of, but for what? A nebulous "it's open" argument, vs converting man-centuries of work? It makes no sense.

It has nothing to do with "balls", but a cost benefit equation, and a recognition that a 5-10 year old, battle tested OS is pretty darn safe compared to some kernel released in the last 3 months.

I didn't say one should throw out decades of work; for a new company or and old company writing new software it makes sense picking technologies which run everywhere so you have a choice. There is no problem running Win if your admins are Win and most of your code is Win only; that makes a lot of sense. What makes no sense IMHO is picking Win blindly for new software and I find the same goes if you substitute Win with OS X or Linux or whatever.

Also; when you write software, now or in the 80s, late 70s (before that it was a bit harder unless it was Cobol/Fortran or something), you separate the frontend from the backend. I wrote a ton of 'Windows only' (meaning it had to only run on Windows) software for companies in the 90s and 90+% of that C++ or Delphi code compiles fine on Win + Mac + Linux. I will still say it's about balls in choosing your tech if it's not mainstream aka simply blabbering out: Oracle + MS, but more so now; now there isn't much excuse for picking lock-in tech for the most part.

Not sure what the 3-month old kernel is about; those exist in MS/Apple/... as well; who runs prod on that? So what does that even mean?

Support. If you sign a contract with Microsoft saying that they have to support your system for next 15 years, they have to - they are legally obliged to. If you go and download Ubuntu, no one will care about your antique system in 10 years time, you will be told to just move on and upgrade the system - which is very non-trivial in all of these environments listed.

You can buy Linux support contracts from Red Hat, Oracle, IBM, Novell etc etc.

Exactly. And you have to pay for them, just as you have to pay for Microsoft's support contract. So really, if you have to pay for either, it's only a question of which company gives you the best deal. Also, I am pretty sure MS will be around in 15 years - Red Hat, not so much.

Red Hat is a 21 year old billion dollar tech company. Unless they do something catastrophically stupid (that can just as soon sink MS, like the Windows 8 bullshit is destroying their bottom line) they will absolutely be around.

Microsoft has 15-16 billion dollar businesses[1]. The realm of mistakes that might sink Red Hat is quite a bit different than the realm of mistakes that would sink Microsoft.

[1]: http://www.zdnet.com/microsofts-16-billion-dollar-businesses...

Okay, so I just went to the Red Hat site. Tried to figure out what they offer. It's a mickey mouse site. Oh, they offer "support" for "enterprise linux". Okay, so are they offering support for a 10 year old release of Red Hat? Am I going to get immediate bug fixes to security problems? Am I going to get a modern tool chain that builds my system for that old release? How many engineers, exactly, are focused on that 10 year old platform? And so on.

Whereas if I go to the Microsoft site, I can trivially find support lifecycles, details of what is supported, all of my tools pretty much interoperate (no breaking changes), it is easy to download from MSDN whatever set of technologies I need for any version of software, and so on.

I realize I am being unfair - I am familiar with MS support, and not with Red Hat support, so obviously it will be easier for me to find this stuff. But, consider me your average CTO. I don't think the case has been made for long term support of OS as host for my applications (we are, after all, talking about buying an OS to host my applications, not support for servers, which RH is very good at, of course). Hard questions that a CTO should be asking, and I suspect the answers are not going to be good.

Try an embedded-focused company, like Wind River or Timesys.

I'm not sure it's a wonder at all. The cost of replacing an operating system for all your ATM machines involves rewriting your application for the new OS, perhaps modifying it for your ATM HW, testing it and deploying it. It's a considerable cost and to gain what exactly? I don't think it would have made any sense.

It's not actually a news - at least here in Europe, I have already seen few ATMs stuck in blue screen.

But it's much worse than that, I was amazed when I learned that it's actually possible to dabble with ATM PC without anybody noticing - as presented on last CCC: https://www.youtube.com/watch?v=0c08EYv4N5A (basically the researches said that while the money case is in vault, the computer itself is not ... so this was exploited to install malware which would empty the money supply on request).

Some banks would have liked to migrate a long time ago but some ATMs vendors are not very cooperative : their XFS [1] interfaces were not compatible with new versions of Windows .... That's the problem when you are stuck with a locked down plateform.

http://en.wikipedia.org/wiki/CEN/XFS

the wikipeda links to the official website, though the page is gone Sharepoint error message): http://www.cen.eu/cenorm/sectors/sectors/isss/activity/banki...

What's the new page? their CEN website is a bit confusing

Unless they established new Linux distro, say ATMLinux, where most ATM operators pays to maintain and contribute, it's going to be interesting how it will work.

I assume each operator paying to different opensource-shop of their choice is going to be more problematic than all of them paying to only Microsoft.

or they could just run Red Hat...

There isn't really anything special about the Windows builds ATMs run. It's all in the ATM software.

The issues is about support for old version.

Will Redhat support the same Linux version 12 years from now?

If they don't care about OS support. Then they wouldn't have problem with Windows XP EOL.

They can take Mer and create a kiosk style UI in a very short time. No need for heavy distros lifting.

I'm guessing they'll just fork something and keep using the same kernel for "50" years, ignoring security updates. "Install this tgz as base system, add your config".

What's the attack surface anyway, the modem drivers? It really, really shouldn't be possible to overflow anything using a "custom" card, or the number pad... (I do sometimes wonder about hostile smart card code for chip and pin, though...).

the same kernel for "50" years, ignoring security updates

Well then don't they have the exact same problem as they do now with MS? Or more general: are the update cycles from a typical linux distro that different from Window's? I.e. can you really get security updates for such distro 20 years after it was released? That would mean the only benefit for choosing linux is that there are possibly less securit issues to begin with, while the article seems to claim the problem is all with the update cycle.

Given the pocketbooks of banks and the small footprint of such a secure embedded system, I think it won't be difficult to negotiate a contract with e.g. Red Hat to provide 20 years of support. The RHEL lifecycle is already 13 years, prolonging that to 20 years for a small subset isn't outside the realm of possibilities.

I (somewhat laconically) implied that the vendors could care less about security, if they could get away with stability and low maintenance cost.

More seriously, with a truly stripped down free software solution (be that Linux or *bsd founded), you can have a pretty good idea of exactly what code you are running.

Current Linux might actually be a pretty poor choice, given the high rate of change in the kernel (which tends to drag a lesser, but noticeable change in userland). A few years ago 1.3 kernel might have seemed a sane choice to build such a system on (along with busybox, minimal init etc).

Anyway, the idea would be to get a reasonably audited core system (mostly userland) and a kernel - and then only ever update drivers, and/or add functionality.

Personally I'd be a lot more confident doing that on Linux (or bsd) than on Windows XP, even if given source access (would you really want to compile the needed bits of XP kernel+userland to run on your embedded stuff? The thought scares the beejeezes out of me)).

Aren't there any existing ATMs running Linux at the moment? Surely they could fork one of those distros.

As usual the uptake or not of Linux for this or any other use case will be moderated by quality drivers or the lack thereof.

This assumes the hardware from one ATM to another varies wildly. This is hardly the case. Thus, driver implementation costs are a very small factor, not the primary one.

License restrictions are more likely to make them choose something else, like Sony chose FreeBSD for the Playstation. (Again, no need for drivers for many different configurations.)

Linux drivers are no longer much a problem, and haven't been for a while.

Linux is have trouble shaking off its old reputation though.

Plus, ATMs (at least where I live) run on stone-old machine usually which you would expect Linux might even be easier to run on.

I can't think of anything in terms of reputation that might hinder this movement. What did you have in mind exactly?

The question is if anyone has gotten their hands on the few different ATM machines hardware-wise and wrote Linux drivers for them. Basically the market for these, magstripe and EVM cards is very much a Windows market => at least most of the US providers of services, backends, software etc for this all are almost entirely Windows based. And therefor the manufacturers, although it would be easy for them, have not much incentive to deliver proper drivers. I'm not saying it's a big problem per-se, but it might make people nervous anyway.

They also need to be complaint and that can take long on new software, so they would need to pull in a provider who already has the compliance in some related areas, probably Redhat has and then try to tape on the extra compliance needed for the new software, drivers and whole combination.

All in all, it's all very possible, but I think going public with all of this is unfortunately just a trick to get MS to play. I hope it's not as I have always wondered, as a software engineer who created banners, POS systems and information panels (I don't know the proper English jargon for these; I know the Dutch names, but like the panels you see at events, train stations, airports :) why they are not using Linux for everything anyway; everyone always cries about drivers but those have been a non-issue already 10 years ago. 'They are used to writing software on Windows' has also always been a none issue; these apps are complete, fullscreen apps which are the only thing running next to the kernel and a few drivers on these systems. They are almost always completely custom drawn and, like 2D games, that means the difference between Windows and Linux is not really there and hasn't been for many, many years now. You can run SDL straight on the framebuffer and make a tiny Linux distro with your software/drivers to run on it.

We sold Linux POS systems over 10 years ago; built on C & Tcl/TK they were faster, easier, cheaper, and nicer than the Windows versions at that time by a long shot. There is 0 reason why you wouldn't do this, but people are ignorant and unfortunately many of these people are coders; like people are stuck on Linux & Mac, a lot of people are stuck on Windows and lose sight of what is better for the customer (over 10 years ago that would have been stability and price; both much better under Linux) while peddling the 'everything is better under Windows'. I would not expect that from smart devs but he, here we go :)

While the POS and ATM systems themselves often run windows, Linux is quite often already in the picture.

That EMV terminal that's talking to the windows host might just be running ARM or MIPS linux.

(yeah I work on this stuff...)

I work on the card creation/manufacturing (EMV) side and this is good to know; people always send me Windows stuff and while I don't mind I always wonder if there is a sane reason for it (there seems not to be).

Huh, one of the few parts I've never touched - I've worked on acquirer and issuer systems, retail-level switches, POS payment subsystems and lately embedded reader/terminals, but not on what goes on inside the card itself.

I never really wanted to go back into payment systems and had a few years away from them, but it turns out that when you've written an EMV L2 kernel people want to employ you for that sort of stuff again...

Well, I reckon that if you're in the market for say 500,000 magstripe readers you're probably in a good position to ask the manufacturer to supply a driver for the OS of your choice.

So are ATM machines monolithic devices where you have to scrap the entire thing if you want to upgrade the OS? Or do you open a door in the side, remove the old computer and hook up a new one, and as long as you have the drivers that same cash dispensing and receipt printing hardware will continue working?

Seriously? This is happening now?! ATMs are supposed to be secure, then why the hell are they running one of the most security loop-hole OSes even now?

That too Windows XP, which has been deemed as the most unsecure OS in the world!. It's long time for them to switch to Linux!

> ATMs are supposed to be secure, then why the hell are they running one of the most security loop-hole OSes even now?

ATMs are not internet-connected and have very restricted inputs, so that's mostly irrelevant[-1].

ATMs use windows because support, licensing[0], institutional knowledge, existing codebases, hardware drivers availability and the like.

Due to [0], as other commenters I'd see them migrating to some BSD rather than Linux, much like Sony did. If they ever switch off of Windows XP in the first place.

[-1] only mostly, if you can cut through and get hardware access, you can have fun: http://www.extremetech.com/extreme/173701-atms-running-windo... then again it seems the vulnerability used here is "boot from USB key" which is orthogonal to the OS used

[0] and no possible copyleft headaches

Are you seriously suggesting that Windows as an operating system has some serious holes that has made it insecure as an ATM OS? Care to elaborate which those holes have been and how have they been exploited in the ATMs?

I came across this yesterday. Not necessarily just exploiting a Windows security hole though.

http://media.ccc.de/browse/congress/2013/30C3_-_5476_-_en_-_...

I saw a Windows 95 blue screen on an Siemens Nixdorf ATM with a CRT monitor two years ago.

The operators (Germany, Austria) say they are not connected to the "internet". I wonder if they use a separate telephone-line-network or just use VPN/firewall.

They have their own network, no "internet".

Barnaby Jack showed how much that isolation is worth at DEF CON a few years ago: https://www.youtube.com/watch?v=htDMu7USsZQ

I still know of one ATM (Bank of the West - Walnut Creek) whose ATM runs Microsoft Network OS 2.01. (or maybe 2.1?)

I think that's OS/2 - it looks like DOS with tcp/ip. The copyright on the screen states 1992.

Good development which really had to happen earlier. As usual, MS shoot themselves in the foot.

By marking an ancient OS that everyone should have moved off as obsolete? It is the ATM manufacturers fault for accuing so much technical debt

By not being able to provide flexible updates the way ATMs need. Custom Linux distros can easily enable that. So it's good they realized that sticking with MS is a bad idea.

They did provide flexible updates, for like ~10 (ish) years. They're done doing that now and everyone should be well aware already.

With Linux no one can pull the plug. Here, they are at MS's mercy. So they learned their mistake the hard way.

Naturally, even supported versions of Linux like RedHat's and etc. have an EOL date support wise. But in the worst case if some company is stubborn enough to stay on the old version for whatever reason (which might be valid for them), they can take the code and support it themselves. With Windows it's not possible. So open systems have a clear advantage here.

Great, let's support companies who like to run financial software on ancient, insecure and decrepit platforms who don't want to invest in pulling their software into the 21st century.

Microsoft has offered an embedded version of Windows since 7, and say what you will about Windows but it's backwards compatibility is second to none. If they can't or won't move to a more modern, secure OS (after 10+ years) then I would argue that they shouldn't be trusted to make ATM's

While their reason was wrong (not taking care of upgrading in time), their outcome was right - they consider ditching Microsfot ;)

Great, now they can stick their ATM's on a 2.6.x kernel and not touch it for another 10 years. Everybody wins right?

In general yes, since it won't make it any less secure than it was already. But it will reduce MS grip on the market. Those who really cared about security didn't even use MS to begin with anyway. Having a black box closed source system with who knows what kind of backdoors as an ATM OS? Sounds bizarre of you think of it.

> Those who really cared about security didn't even use MS to begin with anyway.

I don't know enough about this field to comment definitively, but I have to imagine that if one industry cares about security very, very deeply, it's the one that makes machines that give away money when you have a card with a magnetized strip and you push the right buttons. I'm willing to bet that the Windows XP that lives inside an ATM is not the same one that you buy from New Egg to play Half-Life.

they just skipped a decade...

it's more customizable, more secure, and free. really hard decision.

Reply on news.ycombinator.com