Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Shuttleworth Wants To Get Rid of Proprietary Firmware

samzenpus posted about 4 months ago | from the change-your-ways dept.

Ubuntu 147

jones_supa writes "In a new blog post, the Ubuntu main man Mark Shuttleworth calls for an end to proprietary firmwares such as ACPI. His reasoning is that running any firmware code on your phone, tablet, PC, TV, wifi router, washing machine, server, or the server running the cloud your SAAS app is running on, is a threat vector against you, and NSA's best friend. 'Arguing for ACPI on your next-generation device is arguing for a trojan horse of monumental proportions to be installed in your living room and in your data center. I've been to Troy, there is not much left.' As better solutions, Shuttleworth suggests delivering your innovative code directly to the upstream kernel, or using declarative firmware that describes hardware linkages and dependencies but doesn't include executable code."

cancel ×

147 comments

Sorry! There are no comments related to the filter you selected.

Precisely how... (1)

msobkow (48369) | about 4 months ago | (#46508825)

Precisely how does he intend that a machine boot to the install media without executable firmware?

Or is he a proponent of the "disposable machine" -- once infected, you *have* to replace it, because you can't *reinstall*?

Re:Precisely how... (3, Insightful)

jones_supa (887896) | about 4 months ago | (#46508839)

Getting rid of ACPI sounds also like a "good luck with that" plan.

Re:Precisely how... (5, Insightful)

TechyImmigrant (175943) | about 4 months ago | (#46508963)

I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.

What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware.

Re:Precisely how... (2)

jones_supa (887896) | about 4 months ago | (#46508999)

ACPI WMI specs from the HW makers would be nice. It's frustrating how many laptops have broken hotkeys under Linux.

Re:Precisely how... (2)

fuzzyfuzzyfungus (1223518) | about 4 months ago | (#46509089)

ACPI WMI specs from the HW makers would be nice. It's frustrating how many laptops have broken hotkeys under Linux.

If we are currently at the point where you can't even get the details of what the Windows Management Instrumentation blobs embedded in the motherboard firmware mean, that might be another reason why somebody running a Linux company might dislike ACPI...

As long as (through some mixture of overt standard-setting to that effect, and basic 'you actually think that we are going to keep testing our BIOS once it boots Windows? That means that it's ready to ship!' OEM engineering) proprietary firmware is basically the lowest level of Windows drivers, writing other OSes on top of it just isn't going to be a pleasant experience.

Re:Precisely how... (2)

PopeRatzo (965947) | about 4 months ago | (#46509195)

What he needs is open interface specifications to the hardware.

That. Absolutely.

Shuttleworth may be slightly off the mark, but his dislike for proprietary firmware is worth supporting, given what we're learning daily about what people who mean us no good are doing with our consumer electronics.

Re:Precisely how... (1)

Lumpy (12016) | about 4 months ago | (#46509247)

and he will NEVER get it.

Hell you cant get open microcode on the freaking processors.

Shuttleworth is starting to become a little nutty.

Re:Precisely how... (-1)

Anonymous Coward | about 4 months ago | (#46509659)

Starting? It's a bit of a requirement for something that pedantic in the open sores community.

Re:Precisely how... (1)

Anonymous Coward | about 4 months ago | (#46509361)

"I could wait for someone to accept my changes into the Linux Kernel before I start testing it"

How's that? If you propose your changes to be accepted to Linux, you should already have tested it, and I guess that's how it generally works right now?

Re:Precisely how... (5, Interesting)

TechyImmigrant (175943) | about 4 months ago | (#46510281)

I'm talking about the device not the kernel.

I can compile up my own kernel and test my device against it. But I can't go and deploy my device on the myriad computer/OS configurations out there if I need stuff compiled into the kernel. ACPI solves a problem. If your solution that replaces ACPI doesn't solve the problem ACPI solves while also solving the trojan-via-firmware problem, then it's useless. ACPI is horrible, and I'm all for replacing it with something better but I'm not seeing a proposal that does both.

Re:Precisely how... (1)

Anonymous Coward | about 4 months ago | (#46509949)

I design hardware. I could wait for someone to accept my changes into the Linux Kernel before I start testing it, or I could write some firmware accessible through ACPI.

Or; you could write a FOSS module interlinked with ACPI to coreboot [coreboot.org] and then everything would be free and you would have the ACPI you wanted. You would probably even find that the community would fix the bugs in the software you wrote for free and you would sell extra hardware.

The thing is, that we want the full source to every bit. Anything less and the security risk is just too great.

Re:Precisely how... (1)

drinkypoo (153816) | about 4 months ago | (#46510261)

What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware.

One might reasonably argue that what one needs is the source to the firmware and the tools needed to apply it to the device. One's rebuttal might involve cost, but not "you don't need that".

Re:Precisely how... (2)

mspohr (589790) | about 4 months ago | (#46510537)

"What Shutters wants is irrelevant. What he needs is open interface specifications to the hardware."

I think that's what he wants:

"Declarative firmware that describes hardware linkages and dependencies but doesn’t include executable code is the best chance we have of real bottom-up security. The Linux device tree is a very good starting point."

Re:Precisely how... (1)

fuzzyfuzzyfungus (1223518) | about 4 months ago | (#46509031)

Getting rid of ACPI sounds also like a "good luck with that" plan.

If anything, insufferably shitty firmware has been steadily bloating to the point where we should probably start including it in operating system marketshare charts...

Re:Precisely how... (2)

blackiner (2787381) | about 4 months ago | (#46509363)

Isn't device tree pretty much declarative firmware? It has gained quite a bit of ground in the ARM on Linux world recently too. Seems like the solution already exists, it just need a bigger push.

Re:Precisely how... (1)

jones_supa (887896) | about 4 months ago | (#46509427)

Yes, it could be one solution.

Re:Precisely how... (1)

mspohr (589790) | about 4 months ago | (#46510459)

He didn't say get rid of ACPI.
He said get rid of proprietary firmware.
You can have an open source ACPI (https://acpica.org/downloads) which you can audit to find the NSA evil bits.

Re:Precisely how... (3, Informative)

nateman1352 (971364) | about 4 months ago | (#46510995)

Honestly Shuttleworth's reasoning "Binary blobs can contain NSA exploits" is completely irrelevant to ACPI since ACPI byte-code can be completely de-compiled back in to the original source language making it very easy for security researchers to detect any funny business.

Honestly the modern PC has several microcontrollers in it that contain code that the primary CPU never even sees. I personally would consider those a much bigger security threat than ACPI.

So lets ask ourselves... why does he really want to get rid of ACPI? The answer is pretty simple, it going to take a lot of coding effort to get the Linux ACPI stack ready to fully support ACPI 5.0 and Connected Standby found on a lot of brand new laptops. This is just a feeble attempt to mask the fact that puring all his resources in dumb projects like Mir and Unity doesn't leave much left to keep up to date on new open PC platform standards.

Re:Precisely how... (-1, Offtopic)

davester666 (731373) | about 4 months ago | (#46508951)

No, he's arguing for analog hardware. The world of the 50's, today.

Re:Precisely how... (5, Informative)

Anonymous Coward | about 4 months ago | (#46508995)

Firmware is just fine, as long as it's non-proprietary--free as in freedom.

Re:Precisely how... (1)

SuricouRaven (1897204) | about 4 months ago | (#46509013)

DIL socket. Add your own firmware chip.

Re:Precisely how... (1)

Lumpy (12016) | about 4 months ago | (#46509269)

Yuck QFP is a lot better far better pin density and easier to insert or remove safely.

Re:Precisely how... (2)

LoRdTAW (99712) | about 4 months ago | (#46509819)

I think you mean PLCC. It can be soldered directly to a board or socketed. And in the recent past it was the choice for socketing BIOS chips after DIP32 fell out of favor. QFP is quad flat pack which is always directly soldered to the board and not easily removed. I never seen a QFP socket outside of test fixtures.

With the high density of todays boards, even PLCC is gigantic in terms of footprint so many have moved to smaller SMT packages. I have seen Intel motherboards using 8 pin SOIC chips, most likely on an I2C or SPI bus. You can buy sockets for them but no mainstream motherboard maker sockets them.

Re:Precisely how... (-1)

Anonymous Coward | about 4 months ago | (#46509377)

Can that be stuck in your DIL hole?

Re:Precisely how... (4, Informative)

amorsen (7485) | about 4 months ago | (#46509053)

Precisely how does he intend that a machine boot to the install media without executable firmware?

He does not complain about executable, he complains about proprietary.

Besides, ACPI is complete overkill for booting.

Re:Precisely how... (0)

Anonymous Coward | about 4 months ago | (#46509065)

As far as I know, ACPI is not involved in booting.

Re:Precisely how... (1)

msobkow (48369) | about 4 months ago | (#46509243)

So you can't power off the machine while it's booting?

Give your head a shake.

Re:Precisely how... (1)

msobkow (48369) | about 4 months ago | (#46509261)

Then again, I have to hold down the power switch until it takes effect while booting, so maybe ACPI isn't involved and it's me that needs to give their head a shake.

Anyone know for sure?

Re:Precisely how... (1)

amorsen (7485) | about 4 months ago | (#46509403)

queazocotal has it right. ACPI prepares the hardware and tells the kernel where to find it.

Of course on recent hardware EFI is taking over part of that. EFI is significantly more bloated than traditional ACPI BIOS.

Re:Precisely how... (1)

queazocotal (915608) | about 4 months ago | (#46509355)

It is.
It's one of the primary means that the kernel (of whatever OS) works out what hardware it's actually running on, and what it should setup.
ACPI, PCI* configuration registers, and friends are all pretty much required in order to boot a random system successfully.

Re:Precisely how... (0)

Anonymous Coward | about 4 months ago | (#46509783)

Oh, I was actually thinking about the earlier stages of booting, involving just starting the kernel and all the stuff before that. ACPI is probably not used in those moments.

Re:Precisely how... (1)

dargaud (518470) | about 4 months ago | (#46510303)

Besides, ACPI is complete overkill for booting.

Agree. I've written bootloader code and kernel drivers. All the bootloader really has to do is get the kernel in memory somehow and jump to it. Why can't you boot directly into the kernel you ask ? One reason is size; on many (embedded) systems, there are only a few Kb available for an executable on boot. The other is that the bootloader doesn't not change easily (it needs reflashing or is in some kind of ROM), allowing you to easily change the kernel.

Re:Precisely how... (2)

tlhIngan (30335) | about 4 months ago | (#46510925)

Besides, ACPI is complete overkill for booting.

Agree. I've written bootloader code and kernel drivers. All the bootloader really has to do is get the kernel in memory somehow and jump to it. Why can't you boot directly into the kernel you ask ? One reason is size; on many (embedded) systems, there are only a few Kb available for an executable on boot. The other is that the bootloader doesn't not change easily (it needs reflashing or is in some kind of ROM), allowing you to easily change the kernel.

ACPI is not just used for booting, it's used for controlling the customizations between systems. While the PC architecture has changed little in the way of memory maps since the 1980s, there are still things that various computer manufacturers do that no OS could ever program for.

For example, PCI interrupt routing was completely up to the manufacturer in routing which IRQ when to which PCI IRQ. They were normally scrambled so you don't have all the cards using one IRQ line, but that information needs to be communicated between the BIOS and the kernel, otherwise the kernel has no way to handle PCI interrupts properly.

You could define a data structure (which is what ACPI does), or you could program into the kernel every variation around for every motherboard, and hope that every mobo manufacturer out there updates the list and submits the patch.

The other thing is, well, ACPI handles rebooting, shutdowns and suspend/resume. It tells you how to poke the hardware in various ways to accomplish the goal. It isolates the difference between hardware to the people who know it best - the hardware guys.

Some of these things may be GPIO pins that change for routing convenience (to enable/disable wireless, for example, or for various status LEDs), power switches that control how the regulators operate, other settings and controls for various voltage rails and such.

Every PC is not the same, each manufacturer might choose a different power regulator IC that requires different programming to turn it on and off, and ACPI is best to handle it. otherwise the kernel will have to have each and every variation in it programmed in.

Re:Precisely how... (1)

amorsen (7485) | about 4 months ago | (#46511513)

I do not think that anyone has a problem with interrupt routing tables or ACPI documenting how hardware should be poked. It could be laid out a little simpler perhaps, but that is mostly bikeshedding.

One of the problems is that ACPI suddenly yanks the CPU out from under you and executes its own proprietary code, and the kernel or user space can do absolutely nothing about it.

Re:Precisely how... (1)

Jody Bruchon (3404363) | about 4 months ago | (#46511707)

What people don't get is how PCI + ACPI have made modern computing possible, and how ARM systems suffer terribly precisely because no such equivalents to these exist in the ARM ecosystem (excluding some PCI bridges, but that's only one piece of the puzzle.) Before PCI (and ignoring EISA et al) all peripheral devices in a computer had to be configured manually. You had to know your Sound Blaster 16 used I/O port 220, IRQ 5, 8-bit DMA 1, and 16-bit DMA 5, and tell each one of your DOS programs or your Windows audio driver all of these things.

Granted, some improvements came along the way, but they were troublesome and didn't always work as intended (Plug-and-Play ISA, for example). PCI was the first ubiquitous chipset-to-peripheral bus interface specification that provided all the information needed to figure out any given PCI device's hardware configuration with obnoxious amounts of detail (lspci -vv if you don't believe me).

ACPI was brought in to clean up the other autoconfiguration-unfriendly interfaces that were lying around. Advanced Power Management was the biggest one that comes to mind, though things like MPS were pulled in also. A whole host of highly system-specific information comes in through ACPI and that's what makes it fairly easy to write a "run anywhere" operating system for systems that have ACPI and PCI. It's not perfect by any means, but without it there would be a bunch of proprietary ways to, say, send a "laptop lid was closed" event to the operating system.

ARM does stuff like this with a pile of GPIO pins which are configured differently for every single bloody device that the otherwise identical ARM SoC is engineered around. You can thank ACPI and PCI in large part for keeping us from needing a specially tweaked OS kernel for every single model of PC that gets released. I'm glad they exist, however ridiculous they can seem at times.

Re:Precisely how... (1)

Anonymous Coward | about 4 months ago | (#46509351)

Point totally MISSED! The firmware running in the bios should be OPEN SOURCE - as in Coreboot. Modern PCs today don't NEED the bios of old as the hardware drivers get replaced anyway - with more open source.

Furthermore, the whole UEFI fiasco could have been eliminated if we had a simple SWITCH on a pc to ALLOW writing to flash only when the user decides to update the bios - and I'm talking about a switch connected to the VLSI flash controller that can not be circumvented by software. A whole lot cheaper.

Open Source 100%.

Re:Precisely how... (1)

Florian Weimer (88405) | about 4 months ago | (#46509585)

The reference implementation of UEFI is open source, and some vendors use it as a basis for their firmware.

Unfortunately, most Coreboot-using devices are tied down and do not allow non-interactive booting with custom firmware (if they allow custom firmware at all).

Re:Precisely how... (0)

Anonymous Coward | about 4 months ago | (#46509817)

Furthermore, the whole UEFI fiasco could have been eliminated if we had a simple SWITCH on a pc to ALLOW writing to flash only when the user decides to update the bios - and I'm talking about a switch connected to the VLSI flash controller that can not be circumvented by software. A whole lot cheaper.

Open Source 100%.

I don't think people advocating the return of the flash bios dip switch, or similar, realize how successful factor social engineering is in today's threat landscape. If that switch is available to the user, it would be fairly easy tricking most users into switching it. We can't build systems and standards only for the 1%.

Re:Precisely how... (0)

Anonymous Coward | about 4 months ago | (#46511363)

We can't build systems and standards only for the 1%.

Like the fraction of a percent who will ever see BIOS malware?

Re:Precisely how... (3, Informative)

sjames (1099) | about 4 months ago | (#46509477)

He's talking about ACPI. That is, firmware that the kernel is expected to trust and run in it's own context after being loaded. That is quite distinct from bootstrap firmware that is expected to load and jump into the bootloader and then be inactive until the next boot.

BTW, much of it is actually broken in various ways.

Re:Precisely how... (1)

mspohr (589790) | about 4 months ago | (#46510433)

He said "get rid of proprietary firmware".
He didn't say get rid of all firmware.
There is a difference.
Open source firmware can be audited to see if the spooks are getting their hands on your data... not so with the proprietary stuff.

Who cared? (-1)

Anonymous Coward | about 4 months ago | (#46508845)

And the rest of the world will laugh at his impotent rants.

Source codes, legos, meccanos (3, Funny)

Hognoxious (631665) | about 4 months ago | (#46508869)

Mark Shuttleworth calls for an end to proprietary firmwares

Well I call for an end to spurious pluralization, so there!

Re:Source codes, legos, meccanos (0)

Anonymous Coward | about 4 months ago | (#46509099)

Firmware is still a mass noun, but lego isn't anymore.

Silly Rabit (0)

Anonymous Coward | about 4 months ago | (#46508871)

I never understand this from software perspective. How to you design a hardware that looks the same to software, all the time. I am suppose to make "new, faster, better, lower power, loser cost" hardware without changing anything?

Re:Silly Rabit (2)

X0563511 (793323) | about 4 months ago | (#46508919)

You don't have to.

Just don't lock your implementation away and let people actually use it

I am in the bottom of the gates (0)

Anonymous Coward | about 4 months ago | (#46511399)

All the register settings of a chip are normally open in a form of a spec (enough to invent the bullet, the gun, the foot, and shoot yourself many times over) Any yes some of these can damage the hardware if you program incorrectly. An initial driver from vendor is usually there as a starter for someone to write a full blown driver.

The problem is that people are not willing to spend the time and the effort to do this for a full product. They want canned (Linux) solutions.
Hardware companies make no money writing drivers. They are more than happy to let a third party do the work if they didn't have to support 1000 3rd party developers. The problem is that the support nightmare is not practical (specially for a small company)

Re:Silly Rabit (3, Insightful)

ihtoit (3393327) | about 4 months ago | (#46509945)

it's called reference frameworks. By the time you get to Userland, a Creative soundcard looks to the software identical to a Turtle Beach. This would be impossible without a reference. One obvious example is DirectX. What you want out of the arse end of the driver layer is a device interface that's compatible with DirectX. What happens between the driver layer and the hardware is entirely up to the manufacturer, but the DirectX compatibility is a certain requirement for even the slightest hope that you'll even get a peep out of it in Windows. And one of the reasons why the Linux driver model, at least from my own personal perspective, is horribly broken. Is there a reference framework for *anything* in Linux?

Re:Silly Rabit (1)

Arker (91948) | about 4 months ago | (#46511297)

"Is there a reference framework for *anything* in Linux?"

Yes, it's called Slackware.

Re:Silly Rabit (0)

Anonymous Coward | about 4 months ago | (#46511627)

But I love my Slackware box. With the exception of wireless cards, damn near everything is easy to install because all you have to do is edit a text file. Most of the system config files are well documented and pretty easy to fall. The wireless ones exist but it can still be a chore, especially if you don't have driver support.

Otherwise, you can do anything on Slackware that you can do on any other linux system. The only thing it doesn't come with is a lot of bloat, and even that isn't true because the default full install is, frankly, bloated. You can trim that down big time and still have a fully functional system with office software, development software, and a slew of other things.

So calling Slackware a framework isn't really fair.

P.S. I suppose if you run some of the big, more cluttered and unnecessarily complex is areas that it just doesn't need to be, then I could see how Slacks K.I.S.S. philosophy may not work for you.

Translated (1)

Anonymous Coward | about 4 months ago | (#46508887)

"We at ubuntu ran into problems working with firmware type X and want to get rid of it and need an excuse, playing on fears tends to work, so let's use that"

Re:Translated (2)

peppepz (1311345) | about 4 months ago | (#46510037)

Everybody runs into problems with ACPI. I've never seen it work properly, on any OS, on any machine that I've owned.

I can't see this happening. (3, Funny)

allaunjsilverfox2 (882195) | about 4 months ago | (#46508893)

Perfect example would be dell bios. There is no way DELL would allow a USER into bios. Especially one that might cause issues that can't be condensed into auto-replies.

Make Ubuntu work properly first (1)

Anonymous Coward | about 4 months ago | (#46508943)

Shuttleworth has ambitious plans, but how about taking care of just the basic quality assurance of Ubuntu first. I am greeted with a bloated and laggy desktop (Unity) with constant "Ubuntu has experienced an internal error" popups. Launchpad has multiple reports of the silly bug of many laptops having the screen brightness adjustment go double steps because the brightness event is handled twice. Hibernation, a common feature of modern OS, is still disabled by default. I could go on.

Re:Make Ubuntu work properly first (1)

Desler (1608317) | about 4 months ago | (#46509019)

But fixing bugs is hard!! Canonical is too busy code-churning for boring stuff like bug-fixing.

Re:Make Ubuntu work properly first (2)

lgw (121541) | about 4 months ago | (#46509127)

At Canonical, making Unity worse is job 1! It gets harder every release to make Unity worse than the last one, so it takes all their mental effort. Perhaps with open firmware, Unity could actually electrocute the user, opening a whole new realm of "worse".

Admins sucking vandal cock (-1, Troll)

slashdot is sht (3508181) | about 4 months ago | (#46508969)

Wikipedia admins enjoy sucking vandal cocks.

What RMS has been saying all along. (5, Insightful)

Anonymous Coward | about 4 months ago | (#46508971)

So people are just now figuring out that o'l fatty hippy beard Richard Stallman was right all along?

Color me fucking surprised! Any code you can't see can and will be used against you.

RMS says things that are uncomfortable and difficult but painfully true. Don't mistake is disinterest in your feelings (Or business model) as hostility.

Re:What RMS has been saying all along. (0)

Anonymous Coward | about 4 months ago | (#46511097)

Hear hear.

On the subject of Troy (1)

K. S. Kyosuke (729550) | about 4 months ago | (#46508987)

I've been to Troy, there is not much left

Funny thing is, that's less due to Achaeans and more to Schliemann's "excavations". ;-)

(BTW, when did Shuttleworth decide to grow a kinkled beard?)

Sick. (-1)

Anonymous Coward | about 4 months ago | (#46508991)

What a bastard.

Shuttleworth is incompetent 1% trash (-1)

Anonymous Coward | about 4 months ago | (#46509003)

ubuntu is a flop, ubuntu phone is a flop, the guy is a scam artist who got lucky during the last dotcom bubble. Shuttleworth's business skills are not existent, he's about as entrepreneurial as Mark Cuban, another dotcom scammer.

Re:Shuttleworth is incompetent 1% trash (0)

Anonymous Coward | about 4 months ago | (#46509401)

Good thing he hasn't been CEO since March 2010, then.

Starts with one generic enough (1)

gmuslera (3436) | about 4 months ago | (#46509045)

And if people start buying from that brand over rivals (or having country legislation forbidding not open enough and/or so backdoored hardware) it may move others to do the same.

Also, if a "hidden" functionality is exposed in major brands using that executable code to perform malware-like activities that brands should be punished in security aware circles. That won't reach the majority of people, but will be an start.

Let's guess what prompted this (-1)

Anonymous Coward | about 4 months ago | (#46509057)

Linux is a massive failure on laptops. One of the big reasons is guessing what ACPI will do. (Another is power management, also linked to ACPI)

Re:Let's guess what prompted this (0)

Anonymous Coward | about 4 months ago | (#46509527)

You think that because the sales numbers say that all laptops sell with Windows installed. The fact of the matter is that at least 10% of all laptops out there are having Windows removed and replaced with Linux.

Re:Let's guess what prompted this (0)

Anonymous Coward | about 4 months ago | (#46509647)

[citation needed]

Re:Let's guess what prompted this (0)

Anonymous Coward | about 4 months ago | (#46509697)

Most laptaps these days are sold with OSX actually and once you already have a working unix desktop why would you downgrade to linux? Sounds to me like you're stuck in 2003.

Re:Let's guess what prompted this (0)

Anonymous Coward | about 4 months ago | (#46509825)

Linux is a massive failure on laptops. One of the big reasons is guessing what ACPI will do. (Another is power management, also linked to ACPI)

Huh. I read this on a Linux laptop and am responding using that laptop. I don't see any failure.

Re:Let's guess what prompted this (0)

Anonymous Coward | about 4 months ago | (#46510575)

Shit. You better tell all those millions of Chromebook and Android users that linux is a flop! They'd never know otherwise!

Possesion (2)

MouseTheLuckyDog (2752443) | about 4 months ago | (#46509111)

So how did RMS posses Shuttleworths body?

Re:Possesion (5, Funny)

fahrbot-bot (874524) | about 4 months ago | (#46509169)

So how did RMS posses Shuttleworth's body?

There's an obscure clause deep down in the GPL ...

Re:Possesion (3, Insightful)

Kjella (173770) | about 4 months ago | (#46509737)

It's part of the GPLv666 under the "Demonic Possession" section if you use the "or any later version" clause. I hear Stallman wrote the original in blood, he couldn't find any open source ink. And you really don't want to know how the toe jam is involved.

Re:Possesion (0)

ericloewe (2129490) | about 4 months ago | (#46510585)

And how does Stallman expect me to acquire the blood I need to produce the copy of the license I must distribute?

If there's something worse than vendor lock-in, it's Free Software preacher lock-in.

Charles Stross? Is that you? (2)

daboochmeister (914039) | about 4 months ago | (#46511145)

Your description of the GPLv666 with a "Demonic Possession" section sounds very worthy of a Charles Stross novel, in every respect. Kudos!

Who? (-1)

Anonymous Coward | about 4 months ago | (#46509137)

Mark who? Why would anyone care what this no-name wants?

Some context from a hardware perspective. (5, Informative)

queazocotal (915608) | about 4 months ago | (#46509209)

Great - you don't want ACPI.

I'm looking at my Nokia n900 phone.
(merely because I happen to have a detailed understanding of the design).

Inside it, there are the following closed-source blobs running on turing complete processors.

LED controller firmware.
SIM java virtual machine
SIM raw firmware.
eMMC controller.
SD controller.
Hard-real-time modem controller.
Modem high-level engine.
Bluetooth CPU.
Wifi processor.
Main linux application processor
GPU.
I strongly suspect there is also an embedded processor in:
Power managment controller.
LCD.
Battery charge monitor.
GPS. (It's possible this is just an application running on the closed-source modem high level engine).

https://srlabs.de/rooting-sim-... [srlabs.de]
http://www.youtube.com/watch?v... [youtube.com] (rooting SD cards)
http://www.youtube.com/watch?v... [youtube.com] (battery firmware hacking)
Similar efforts have been done with reverse engineering the firmware of bluetooth devices, wifi.
The notion that you should only care about the code running on the CPU being open has always seemed really naive to me.

Re:Some context from a hardware perspective. (0)

Anonymous Coward | about 4 months ago | (#46509967)

Great - you don't want ACPI.

I'm looking at my Nokia n900 phone. (merely because I happen to have a detailed understanding of the design).

Inside it, there are the following closed-source blobs running on turing complete processors.

LED controller firmware. SIM java virtual machine SIM raw firmware. eMMC controller. SD controller. Hard-real-time modem controller. Modem high-level engine. Bluetooth CPU. Wifi processor. Main linux application processor GPU. I strongly suspect there is also an embedded processor in: Power managment controller. LCD. Battery charge monitor. GPS. (It's possible this is just an application running on the closed-source modem high level engine).

https://srlabs.de/rooting-sim-... [srlabs.de] http://www.youtube.com/watch?v... [youtube.com] (rooting SD cards) http://www.youtube.com/watch?v... [youtube.com] (battery firmware hacking) Similar efforts have been done with reverse engineering the firmware of bluetooth devices, wifi. The notion that you should only care about the code running on the CPU being open has always seemed really naive to me.

Though I agree on the security implications of all this code, it's always seemed really naive to me that people open source would make an automatic difference. There are so many examples now of long overlooked OSS vulnerabilities, and a growing realization that proper security development lifecycle and stringent testing procedures with fuzzy testing etc. are more successful approach to catching vulnerabilities. And many closed source shops are better resourced to do this better, and with a more programmatic approach.

Re:Some context from a hardware perspective. (3, Informative)

rahvin112 (446269) | about 4 months ago | (#46510129)

There are many cellphones where there is an independent CPU running the cellular radio. This CPU runs a proprietary OS that runs has write access to all memory and can actually override the main CPU. In theory the radio CPU and OS could actually overwrite memory on the fly and redirect the kernel in completely transparent ways.

Re:Some context from a hardware perspective. (1)

ericloewe (2129490) | about 4 months ago | (#46510623)

I believe it's nearly all phones, if not all of them.

Re:Some context from a hardware perspective. (0)

Anonymous Coward | about 4 months ago | (#46510289)

Don't give him any ideas, he's already batshit enough.

More context (1)

maestroX (1061960) | about 4 months ago | (#46510559)

reminder for the list; signed code, tivoization, like sigma et. al. firmware support pretty much equals caveat emptor nowadays, I like to re^H^Huse the cpu/mobo for something useful oh well raspberry pi + sim anyone?

Re:Some context from a hardware perspective. (3, Interesting)

AmiMoJo (196126) | about 4 months ago | (#46511111)

Okay, but despite being Turing complete most of those devices could be contained by an open source firmware in a secure way. For example the LED controller is probably what, an I2C device? There is no way it could compromise anything with an even half way competent ACPI implementation. The battery monitor, LCD, GPS and probably a few others probably fall into that category too.

For everything else you need a secure APCI implementation that is based on not trusting the firmware in those devices. Okay, the wifi firmware could intercept, modify or leak any packets, but at least with an open source ACPI implementation the damage could be limited, contained and perhaps detected. It's not perfect but it's a lot better than what we have now.

Shuttleworth wrote ... (1)

tipo159 (1151047) | about 4 months ago | (#46509227)

In ye olden days, a manufacturer would ship Windows, which could not be changed

What the hell is he talking about?

Re:Shuttleworth wrote ... (0)

Anonymous Coward | about 4 months ago | (#46510393)

You know, before Shuttleworth made Linux.

Stallman was right (1)

SplashMyBandit (1543257) | about 4 months ago | (#46509309)

Haha! Shuttleworth now agrees with Richard Stallman's assessment of the situation from thirty years ago.

Hopefully more IT leaders (and users!) also wake up to this.

If you can't control your device all the way down to the hardware, then bad guys will (and very sadly, bad guys now includes the NSA).

This is about ARM 64 bit Servers (3, Informative)

Bill, Shooter of Bul (629286) | about 4 months ago | (#46509359)

Its already been decided by the industry that its going to be ACPI.

And Canonical helped desgin it... with ACPI in it

http://www.businesswire.com/ne... [businesswire.com]

So I don't understand why Mark is suddenly against it. Sudden change of heart leading Ubuntu to be non compatible with other linux operating systems? Again? I don't get it.

Re:This is about ARM 64 bit Servers (0)

Anonymous Coward | about 4 months ago | (#46510071)

So I don't understand why Mark is suddenly against it. Sudden change of heart leading Ubuntu to be non compatible with other linux operating systems? Again? I don't get it.

Did you completely miss the news about the NSA [theguardian.com] ? It turns out that instead of doing their job and defending us, they have been deliberately leaving holes in software and setting us up for our computers to be owned by the Russian mafia.

Anyone who hasn't changed their attitude was either psychic or hasn't read and understood the implications of the fact that almost every bit of mainstream proprietary software has embedded backdoors which are easily discoverable and exploitable by almost every major government. Shuttleworth has every right to have changed his mind.

Re:This is about ARM 64 bit Servers (1)

Bill, Shooter of Bul (629286) | about 4 months ago | (#46511311)

Yes, there are many fears of what a government could do to gain access. There is no way to avoid it currently. Saying ACPI has the potential for problems doesn't add anything new to the conversation that's been going on for years.

I'm guessing someone just informed him what his company agreed to, or he's gone a bit crazy.

Re:This is about ARM 64 bit Servers (-1)

Anonymous Coward | about 4 months ago | (#46510417)

He's suddenly against it because he hasn't had enough attention this month.

Who cares? (0)

Anonymous Coward | about 4 months ago | (#46509379)

We'll just all buy Chromebooks. Linux FTW!!!
 
When HP, Lenovo, Apple and Dell all fail it'll be Linux who will have brought them to their knees. We don't want Windows and we don't need Windows and we don't need Windows fanboys.

blobs? (0)

Anonymous Coward | about 4 months ago | (#46509391)

He's pulling a Theo?
How original...

Because "Open Source" isnt an NSA vector (1)

enigmatic (122657) | about 4 months ago | (#46509587)

Remember GnuTLS

Re:Because "Open Source" isnt an NSA vector (1)

jones_supa (887896) | about 4 months ago | (#46509885)

Yep. For truly secure and non-malicious software we need both open source and thorough code audits (à la OpenBSD).

Re:Because "Open Source" isnt an NSA vector (0)

Anonymous Coward | about 4 months ago | (#46510399)

Remember GnuTLS

And forget about Microsoft TLS, since you will never be able to find out about the holes in that. 'cmon, it was the Linux guys catching a backdoor insertion attempt [freedom-to-tinker.com] which first alerted people to the fact that such attempts are being made.

That ship sailled in the early 90's (1)

Wierdy1024 (902573) | about 4 months ago | (#46509811)

No escaping proprietary firmware now. I would hazard a guess that a laptop purchased today has firmware or firmware libraries from over 1000 teams.

You don't see them, because most are stored in roms and flash, and your OS doesn't need to know about them...

Translation (0)

Anonymous Coward | about 4 months ago | (#46509921)

Vendors don't want our garbage OS so we need an excuse.

Shuttleworth is a publicity whore (0)

Anonymous Coward | about 4 months ago | (#46509975)

Shuttleworth should have long ago done the right thing. He cheated us all out of it by saying we weren't interested. If people recall he even polled the community on this issue. If you ask me that was no excuse for not doing the right thing. Claiming credit now is just publicity whoring.

I stopped giving Shuttleworth's comments any real consideration long ago. He's taken action to invade our privacy (reporting activity to Amazon) and much more. There are people who are actually making a real difference. The Tor project, the Freedombox project, the Free Software Foundation, Richard Stallman, and even at least one company, ThinkPenguin (they sell free software friendly hardware and are concious of all the non-free bits still remaining everywhere despite compatibility with Trisquel, Parabola GNU/Linux, and other 100% free distributions).

This issue isn't just an ethical issue either like so many are bound to spout out. Stop letting emotion get the better of you. It's also a security, privacy, and usability nightmare. Do you really think a for-profit corporation is solely interested in freedom because it's the right thing to do? It might be one of the reasons, but it's definitely not the only reason. It's an ease of use issue that at least one CEO actually gets (ThinkPenguin).

Now we just need to get more projects and companies (looking at you Qualcomm, Intel, Broadcom, AMD, NVIDIA, and others) to follow ThinkPenguin's lead.

Don't we all (0)

Anonymous Coward | about 4 months ago | (#46510081)

Isn't he the guy that takes Debian, sticks in some blobs and brands it Ubuntu?

in a good mood (0)

Kevin Fishburne (1296859) | about 4 months ago | (#46510959)

Mark must have gotten laid recently. Or had lunch with Richard Stallman. Or...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>