Feeds

back to article Shuttleworth: Firmware is the universal Trojan

Canonical boss Mark Shuttleworth has called on the world to abandon proprietary firmware code, calling all such code “a threat vector”. In this blog post, Shuttleworth makes the case that manufacturers are simply too incompetent, and attackers (including government security agencies) too competent, for security-by-obscurity in …

COMMENTS

This topic is closed for new posts.

Page:

Wow

This would have to be the most intelligent thing I have heard Shuttleworth say!

39
1
Silver badge

Re: Wow

It is indeed bang on. "Abandon proprietary firmware code."

Not only is it a vulnerability as we've seen over and over again, but it is often deliberately feature poor.

To really do a good job, let's get rid of the "proprietary firmware" that is the pre-installed OS on store bought computers.

22
4
Linux

Re: "deliberately feature poor"

And Windows-centric.

11
3
Silver badge

Re: Wow

"This would have to be the most intelligent thing I have heard Shuttleworth say!"

Really? So what, a washing machine manufacturer is going to post a message on the linux mailing list or sourceforge saying "Hey guys, we need some firmware writing for our new 1200 spinspeed model. Any takers?" Or is it just a case of lets publish all source code and hope someone understands servo motor controller XYZ123 well enough and gives enough of a toss about washing machines to spot coding errors?

Please.

I like Linux as much as the next guy - been running it at home since 93 - but I'm getting a bit tired of this whole OSS is the solution to all our software problems. If that were the case how come Shuttleworth came up with an abortion like Unity? If anything should be got rid of its that festering dogs dinner.

The people who write firmware are usually experts in that particular field and I for one do NOT want some have-a-go amateur writing, for example, the baseband software for my mobile phone or the controller of the lift I use in the mornings. And nor frankly do I want Linux running everything. Its complete overkill for a lot of applications and KISS still applies in the 21st century.

Sure, some firmware has faults, but compare the number of those against the firmware you use everyday without even thinking about it.

9
12

Re: Wow

Downvote from me for misunderstanding Open Source software on a fundamental level.

"Have-a-go amateur"? Almost all major open source projects are supported by commercial interests. The Linux kernel is contributed to in a very significant manner by big name corporations, not have-a-go amateurs.

http://www.linuxfoundation.org/publications/linux-foundation/who-writes-linux-2013

11
7
Silver badge

Re: Wow

>Downvote from me for misunderstanding Open Source software on a fundamental level.

Sorry pal, its you who doesn't understand it. The point of Open Source is that the code is available for anyone to look at - it matters not who funds it or otherwise.

>"Have-a-go amateur"? Almost all major open source projects are supported by commercial interests.

>The Linux kernel is contributed to in a very significant manner by big name corporations, not

>have-a-go amateurs.

And the "major" projects will be outnumbered 1000-1 by all the smaller OSS projects out there. So have a go amateur is an entirely valid epithet especially since there are plenty of those who still contribute to the linux kernel. And I don't mean it in a negative way , I just mean someone who isn't employed to write some code but does it anyway and perhaps isn't an expert in the field.

PS - it might help if you posted links that don't require registration before view.

2
7

Re: Wow

You're missing the point. The suggestion is not that hardware manufacturers absolve themselves of the responsibility to write their own firmware by calling in the "amateurs". They're free to do that, of course, if they want to see their sales plummet.

The idea is that after writing their own craptastic drivers that they then publish the code. This lets competent people look for security holes, and allows the amateurs to fix or re-write the code. This presents the users with the option of loading alternative firmware, and it allows the hardware vendors the option of absorbing new code into the "official" release.

10
2

Re: Wow

Also: I'm not sure if you're making a separate point, or if you're actually suggesting that Shuttleworth is wants all firmware to be written in Linux. He explicitly states that he things declarative software is the best option. That's obviously not any type of OS, it's more like a static reference book.

I don't know of too many knowledgeable people who consider Linux to be "the answer to everything". While Linux can actually be stripped down quite nicely for low-end devices, of course things like ultra-compact RTS OSs are vital for many embedded applications, and only the terminally ignorant would claim otherwise.

Things like cell-phone baseband stacks will not be over-writeable, ever, because of legal implications and inter-operability concerns. That still doesn't stop security experts finding holes in them and letting the manufacturer know that it needs to patch them before it begins the next round of certification testing.

The same thing applies to any safety-critical systems.

And your comment about firmware specialists being needed to understand the intricacies of particular hardware components is certainly true, but it has no bearing on the issue of the suitability of open-source because, as I mentioned, the idea is not that the writing of firmware be left entirely in the hands of "amateurs".

2
0
Anonymous Coward

Re: @boltar

I have been reading the Reg for a few years and from reading many many articles I have come to this conclusion - All OSS coders, at least on El Reg, are experts in every field and language, and do not make mistakes, EVER. Sloppy coding and security vulnerabilities are for those "Windows" coders.

With this knowledge I sleep soundly every night and I hope you will too.

5
7

Re: @boltar

And another one misses the point by a light year.

It's not that OSS is inherently better, it's that anyone can see how good/bad it is, and then try to improve it, as opposed to relying entirely on Microsoft / Apple / the firmware blob-makers.

5
2
Anonymous Coward

Re: @ Stuart Van Onselen

You missed the point, the previous post was an obvious joke. Get off your high horse and get a sense of humor.

2
4
Silver badge

Re: Wow

"that he things declarative software is the best option"

It seems to me his idea of declarative software is nothing more than a glorified config file. The actual software he wants already written in the kernel. These sort of ideas sound great in theory - abstract everything away and just twiddle a few knobs to suit - but in practice it never works well because they're are just too many gotchas quirks and unknowns.

1
1
Anonymous Coward

Re: @boltar

> anyone can see how good/bad it is

But almost nobody does.

And therein lies the elephant in the room.

2
0
Silver badge

Re: Wow

The suggestion is not that hardware manufacturers absolve themselves of the responsibility to write their own firmware by calling in the "amateurs". They're free to do that, of course, if they want to see their sales plummet.

The idea is that after writing their own craptastic drivers that they then publish the code. This lets competent people look for security holes, and allows the amateurs to fix or re-write the code.

It also allows other competent people to look at what commodity chips the hardware manufacturer has put onto the breadboard and produce a knock-off for virtually no investment.

It also provides insight into any proprietary algorithms you use, eg wifi firmware frequently has (had?) proprietary rate algorithms, and nVidia and ATI keep the very proprietary bits of their drivers in their firmware.

Shuttleworth doesn't care about any of that though, since he is an ideologue and this gets in the way of his faith. Yes, it would be fucking awesome if we had at those bits and pieces, but it would suck balls if it meant that hardware was either more expensive, less readily available or not developed.

1
2

Re: @ Stuart Van Onselen

Sorry, AC.

But never assume that a joke is "obvious" to everyone else, because there are always overly-literal wankers (such as myself) who will take it seriously. And it's even more likely that someone will misunderstand when there are so many similar posts made in absolute seriousness in this very thread.

0
0

Re: Wow

It also allows other competent people to look at what commodity chips the hardware manufacturer has put onto the breadboard and produce a knock-off for virtually no investment.

nVidia and ATI keep the very proprietary bits of their drivers in their firmware

As has already been pointed out, a sufficiently motivated and well-funded commercial rival can always disassemble the blobs and get at these "crown jewels" anyway, for all the good that does them. You see, ATI, nVidia, et al are not using just all off-the-shelf parts to make their stuff, and it's extremely difficult to reverse-engineer a billion-gate custom chip whether or not you have the firmware at hand. So they have very little to fear from open-source firmware, it's mainly paranoia and the bean-counters holding them back.

1
0
Silver badge

He's right... and wrong!

Like with most things in life, the truth is somewhere between the extremes.

Yes, firmware is increasing becoming a potential vector. These days we have gone far beyond system designs where the CPU does everything and the OS is the gatekeeper of the CPU and thus what happens in the system. We now have increasingly sophisticated peripherals which are bus masters in their own right. They range from ethernet/serial/communication subsystems to graphics subsystems and lots, lots, more. Since many of these are bus masters, they can access any memory or peripherals in the system. Naughty firmware can very easily expose your whole system to the network. Thus, the threat is more than just technically feasible.

So full marks to Shuttleworth for identifying a problem. Nothing new in this though - people have known of this for ages. It has even been discussed in hushed, and less hushed, voices in Reg commentardsville. Due to lack of originality we'll give him a C.

But the solution... He doesn't know what he's talking about.... I've been in embedded system design for over 30 years now and I wish it was a tenth as simple as he makes out.

Firmware typically needs to be incredibly responsive and run on very cheap hardware. That will always mean that people writing firmware will push the envelope. Pie-in-the-sky solutions seldom deliver anything. And, at the end of the day it is still code and needs to be written by people who are not aware of the full implications of what they are doing.

So shuttleworth gets an F for that part of the paper.

15
7
Silver badge

Re: He's right... and wrong!

Wouldn't it be nice to be sure you do not have NSA firmware in your hard disk that will hand over the drive encryption key to anyone that knows the NSA's secret handshake? How about replacing a camera's firmware to make it a standard UVC device or to make the LED always come on when it is recording? Would you like to know if your 32GB HDLC card contains 32GB, or 8GB with some lying firmware that will crash and burn when it gets quarter full.

Given proper documentation, people will do these things for themselves and share them with others. They will use Linux when it is the right tool for the job or something smaller when Linux does not fit. I can understand Mr Shuttleworth simplifying the message. Imagine what what the Daily Wail or the Grauniad would do with a technical quote over 5 words. A proper IO MMU on USB interfaces was overdue last decade. Try explaining why to a non-technical journalist and see what headline he comes up with.

Enough of the UK government now understand the value of open standards sufficiently to mandate ODF. It took them under a decade to catch on. Several other governments took less time. The same thing will happen with open firmware. Techies want it now. People will want it soon. Progressive governments will mandate it later. Manufacturers will then hire coders to maintain it, and in about fifteen years members of the Conbour party will draft a law requiring it on new purchases.

7
2
Boffin

Re: He's right... and wrong!

Wow, I wasn't even thinking about hard drive firmware. If you're really paranoid, you can employ full-disk encryption on that. Bus master peripherals are trickier...

I was thinking more like coreboot, based on LinuxBIOS. There's no fundamental reason for the motherboard firmware to be proprietary software, when motherboard makers suck at writing firmware and free alternatives exist.

9
1
Bronze badge

Re: He's right... and wrong!

>Firmware typically needs to be incredibly responsive and run on very cheap hardware.

That's precisely the code I would like to see written by enthusiasts, not corporate drones. You know the demo scene? One sub-genre is making really limited hardware like C64 do things you would never have thought possible with it...

7
3
Silver badge

Re: He's right... and wrong!

And a lot of the router "firmware" problems are old versions of Linux running on routers not being patched and allowing vulnerabilities through, as well as the proprietary stack on top of Linux.

As Charles stated, the actual firmware is a known problem, but the proposed solution is a backwards step, especially in the IoT, where low power and highly efficient SoCs or ICs are called for, pushing all of that back out to a general purpose CPU, more memory and storage is going to drive the price and power consumption up, whilst reducing efficiency.

Better standards for testing security and more transparency are called for.

4
4

Re: He's right... and wrong!

I dispute this. I used to write BIOS/Firmware code and there is no reason why the handoff cannot take place in a different manner. The firmware could also be open sourced, what there is of it, and kept to a minimum.

I understand the things that take place on this boundary (within my own area of expertise anyway) and there was never any real discussion of these issues. Had there been then we could have either (a) Made the BIOS/Firmware open (since it is supposed to be minimal anyway) and/or cut back on what BIOS did. Typically I was writing in assembler/C for the firmware and you could put all sorts of back doors in there if you wanted. I bet there are loads of them in POS machines (as has been proved).

7
0
Bronze badge
WTF?

Re: He's right... and wrong!

Indeed, firmware is a vulnerability. Indeed, it would be better if it would all be open source. However, the "general solution" of not having embedded executable code is idiotic on such a monumental scale, it beggars belief.

Perhaps it would work in the specific context of BIOS / ACPI he is generally writing about - but to have ALL hardware dangling on the CPU as some basic I/O... good grief. What is he thinking?!? How does he expect to push through ever-increasing resolution from a camera through USB if there isn't anything running on the other side of that, pre-compressing stuff first...? And that is a prime target for infection - let's just remember the rogue firmware that redefined the camera as a camera+keyboard and started "typing" into the OS, breaking out of its VM! Or does he intend to read and write HDD heads on-the-fly as CPU I/O as well...? If so, he's delusional. If not, his point is extremely poorly worded. Kudos either way.

As far as I'm concerned, I still remember the times when "soft modem" used to be a swear-word. Nothing has changed merely because now we have more CPU cycles...

4
0
Bronze badge

Re: He's right... and wrong!

"How about replacing a camera's firmware to make it a standard UVC device or to make the LED always come on when it is recording?"

My first thought was the Magic Lantern firmware add-on for Canon cameras to provide a whole host of improved functionality for videographers such as being able to turn off the Automatic Gain Control and a bunch of video stuff which for obvious reasons is generally a poor cousin to the stills functionality.

It's entirely proprietary and undocumented - Canon would really rather you didn't, and bought a nice expensive video camera off them as well, so the guys behind it reverse engineered the DIGIC processor by literally just putting an LED on the board and reverse engineering it from the hardware up. Quite a feat of brain power and logic!

If man can make it, man can break it...

3
0
Anonymous Coward

Re: He's right... and wrong!

Given proper documentation, people will do these things for themselves and share them with others

Yes and no. Firmware can also contain clues to business secrets, to the way a supplier has managed o speed up graphics etc. so I can see the other side of the coin as well - that does not mean I disagree with the idea of open code, just a realisation that it's not quite as easy as it seems.

As for flashcards and wrong size reporting - if you find a way to tell the firmware of a hard disk to mark its allocated contents as bad blocks, you will find that that content is no longer touched, and that includes any wipe or delete routines. Worth thinking about..

3
0
Anonymous Coward

Re: He's right... and wrong!

That's precisely the code I would like to see written by enthusiasts, not corporate drones

Oh really? And abandon, say, QA and other trivial things? A for enthusiasm, but you may need to think about this a bit more.

4
4
Silver badge

Re: He's right... and wrong!

As for flashcards and wrong size reporting - if you find a way to tell the firmware of a hard disk to mark its allocated contents as bad blocks, you will find that that content is no longer touched, and that includes any wipe or delete routines. Worth thinking about..

Is this true even on the low level?

0
0
Bronze badge

Re: He's right... and wrong!

>Oh really? And abandon, say, QA and other trivial things?

Of course not. This could work analogously with Red Hat's RHEL, with the companies using the firmware doing QA on their hardware.

Besides the existing state of firmware QA isn't stellar either. Eg., I have a big.brand DVD recorder / DVB-receiver combination that locks up almost always when it sees disk it does not like (wrong format, or too scratchy). The great corporate QA department obviously tested it only with perfect disks.

5
0
Silver badge

Re: What is he thinking?!?

What he's thinking is that there's only one part of the stack that gets reliably* updated: the OS. We all patch it on a monthly basis. If security of your system is only as good as your last path (which all too frequently it is), the logical solution is to make the attached devices read only and have the bits that get patched do all the work.

It's a nice neat theoretical solution. It's practicality may be doubtful, but there don't seem to be a lot of practical solutions being kicked around at the moment either.

* if you don't like "reliably" per se, substitute "on average (mean and mode) gets patched the most often," but that wasn't going to be a very readable sentence.

0
0
Silver badge

Who abandons QA?

Half the places I have worked did not know what QA was, and half of those that had some thought it was only there to cause trouble. Microsoft disbanded their test team because they were 'delaying' Vista. The most common attitude I receive in industry is 'It compiles - ship it'. That is quickly followed by 'Version 2 hardware is ready to go, no more work on firmware for version 1. If there is a problem, customers will have to purchase new hardware'.

Take a look at the Debian policy documents some time.

There was an article recently about flying toasters coming back from the dead - presumably on Windows because they never went missing from Linux. I have far more confidence in open source software being tested and maintained than in proprietary.

6
1
Anonymous Coward

Re: He's right... and wrong!

"We now have increasingly sophisticated peripherals which are bus masters in their own right."

Yeah, a really new idea, that. Let me see. CDC 6400 PPs. Network cards on 8-bit PC bus with 80186 processors......

1
0
Bronze badge
Holmes

Unfortunately we need to look at this!!!

Although I already suspected and acted on the "Snowden leaks", WAY before they came out; ALL code is suspect now that the revelation IS out! We need do an entire overhaul of all code to open source! It will not guarantee we won't get cracked, but at least we can keep an eye on it , if we band together and standardize the code! Of course, now that the wide world of the web is not under one domain source control now, we can see chaos in the near future - but it was headed that way anyway - I'm sure of it!

4
1
Silver badge

But then we'd need hardware standards

For example the framebuffer mode of every graphics card would need to work identically. We'd need to have just a small set of USB controllers, and all of that needs to be discoverable by the operating system. Otherwise you'd need to port your OS to every system just like you already need to do in the mobile world.

1
0
Bronze badge

Re: But then we'd need hardware standards

No, the hardware would just have to be documented, no hidden bits needing non-disclosure agreements to see. Of course getting rid of nonsensical variation would be useful, and might be a side-effect of more openness and the requirement to properly and publicly document things (gratuitous changes become more expensive to do).

5
0
Roo
Silver badge

Re: But then we'd need hardware standards

"For example the framebuffer mode of every graphics card would need to work identically."

I'm guessing that the PC BIOSes, CGA, EGA and VGA must have passed you by. :P

As for the USB controllers, there are already standard mechanisms for talking to them (EHCI, OHCI) etc. In fact I think a large part of USB's success and subsequent ubiquity can be attributed to the stuff like the EHCI/OHCI specs. It has saved people writing an awful lot of code that does the same thing but slightly differently !

Reinventing the interfaces for these widgets costs vendors money too, so there is an incentive for these folks to standardise - which is precisely why we have things like VESA, AC97 etc. Standardising stuff can mitigate some of the barriers to vendors releasing docs too (eg: patents) too.

Regards,

Rupert

2
0
Silver badge

Re: But then we'd need hardware standards

Basically, you wanna ban trade secrets. Never gonna happen since trade secrets are one of the valid business differentiators still legal under law. It's what allows for nVidia and AMD to keep trying to one-up each other. As long as there is a need to protect trade secrets or patents (and I mean honest hardware-based patents), then there will always be a need for obfuscated, proprietary hardware to guard against industrial espionage if nothing else.

0
2
Bronze badge

Re: But then we'd need hardware standards

>Basically, you wanna ban trade secrets.

Not at all. Just keep them on the other side of the programming interface. If the trade secret can be seen from the firmware code, it is no trade secret at all, because those with serious financial interest in getting the secrets can get the binary blob disassembled and analyzed. The only people hampered by the binary blob are those who honestly want to program the device.

2
0
Silver badge

Trade secrets

AMD have been publishing hardware specs for years. Nvidia started more recently - because it was to their advantage. You can get detailed specs on the behaviour of an ARM or Intel CPU, but that is nothing to with the implementation. You cannot put the documentation through a PDF to verilog converter. There is no such beast, and never will be.

2
0
Bronze badge

Re: But then we'd need hardware standards @Roo

I think you are confusing interface specifications with firmware. Interface specifications treat the devices on either side of the interface as black boxes; firmware resides within the black box.

What is the real benefit of having the firmware running in my VESA compliant LCD monitor/tv open sourced? particularly as the vendor has most probably not included any way for the firmware to be field upgraded.

Yes there are some things that may theoretically benefit from being open source, however as the various router vulnerabilities and exploits has highlighted: it is one thing to find and fix a bug, it quite another to deploy that fix to devices already in the field.

0
0
Roo
Silver badge

Re: But then we'd need hardware standards @Roo

"I think you are confusing interface specifications with firmware. Interface specifications treat the devices on either side of the interface as black boxes; firmware resides within the black box."

That rather misses the point I was making, ie: that it's possible to have vendors make hardware behave to a standard...

1
0
Silver badge

Re: Trade secrets

AMD have been publishing hardware specs for years. Nvidia started more recently - because it was to their advantage.

Bad example I think - AMD started publishing hardware specs for their graphics cards after they separated out the proprietary bits into loadable firmware modules that you load and run on the card. The firmware then provides the "hardware interface" that is described in the specs - this is what Shuttleworth wants to remove.

0
0

Re: But then we'd need hardware standards

And those with a *really* serious financial interest in getting the secrets can (literally) disassemble and analyze your hardware... the fact it's not software isn't going to stop them.

0
0
Bronze badge

Er, What?

Given that most of the Internet connected smart devices (SmartTV, fridges, home routers, set top boxes) are running on top of some form of Linux kernel already, what's he on about? These are the things that are getting comprehensively hacked, and mostly it is mistakes in the software stack above that is to blame. Whatever way you look at it, it's poor design, implementation and maintenance of firmware that is the root cause, not the lack of Linux inside.

Even if the firmware was standardised and opened up, how's that going to improve things? The result would be that one single flaw would allow hackers to breach all devices worldwide, not just one family of routers from one company. Sure, one single fix would deal with it, but that's not comforting. Imagine if all home routers got compromised and the attacker disconnected them all from the net. How then would anyone be able to get the fix?

If firmware became a standardised open platform there would be pressure to have things like virus checkers, etc running on them. It's happened with Android, why wouldn't it happen with standardised linux based firmware on other devices? And how would old devices be supported? The consequences are that there would be new firmware versions that won't run on older hardware, so we'd have the "Windows XP" style of obsolescence problem on everything, not just our desktops.

So it comes back to good design, and a commitment from manufacturers to maintain and improve their firmware and hardware. Having a real "Read Only" switch on the device so that a hacker physically cannot alter it or install malware would be a very good start.

11
2
Silver badge

Re: Er, What?

Thanks. Most sensible comment yet.

There's an unfortunate tendency for people to leap at the word "open" and declare it a solution for absolutely everything. It isn't.

2
0
Roo
Silver badge

Re: Er, What?

"Even if the firmware was standardised and opened up, how's that going to improve things? The result would be that one single flaw would allow hackers to breach all devices worldwide, not just one family of routers from one company"

Clearly that would be stupid, and it's not what Shuttleworth appears to be advocating. RTFA.

On the other hand that is pretty much the situation as it stands now because vendors tend to use off-the-shelf bootloaders & BIOSes in any case. You don't seriously expect a vendor on razor thin margins to write AND verify a new bootloader / BIOS everytime they ship a product do you ?

Personally I would love to have hardware that sat there inert until I installed the bootloader of my choice on it. I have wasted far too much time working with poorly documented, broken abandonware BIOSes. Moving that stuff up the stack would mean I don't have to learn a new set of tricks everytime I get a new machine to look after.

3
0
Silver badge

And what has closed ever solved?

Take a quick trip to the twentieth century, and see what things were like before the rest of the world knew what open source was. Windows NT for people prepared to pay through the nose for software that worked. Windows ME for home users. Microsoft used its monopoly in operating systems to get monopolies in other fields - networking, office software and browsers. Microsoft were being found guilty of abusing their monopoly all over the world. They were paying millions a day for breaking the rules, but carried on because the fines were not a big enough incentive to stop. They got the judge in the US case replaced with someone who would give them nicer penalties. They were even granted a stay so they could come up with more 'penalties' because they were getting whatever they asked for.

Now look at what open source has given you - the cooperative multi-tasking of DOS/W95/98/ME was replaced by XP at a reasonable cost because of competition from Linux. XP has lasted to this day because the existence of Linux gave you an alternative to Vista and Windows 8. The small cheap computer existed (disappeared and came back again) because of Linux. IE7 and Microsoft's non-standard HTML have gone because of competition from Firefox. Home NAS exists because you can use SAMBA and not need a full price Windows license and hardware big enough to run it. Microsoft tried - and failed - to own the entertainment distribution business because PVR hardware + Linux cost less than a Windows license. Satnavs are a reasonable price because Linux is free and runs on cheap hardware. You do not have to keep BT's spyware in your router because of openwrt. Libre Office is crushing Microsoft Office back into expensive nicheware. Microsoft never got more than their nose into super computing. Imagine the cost of a data centre with a Microsoft license for each CPU - not at today's prices, but at monopoly prices.

Quit literally, all the kings horse's and all the king's men could not stop Microsoft's monopoly power. The thing that did was the Gnu Public License. Back in the twentieth century, the vast majority did not believe that was possible. Fifteen years later, you are the minority.

4
3
Bronze badge

Re: Er, What?

>Personally I would love to have hardware that sat there inert until I installed the bootloader of my choice on it.

Can't see what Mark Shuttleworth is proposing will actually help you. You only need to look at the fun and games of PC motherboard monitoring tools, that are having to be constantly updated to keep pace with the release of new motherboards and chipsets, to see the problems with having application software directly interfacing to hardware rather than via a defined set of BIOS calls.

0
0
Roo
Silver badge

Re: Er, What?

"to see the problems with having application software directly interfacing to hardware rather than via a defined set of BIOS calls."

FYI PC BIOS calls are *very* rarely used these days - most OSes talk direct to the hardware via drivers. The reasons for that include performance, and working around broken PC BIOS design. Not really sure how you could reasonably expect a 16bit PC BIOS to work well with a 64bit OS...

OTOH if you have a static description of the hardware and the OS provides the drivers then you are not tied into using 16bit PC BIOS calls for the next 40 years...

3
0
Bronze badge

Re: Er, What?

>most OSes talk direct to the hardware via drivers.

I think that what most OSes these days talk to, isn't the 'hardware' in the 1980's sense, but as you pointed out in a previous comment, but more to abstract and intelligent 'hardware' such as a USB or SATA controller through a well defined interface. Obviously, we can split hairs over whether this interface is part of the 'official' BIOS or available via direct access (DMA, System Bus, etc.) to the firmware in the controller.

And I get your point about the role of a BIOS in modern systems being much reduced to essential services such as (effectively) providing a static description of the available hardware and bootloader services.

0
0
Bronze badge

Not sure what the best approach is as I do not work in embedded system design, but proprietary firmware blobs are definitely the worst possible solution. Trojans are one problem, the other being their reluctance to allow third parties to redistribute their blobs, which of course is their way of controlling their blobs.

@Charles Manning

Great, you give him an F because his solution is too complex to implement yet you cannot come up with a better one ...

2
4

Page:

This topic is closed for new posts.