FPR5 is coming along very well. If I could sum up the changes in two words, it would be "MOAR ALTIVEC." Two other words I'd use are "stay tuned" and "totally awesome" and "amazing programmer" and "very modest."
Monday, December 4, 2017
Sunday, November 12, 2017
The usual advice well-meaning but annoying people will give us Power Mac users is, "there are many security holes in your machine, so you shouldn't ever use it on the Internet." The first part is true. The second part is, at least right now, not. You just have to understand where the vulnerabilities lie, patch the holes you can, and mitigate the vulnerabilities that you can't. However, doing so is absolutely imperative and absolutely your responsibility. If some easily remotely exploitable bug surfaces that cannot be mitigated or blocked, I'll change my tune here, but that's not presently the case.
The most important thing to keep in mind is that, as virtually all the regular readers of this blog know, Power Macs use a completely different architecture than the majority of what's out there today, and this has important security ramifications. The vast majority of presently extant low-level exploits like buffer overflows and use-after-frees broadly depend on being able to deposit Intel or ARM machine code in memory and have it executed by the victim application, but our instruction set and (often) memory layout are completely different, so any such exploit would have to be specific to PowerPC to successfully execute. At worst, an non-PowerPC exploit of this type would just crash the application or, in extreme cases, the machine. While the more security conscious amongst you will (correctly) point out this is a special example of "security by obscurity," that doesn't mean this heterogeneity isn't an advantage. Attackers go where the money is, and it's not our machines. No current Intel Mac can easily generate code that will run on a Power Mac without a lot of work either.
So as promised, here's an updated practical guide to keeping your beloved Power Mac safe, or at least safer, today 11 years and nine operating system releases after the last Power Mac rolled off the assembly line. This post is hardly comprehensive and you should not assume it covers all relevant deficiencies, but, for the record, these are the recommendations I myself use on my own systems. I reference prior blog posts here you can read for more details, but this guide will cover the basic notions and try to give you an idea of priority. Please note: this document primarily applies to systems running 10.4 and later. The classic Mac OS through OS 9.2.2 has an extremely small attack surface because of its radically different architecture, and while browsers on OS 9 (including, though this is improving, Classilla) are subject to information leakage attacks and should not run Flash or Java, other kinds of attacks are almost impossible upon it. There are a few exceptions noted below. For 10.0 through 10.3, however, there are sadly much fewer good options for securing these systems, and I would simply advise putting them behind a good firewall and assuming everything you do on them is not secured.
Obviously, I also assume for the below that you're running the current version of TenFourFox and can securely download additional tools if necessary!
Make sure your clock is set correctly: certificate verification will fail if your clock is off more than a few minutes in either direction. Particularly on 10.4 systems (but also observed on 10.5), systems with long durations of uptime without sleeping or being shutdown may go out of synchronization with any time server you use. The first and easiest way to reestablish the connection to your timeserver is either by rebooting, or unchecking and then re-checking the time server checkbox in System Preferences. If your system is powered on and off regularly you may not have a need even to do this much. However, if this is insufficient and you are comfortable with the command line, you could try the more definitive solution in our article.
Consider using a non-admin account for basic activities: this will ensure that, if a old PowerPC-compatible exploit or Trojan horse is around and does get through, the damage is limited. At least one well-known OS X Trojan horse circulated in a PowerPC-compatible version as late as 2012!
Why do I have to enter my password? Consider this every time you're asked for it; a little paranoia is just good common sense. Ask yourself, does this application actually need administrative access? Or is this program doing something other than it claims?
Security issues with connectivity and networking
Built-in networking: On OS X, enable the built-in firewall in System Preferences (Sharing, Firewall) and enable stealth mode, and if you can, also Block UDP Traffic from the Advanced menu within that preference pane. This substantially reduces the surface for incoming network threats. Using a hardware firewall is even better, especially in combination, as well as disabling UPnP on your router if your applications don't require it; in fact, my personal daily drivers live on a specially secured wired network that cannot directly route to the Internet. There are a number of possible exploits in the network-accessible components of 10.4 and 10.5 and simply preventing access to them in this fashion is probably the best approach. Note that UDP is still necessary for some kinds of protocols such as local Windows file and printer sharing (in that case, blocking it at the router level rather on individual Macs would be more appropriate), and disabling UPnP may be problematic for some applications.
WiFi: All Power Macs are subject to the KRACK attack and there is no known client-side fix (more info). The problem can be mitigated by going into your router settings and selecting WPA2 (not just WPA!) AES-CCMP as your only means of Wi-Fi security, which some routers may abbreviate to just "AES." Do not use TKIP. Routers may also be vulnerable, particularly if your router is itself a client to another WiFi network such as being in repeater mode; you should check to see if a firmware update is available, and consider another router if necessary.
Although AES-CCMP is much more resistant to attacks than TKIP and an attacker cannot actually join a network secured with it, they could clone your access point to a second access point with the same SSID and MAC/BSSID on a different channel and entice you to transparently connect to that. This is not very likely in a controlled home environment, but it could be an issue for public Wi-Fi or close quarters like dorms or apartments. Immediately disable Wi-Fi if you see two copies of the same network; it could be an attempt to snare you. See our article for a more in-depth way of detecting such an attack.
If you are on a public Wi-Fi connection you can't control, you should assume your connection is completely insecure (the same applies for WEP, such as on Mac OS 9, which does not support WPA2 natively, or WPA). Use a VPN if you have it available, and/or only connect to secure hosts, such as over HTTPS and SSH, to layer your connection with a secondary level of encryption. A better browser can help ... like, I dunno, TenFourFox. Just a suggestion.
Bluetooth: All Power Macs are potentially vulnerable to BlueBorne-based attacks, though the practical likelihood of being exploited is low (more info). These attacks are generally low-level and would need to be specific to PowerPC to function, but could be a source of system instability if a malicious Bluetooth device is broadcasting poison packets with Intel or ARM code embedded in them. Keep Bluetooth off if you don't need it except in controlled environments; when tethering, if a malicious device is likely to be in range, Wi-Fi is probably safer even with the caveats above.
Hardening OS X
These are well-known vulnerabilities in OS X which can be, in some cases, exploited remotely.
sudo at the wrong time: Because a password is not required to change the system date and time (either with System Preferences or using systemsetup from the command line), an attacker can set the clock wrong and then dupe vulnerable versions of the sudo utility, which allows you to run commands with administrator permissions, to acquire that same administrative access without authentication. This is due to a convenience in sudo where repeated use within a certain interval does not require a password; thus, the simplest and most secure solution is to always require a password. Start a Terminal window (or start /Applications/Utilities/Terminal) and enter the following commands:
- sudo visudo (enter your password)
- Using the vi editor which then appears, add the line Defaults timestamp_timeout=0 at the end. If you don't know how to use vi, type these key strokes:
- 0G (the number zero, and a capital G)
- o (lower case "o")
- Defaults timestamp_timeout=0
- Press the ESCape key and then type :wq! (colon, lower case "w", lower case "q", exclamation point) and press ENTER.
RootPipe/systemsetupusthebomb: This is an actual flaw in another privileged system component called writeconfig that can be exploited to write arbitrary files with root permissions, also giving an attacker administrative access. The simplest fix is to go to System Preferences, and under Security, check "Require password to unlock each secure system preference" (and make sure the lock at the lower left is locked). Now any known use of the vulnerable tool will either fail or at least prompt you for a password. This covers all known exploits for this component, but for a more comprehensive approach (that may have side effects), see the original article.
Shellshock: The version of the Bourne again shell (bash) that comes with all PowerPC versions of OS X is susceptible to Shellshock, a collection of methods of causing the shell to execute arbitrary commands passed to it through environment variables. Although of particular concern to anyone using their machine as a server, it is possible to use this exploit even on single-user systems in more limited circumstances. All versions prior to 4.3.30 are vulnerable. If you have never fixed this on your system, then download the patched version of bash 4.3.30 that we provide as a community service and follow these directions exactly:
- Put the file in your home directory and double-click to decompress it. You should be left with a file named bash-4.3.30-10.4u. Do not change the name.
- Close all terminal windows and programs if they are open, just to make sure you won't stomp on bash while a program is trying to call it. Start /Applications/Utilities/Terminal and have exactly one window open.
- In that Terminal window, type these commands exactly as shown. If you get any errors, STOP and ask for help.
- exec tcsh
- chmod +x bash-4.3.30-10.4u
(IMPORTANT! If you replaced /bin/bash (and/or /bin/sh) with any earlier version using these commands, DO NOT ENTER THE NEXT TWO COMMANDS. If you have never replaced them, then do go ahead; these will put the old ones in a safe place just in case.)
- sudo mv /bin/bash /bin/bash_old (enter your password)
- sudo mv /bin/sh /bin/sh_old (enter your password; if you don't get prompted again, you need to fix sudo with the steps above!)
Everybody does these:
- sudo cp bash-4.3.30-10.4u /bin/bash (enter your password)
- sudo cp bash-4.3.30-10.4u /bin/sh (enter your password)
- Restart your Mac as a paranoia to make sure everything is using the new copy of bash.
Other vulnerabilities in OS X built-in software
Although there aren't updates for most of these, you should at least be aware of the actual risk, and how to reduce it.
Some of the entries in this and the following sections reference plugins. These are usually stored in /Library/Internet Plug-Ins, but there may be per-user plugins installed in Library/Internet Plug-Ins in your home folder. You can disable them as recommended below by simply moving them to another folder, or deleting them outright if appropriate.
Java: Java is not safe on Power Macs; all versions of Java provided on any PowerPC-compatible version of Mac OS or OS X have serious well-known vulnerabilities. In particular, exploits such as Flashback can obtain system access in a cross-platform fashion. If the Java plugin is on your computer, it should be removed or disabled (or use TenFourFox, natch, which won't even run it), and you should only run signed Java applets from trusted sources if you must run them at all.
QuickTime: There are historical PowerPC-based exploits for certain codecs in QuickTime, though none of these are known to be circulating now, and no specific PowerPC-based exploit is known for QT 7+ generally. (While QT 6.0.3 in OS 9/Classic is technically vulnerable, the limitations of OS 9 make the exploit difficult and it would have to be specific to both OS 9 and PowerPC.) It is possible for QuickTime playlists and certain other kinds of scriptable content to be used to load data over the network, but they can be only interacted with in limited ways, and to actually use them for executable data would require a PowerPC-compatible attack. While such an attack is feasible and possible, it isn't very likely to occur or succeed on a Power Mac. This mode of attack can be minimized further by removing or disabling the QuickTime Plugin (or use TenFourFox, natch, which won't even run it); removing the Plugin won't affect using the QuickTime Player.
WebKit and Safari: Safari, and many other software packages, uses the version of WebKit on the system to render web pages and other network, HTML and image assets; it is, essentially, the built-in "WebKit shell." With the exception of OmniWeb, every PowerPC-compatible WebKit-based browser (Safari, iCab, Roccat, Stainless, Demeter, Shiira, etc.) relies on the version of WebKit the operating system provides, which means they inherit all the bugs and security issues of the built-in WebKit framework as well as any bugs in the shell they provide. (Gecko-based browsers bring their own libraries with them, but we're the only Gecko-based browser still updated for PowerPC OS X.)
I'm sure all of you are enthusiastic daily drivers of TenFourFox, but WebKit should also be updated because of how many other apps depend on it. For 10.5, of course, the best solution is Tobias' Leopard WebKit. Leopard WebKit not only includes a very current WebKit framework, but also includes an updated OS Security framework, and can relink WebKit shells and other programs using a provided utility.
Unfortunately, a similar supported option is not available for 10.4. TenFourKit, also written by Tobias, does update the system framework somewhat but does not include security or encryption updates, and has not received any updates since 2012; it's basically the same version as the framework built-in to the OmniWeb browser. For this reason, you should avoid Safari and other WebKit shell applications like iCab on 10.4, as they will not be sufficiently protected, and you should be cautious of apps that attempt to display web pages over the network since the vast majority will use the built-in WebKit also. Because the OS's security framework is also not current, many secure sites will either not connect properly, or throw inexplicable errors.
Currently all WebKit shells support, and will instantiate, plugins (TenFourFox doesn't). I still advise disabling them or removing them where appropriate, but if you can't do this, ClickToPlugin will at least reduce drive-by risk in Safari.
Mail.app: Mail uses the built-in system WebKit (as above), and may have other deficiencies which are not patched. These deficiencies likely require PowerPC-specific exploits, though Apple Mail's general lack of updates implies other vulnerabilities likely lurk such as information leaks and inadequate connection security. Although Tenfourbird (an unaffiliated project) was once a solid and secure alternative, it has not been maintained since version 38.9 as of this writing, so unfortunately I am no longer able to generally recommend it. The simplest and safest approach is simply to use a webmail service instead in TenFourFox or Leopard WebKit unless you absolutely must have a local mail client; in that case, I would use Tenfourbird over Apple Mail, since it is at least more up to date.
Major third-party and optional software vulnerabilities
Your web browser: Currently TenFourFox (10.4+), Leopard WebKit (10.5 only) and Roccat (10.5 only) are known to be updated on a semi-regular basis (we issue TenFourFox releases with security updates, updated certificates and pinned keys every six weeks simultaneously with Firefox ESR updates). No other browser is current, though at least a re-linked WebKit shell will have fewer vulnerabilities. Note that Roccat also needs to be relinked with Leopard WebKit for maximum security.
Flash: Flash is not safe on Power Macs; all PowerPC-compatible versions of Adobe Flash Player have serious well-known vulnerabilities. The cross-platform Rosetta Flash exploit is able to steal credentials and cookies with 10.1 and earlier versions of Flash, and the recommended server mitigation does not fix the problem in these versions (only Flash 10.2+). Furthermore, Flash applets have been previously demonstrated to attack network settings in a cross-platform fashion, and there are other sandbox escape vulnerabilities that have been reported. Although unofficial "later" versions of the Flash plugin have circulated for Power Macs, these are still Flash 10.1 internally with a bumped version number and do not actually have any fixes. Unless you have content that absolutely cannot be viewed without Flash, you should remove or disable the Flash plugin (or use TenFourFox, natch, which won't even run it); a tool like SandboxSafari or the experimental PopOut Player can help reduce the risk for legacy content that still requires it.
Microsoft Office and OpenOffice/NeoOffice/LibreOffice: None of these office applications is currently updated for Power Macs and all of them have potential vulnerabilities to Word and Excel macro viruses, though the OpenOffice derivatives are much less likely to be successfully exploited. For Word it is unlikely you will want macros enabled (and you should definitely turn them off in the preferences except for those rare situations in which they are needed), but this could be a real issue for Excel power users. Office v.X, and Office 98 in Classic/Mac OS 9, are probably too old to be effectively pwned, but many macro attacks against Office 2004 and 2008 will run on Power Macs and the Open XML Converter can be attacked in some of the same ways. Microsoft, damn their Redmond hides, does not offer any of the updaters prior to Office 2008 for download anymore, but I've archived some of them on the Gopher server. For Office 2008, start here (note that you may need to download earlier service packs, which are currently still available as of this writing). Note that Office 2008 cannot run Visual Basic for Applications (VBA), which is a drop in functionality but also a reduction in attack surface, nor can the OpenOffice alternatives. NeoOffice has not been updated for PowerPC in some time; 5.2.0alpha0 is the last version of LibreOffice for Power Macs and is generally my recommendation, but you can also download OpenOffice 4.0.0. All will run on 10.4+.
Note that while iWork/Numbers does support some Excel macros, it does not support VBA and seems to have some issues interpreting macros in general, so it is less likely to be exploited. The venerable AppleWorks nee ClarisWorks is also not known to have any serious vulnerabilities.
Microsoft Virtual PC (and other PC emulators): I won't belabour this point except to say this depends greatly on what you run inside the emulator. Remember that a virtual machine installation of Windows can be just as hosed as a real installation, and can be an even greater malware risk if it has network access. Some Linuces will still run in VPC (I used to use Knoppix). Otherwise, stick to Windows and patch patch patch, and/or completely disable networking or enable bridged mode, which uses your Mac as a firewall for the emulated PC, as appropriate.
Watch this blog as other security-related posts appear. Yes, your Power Mac has holes, but until such time as they can't be plugged or the system is no longer fit for your purpose, nothing says the only choices are a forced upgrade or sit unprotected. So far we've made our systems last over a decade. I think we can still safely keep them viable a while longer.
Friday, November 10, 2017
For FPR5 the big goals are expanded AltiVec (enable strchr() everywhere else, finish as much as possible of the AltiVec VP9 intra predictors), some DOM and Web compatibility improvements, and some additional performance improvements primarily in the session store module and the refresh driver. More on those soon.
Tuesday, November 7, 2017
On to the main event. One of the computers in my stable of systems is my beloved Power Macintosh 7300, a classic Old World beige PCI Power Mac. This 7300 served as my primary personal computer -- at that time with a 500MHz Sonnet G3, 192MB of RAM and a Rage Orion 3D card -- for about three and a half years and later became the first gopher.floodgap.com before I resurrected it as a gaming system. Currently it has 1GB of RAM, the max for this unit; the same Rage Orion (RAGE 128 GL) 3-D accelerator, which I prefer to PCI Radeons for those games that have 3-D support but weren't patched for various changes in the early Radeon cards; two 7200rpm SCSI drives; a 24x CDROM; a (rather finicky) Orange Micro OrangePC 620 "PC on a card" with 128MB of RAM and a 400MHz AMD K6-II CPU; and, most relevantly to this article, a Sonnet Crescendo/PCI 800MHz G4 CPU upgrade card, running a PowerPC G4 7455 CPU with 256K L2 cache at CPU speed and 1MB of L3 at 200MHz. The system boots Mac OS 9.1 and uses CPU Director to disable speculative access and, for those hardware situations that require it, L2 and L3 caches.
Overall, this system runs pretty well. It naturally can chug through Classilla pretty well, but it also has the Mac ports of a large number of games from a smattering of 68K titles to software-rendered titles like Doom, System Shock, Full Throttle, Wing Commander III and up through 3-D titles near the end of OS 9's life such as Shogo MAD and Quake III and its derivatives like Star Trek Voyager: Elite Force. The PC card boots both Windows 95 OSR2 and Windows 98 to run games like Outlaws and Dark Forces II: Jedi Knight that were never ported to PowerPC Mac OS or OS X.
It's a project of mine to trick this sucker out, which is why I jumped at the chance to buy one when three of the nearly unobtainium 1.0 GHz G4 Sonnet Crescendo/PCI cards turned up on eBay unused in original boxes and factory livery. Although Sonnet obviously makes faster processor upgrades for later Power Macs, and in fact I have one of their dual 1.8GHz upgrades in my FW400 MDD (the Mac that replaced the 7300 as my daily driver), this was the fastest you could cram in a pre-G3 beige PCI Power Mac, i.e., pretty much anything with PCI slots from the 7300 to the 9600. Only the sticker on the box would have told you this was more than the prior top-of-the-line 800MHz card; nothing else mentioned anything of it, not even the manual (an info sheet was tucked inside to reassure you). The urban legend goes that Sonnet's board manufacturer under contract was out of business and Freescale-Motorola was no longer producing the 800MHz 7455. This was clearly the end of the Crescendo/PCI product since it didn't make enough money to be redesigned for a new manufacturer, but left Sonnet with about 140 otherwise useless daughtercards for which no CPU was available either. Possibly as an enticement, Freescale offered to complete Sonnet's order with 1GHz parts instead, which would have been a more-or-less drop-in replacement, and Sonnet quietly sold out their remaining stock with the faster chip installed. Other than a couple blowout NOS deals, all of which would sell out nearly instantly, this was the first time in years that I ever saw one of these cards offered. (I won't comment on the price offered by this gentleman, but clearly I was willing to pay it.)
The Crescendo/PCI cards struggle against the relatively weak system bus speed of these Macs which tops out at 50MHz. I've heard apocryphally of hacks to exceed this, but the details are unknown to me and all of them also allegedly have compatibility problems ranging from moderate to serious, so I won't discuss them here. To counter that, the 1GHz card not only increases its L3 cache speed from 200MHz to 250MHz (using the same 4:1 multiplier as the 800MHz card it's based on), but doubles its size to a beefy 2MB (the L2 cache remains 256K, at full CPU speed). The system must slow to the bus speed for video and other peripherals, but CPU-bound tasks will hit the slower RAM much less. None of this is unusual for this type of upgrade, and anyone in the market for a card like this is already well aware it won't be as fast as a dedicated system. The real question for someone like me who has an investment in such a system is, is it worth finding such a beast to know you've pushed your beloved classic beige Mac to its absolute limit, or is the 800MHz card the extent of practicality?
First, let's look at the card itself. I've photographed it front and back compared with the 800MHz card.
With the exception of some minor board revisions, the two cards are nearly identical except for the stickers and the larger heat sink. More about that in a moment.
If your system already had the 800MHz card in it, the 1GHz card can simply be swapped in; the Mac OS extension and OpenFirmware patches are the same. (If not, the available Sonnet Crescendo installers will work.) Using my lovely wife as a convenient monitor stand while swapping the CPUs, for which I still haven't been forgiven, I swapped cards and immediately fired up MacBench 5 to see what difference it made. And boy howdy, does it:
The card doesn't bench 3.33x the speed of the baseline G3/300 used by MacBench, but it does get almost 2.5x the speed. It runs about 25% faster than the G4/800, which makes sense given the clock speed differential and the fact that the MacBench code probably entirely fits within the caches of both upgrade cards.
Besides the louder fan, the other thing I noticed right away was that CPU-bound tasks like Virtual PC definitely improve. It is noticeably, if not dramatically, smoother than the 800MHz card, and the responsiveness is obviously better.
With this promising start, I fired up Quake III. It didn't feel a great deal faster but I didn't find this surprising, since beyond a certain threshold games of this level are generally limited by the 3D card rather than the CPU. I was about to start checking framerates when, about a minute into the game, the 7300 abruptly froze. I rebooted and tried again. This time it got around 45 seconds in before locking up. I tried Elite Force. Same thing. RAVE Quake and GLQuake could run for awhile, but in general the higher-end 3-D accelerated games just ground the system to a halt. Perhaps I had a defective card? Speculative I/O accesses were already disabled, so I turned off the L2 and the L3 just to see if there was some bad SRAM in there, though I would have thought the stress test with MacBench and Virtual PC would have found any glitches. Indeed, other than making OS 9 treacle in January, it failed to make any difference, implying the card itself was probably not defective. My wife was put back into monitor stand service and the 800MHz card was replaced. Everything functioned as it did before. So what happened?
In this system there are two major limitations, both of which probably contributed: heat, and power draw. Notice that larger heat sink, which would definitely imply the 1GHz card draws more watts and therefore generates more heat within a small, largely passively cooled case in which there are also two 7200rpm hard disks, a passively cooled 3D accelerator and an actively cooled PC card. Yes, all those little fans inside the unit certainly do get a bit loud when the system is cranked up.
The other problem is making all those things work within a 150W power envelope, the maximum the stock Power Mac 7300 power supply can put out. Let's add this all up. For the two 7200rpm SCSI drives we have somewhere between 20 and 25W draw each, so say 50W for the two of them if they're chugging away. Each PCI card can pull up to a maximum of 25W per spec; while the PC card was not running during these tests, it was probably not drawing nothing, and the Rage Orion was probably pulling close to its limits, so say 30-35W. The CD-ROM probably pulls around 5W when idle. If we assume a generous, low-power draw of about 2W per RAM stick, that's eight 128MB sticks to equal our gigabyte and 15-20W total. Finally, the CPU card is harder to compute, but Freescale's specs on the 1GHz 7455 estimate around 15 to 22W for the CPU alone, not including the very busy 2MB SRAM in the L3; add another 5 or so for that. That's up to 137W of power draw plus any other motherboard resources in play, and we're charitably assuming the PSU can continuously put out at max to maintain that. If there's any power sag, that could be enough to glitch the CPU. Running this close to the edge, the 3-6W power differential between the 800MHz and 1GHz cards is no longer a rounding error.
Now, if heat and/or power were the rate limiting characteristics, I could certainly yank the PC card or get rid of one of the hard drives, but that's really the trick, isn't it? The entire market for these kinds of processor upgrades consists of people like me who have a substantial investment in their old hardware, and that investment often consists of other kinds of power hungry upgrades. Compared to the 800MHz G4, the 1GHz card clearly pushes the envelope just enough extra to kick a system probably already at its limits over the edge. It's possible Sonnet had some inkling of this, and if so, that could be one reason why they never had a 1GHz G4 card in regular production for the beige Power Macs.
The 1GHz card is still a noticeable improvement particularly in CPU-bound tasks; the 2MB of L3 cache in particular helps to reduce the need to hit slower RAM on the system bus. For gaming, however, these cards have never been the optimal choice even though they can get many titles within reach of previously unsupported configurations; on PCI Power Macs, the 3D accelerator has to be accessed over the bus as well, and it's usually the 3D accelerator that limits overall framerate in higher-end titles. In addition, none of these CPU cards are particularly power-thrifty and it's pretty clear this uses more juice than any other such card. Overall, if you can get your hands on one and you have a beefier PSU like an 8500 (225W) or a 9600 (390W), this would be a great upgrade if you can find one at a nice price and certainly the biggest grunt you can get out of that class of system. If you have a smaller 150W system like my 7300 or the other Outrigger Power Macs, however, I'd look at your power budget first and see if this is just going to be a doorstop. Right now, unfortunately, mine is now just a spare in a box because of all the other upgrades. And that's a damn shame.
Sunday, October 22, 2017
I didn't get everything into this release that I was hoping to; CSS Grid and some additional DOM features are going to have to wait until FPR5. Still, there's quite a bit in FPR4, including more AltiVec conversions (this time the library function we're making over is strchr()), layout speed enhancements and hopefully a final fix for issue 72. That was a particularly interesting fix because it turns out there are actually two OS bugs in 10.5 that not only caused the issue but made it a little more involved to mitigate; read the issue if you're interested in the gory technical details, but basically we can overwhelm Leopard with our popup window events, and on top of that we can't even detect the misplaced clicks that result because the NSEvent's underlying CGEvent has incorrectly displaced coordinates. Since it does much the same work to patch around the OS as the fix for issue 248 (which also affects 10.4), even though the two issues have completely different root causes, I mostly combined the code for the two fixes to simplify the situation. It's not well tested, however, so I haven't uploaded it to the tree yet in case I have to back it out like I did the last time. Once we've determined it fixes the problem and it doesn't regress anything, I'll commit and push it.
The two major user-facing changes relate to fonts and HTML5 video. On the font side, we now have the same versions of the Brotli, OTS, WOFF2 and Harfbuzz libraries as Firefox 57, meaning we now support the latest iteration of WOFF2 webfonts as well and pick up all the rendering and performance improvements along the way. (This also upgrades Brotli decompression for the websites that support it, and I added some PowerPC-specific enhancements to the in-tree Brotli to use our native assembly byteswapping instructions for endian conversion. I should try to push this upstream when I get a round tuit.) This version of TenFourFox also fixes a longstanding issue where we couldn't display Graphite fonts for minority writing systems; they just wouldn't load due to a compiler issue where one of the key structs was computed with the wrong size, causing the browser to bail out. Before you upgrade, look at that link in FPR3 and note that because of this fallback the Burmese Padauk font has the wrong washwes and the Nastaʿlīq font at the bottom is missing all the ligatures and glyph substitutions shown in the comparison screenshot. In FPR4, this is all corrected and everything appears perfectly. As a formally trained linguist (BA, University of California) and a Christian, I find the work SIL International is doing with writing systems to be fascinating and hopefully this will make TenFourFox more useful to our users in foreign climes.
On the video side, the YouTube redesign has been an unmitigated dumpster fire for performance on older machines. Not only does it require a lot more system resources, it also ruined a lot of older addons to download videos that depended on the prior layout (on purpose?). It's not entirely misguided, though: while the lazy loader they appear to be using makes it very hard to deterministically reason about what loads when, after the first video finally grinds through subsequent ones do require much less work. (This is part of Google's attempt to get you to just "leave YouTube on" like your TV, I suspect.) I tried to retune the media decoder state machine to deal with these changes, and the baseline I hit on makes the browser pre-render a lot more frames (not just buffer, but actually pre-decode prior to playback) and pushes much smaller sets to the compositor instead of drowning it in frames that arrive too late and then have to be taken back out. With this change my Quad G5 is able to play most videos in Reduced mode nearly as well as before -- it does not completely erase the loss in performance, but it does improve.
This retuning also benefits HTML5 video playback in general, not just on YouTube. You can see the difference on other WebM and Theora videos, such as the ones on Mozilla's own pages, or Wikipedia (WebM VP8 example, Theora VP3 example) — although there is an initial delay while the video pre-decodes, playback should be a fair bit less choppy. Even full-screen playback is no longer "LOL" in theory, though in practice still probably more stuttery than people would like. The same general limitations apply as before; for example, my Quad G5 handles VP9 with MSE fine, but my 10.5 DLSD PowerBook G4 becomes a slideshow due to VP9's higher bitrate and strongly prefers VP8. As such, the default setting is still to disable MSE, and I discourage enabling it except on low-spec G4 systems near the 1.25GHz cutoff (to use the lower 144p and 240p resolutions) and high-end 2.5GHz/2.7GHz G5 systems (to use the 360p and 480p options if desired).
FPR4 also introduces an experimental (disabled by default) set of features specifically for YouTube but possibly beneficial elsewhere, namely decode delay and Mach monitoring. Decode delay adds a "wait state" between page load and video playback so that the rest of the page can (eventually) load and the video won't get stomped on by other page display tasks requiring the CPU. In a similar fashion, Mach monitoring looks at the kernel-provided Mach factor at various intervals and if not enough CPU resources are available, inserts a "wait state" right then and there to temporarily delay playback until the CPU load goes down.
The reason these aren't enabled is because 1) I'm not sure what the proper values should be, or what a reasonable default is, and 2) longer values can cause some issues on YouTube with very short clips (particularly the interstitial ads) because their code doesn't expect the browser to suddenly take a timeout during playback. When this happens and an ad won't play, you probably can get around it by reloading the page. But you can still play with these settings and see what works for you. Post your findings in the comments along with your system specs, speed, RAM, etc. NB: You may need to restart the browser for some of these settings to stick, as they are cached for performance.
To introduce a decode delay, create a new integer preference tenfourfox.media.decode_delay in about:config and set the number of seconds you want. If you say zero (0), or delete the preference, there is no decode delay (the default). Every video played will have the decode delay, but only once upon initial playback. The idea with YouTube is a nice long decode delay to let all the other crap lazy-load, and then your video can queue up in peace.
Mach monitoring is based on Mach factor: the lower the factor, the more load is on the system (the reverse of load average in concept); zero, then, means all cores are 100% occupied. The default is a critical Mach factor of 450 (tenfourfox.media.mach_factor_min), a delay of five (5) seconds (tenfourfox.media.mach_factor_delay), and zero (0) maximum tries (tenfourfox.media.mach_factor_max_tries) which essentially disables the feature. If the preferences do not exist (the default), these defaults are used, meaning monitoring is not in effect. At various times the state machine will sample the Mach factor for the entire computer. If the Mach factor is less than the critical point, such as when the browser is trying to load YouTube comments, a playback delay is introduced (note that a delay of zero may still cause the browser to buffer video without an explicit delay, so this is not the same thing as disabling the feature entirely). The browser will only do this up to the maximum number of tries per video to prevent playback thrashing. Systems that are at their limit decoding video or very busy otherwise will likely need the Mach factor set rather low or the browser will blow through all the tries back to back before it even plays a single frame. Likewise, more maximum tries rather than longer delays may reduce problems with short clips but can cause irritating stalls later on; you'll have to find the balance that works for you. A tool like iStat or MenuMeters can give you an idea about how much processing headroom your system has.
Finally, this version removes the "Get Add-ons" tab from the Add-ons Manager, as
threatened promised. Since the future is WebExtensions, and TenFourFox isn't compatible, there's no point in advertising them to our userbase. You can still download older legacy addons from AMO; I do still support them (remember: "best effort" only), and they will still install. I may resurrect this tab if someone(tm) develops a site to host these old addons.
For FPR5 my plan is to expand the use of our VMX-accelerated strchr() to more places, add CSS Grid, add some additional DOM features, and maybe start work on date and time pickers. The other major change I'd like to make is an overhaul of the session store system. The argument is that session stores run too frequently and chew up SSDs by writing the state of the browser to disk too often. As a fellow SSD user (a Samsung 512GB 850 PRO) I agree with this concern up to a point (which is why we have a 25-second interval instead of the default 15-second interval used in Firefox), but I think it's more profitable to reduce the size of the writes instead of making the interval excessively long: our systems aren't getting any younger and some of the instability we get reports on turned out to be undiagnosed system conflicts or even failing hardware. If we had a very long interval, it's possible these people might have lost data. The session store, like any backup method, only works if you use it!
Like everything else, you can tune this to your taste (though don't come crying to me if you muck it up). However, I think a reasonable first pass would be to do some code cleanup and then reduce the amount of history that gets serialized by reducing the number of back and forward documents to 5 (currently 10 and no limit respectively), and automatically purging closed windows and tabs after a certain timeframe, maybe a couple hours (see issue 444 for the relevant prefs). Making the interval 30 seconds instead of 25 shouldn't be a big loss either. But if you have other ideas, feel free to post them in the comments.
FPR4 final is scheduled for release November 14.
Tuesday, October 17, 2017
KRACK is particularly
wack problematic because there are multiple varieties of attack and virtually every system tested was vulnerable to at least one of them:
We can confidently assume that 10.4 and 10.5 (and 10.6, for that matter) are vulnerable in the same or similar ways that at least 10.9.5 are (I'll dive into this in a moment), but the situation is really bad for Linux. wpa_supplicant 2.6 and prior are vulnerable to all of the variants, including current PPC Linux users and devices running Android 6.0+. These will almost certainly be patched eventually, even considering the shrinking support for 32-bit PowerPC in Linux. OpenBSD is also vulnerable, but patches emerged prior to the embargo, and its close relative NetBSD will likely be repaired in a similar fashion. Microsoft has quietly issued a Patch Tuesday update that covers KRACK. There are reports that the issue is already patched in current betas of macOS and iOS, but it's not clear yet if these patches will be backported to Sierra or El Capitan.
10.5 and earlier exclusively use the private framework Apple80211.framework for WiFi connectivity. Although the public wireless networking framework CoreWLAN was introduced with 10.6, the later private framework CoreWifi is not present and a comparison of symbols shows subsequent upgrades to Apple80211's functionality in Snow Leopard, so it is very likely in use invisibly there as well. Although this framework still exists in 10.12, it does not appear to be used or linked by CoreWLAN, implying it was since internally deprecated. Apple never documented this framework or made it open source, but there have been attempts to reverse engineer it. However, the necessary changes likely mean inserting more sanity checks during the key handshake, which would require a bit more than just patching the library in place. I've done a little preliminary disassembly of it but I haven't found where this critical section exists yet. However, there is a tool in this framework which will be very helpful to determine your actual risk; read on.
WPA2 has three major encryption protocols, only two of which are supported by PPC Mac OS X, namely TKIP (a legacy encryption protocol from WEP intended as an interim compatibility measure), and AES-CCMP, a more secure protocol which is supported in 10.3.3+ and is sometimes just abbreviated "AES" (incorrectly) or "CCMP." TKIP was deprecated in 2012, but is still often used. The last form is GCMP, which no Power Mac supports in OS X and is part of 802.11ac Gigabit WiFi. This turns out to be a blessing, because KRACK can actually recover the key from GCMP-based connections and forge packets in both directions. This is even worse than TKIP's exposure, despite being the older and historically more insecure means of encryption.
The router situation is probably worst of all. Many older WiFi access points will never receive firmware updates, and even if they do, just patching the router is insufficient; every connecting client must also be patched. Some information circulated earlier that said only patching the router is adequate to mitigate the risk, but the discoverer of the flaw is clear both clients and the router must be updated to eliminate the risk completely.
Given it's not currently clear how we can patch OS X, then, what can you do with your Power Mac? Well, obviously, if you have the ability to hardwire your system, that would be preferable. All of my desktop Power Macs connect to a secured internal network over wired Ethernet that cannot directly route to the Internet.
If your connection to the router you control is still using TKIP (or any form of WPA or WEP), you should make sure it is WPA2 AES-CCMP. Log into your router and look at your security settings and change them if necessary; while you're at it, also see if your manufacturer has a firmware update for your router. While AES-CCMP is still vulnerable to some of these attacks and traffic secured by it can be decrypted, the actual key cannot be forged, so an attacker cannot actually join your network and attack it in place; they would have to clone your WiFi router's MAC address to a new access point with the same name on a different channel that's in range. This might be a risk in a hotel or apartment building but probably not in your house unless your neighbour is naughty and needs a baseball bat education. (If you have an Apple AirPort base station, this old TidBITS article can help you with the steps.) You can confirm your setup by opening a Terminal and entering these commands ([...] means not important for this usage):
% cd /System/Library/PrivateFrameworks/Apple80211.framework/Resources/ % ./airport -s 1 Infrastructure networks found: SSID Security Ch [...] BSSID yournetwork WPA2 PSK 6 [...] 20:4e:7f:ff:fe:fd [...](AES2),[...] % ./airport -I [...] SSID: yournetwork Security: WPA2 PSK cipher: AES2
These steps use a command line utility called airport that comes with Apple80211.framework; you can see other commands with ./airport --help. The first airport command scans for access points. In place of the SSID yournetwork, you should see the name you assigned your router in its settings; its channel may or may not be six, its BSSID will almost certainly differ from this example, and you may see any number of other access points your PowerBook is in range of. What you should not see under ordinary circumstances are multiple copies of your network SSID with the same BSSID on multiple channels. If you do, something might be wrong!
The second airport command tells you what access point you are currently associated with. Verify the SSID matches the one you expect and that the security is WPA2 and AES2 (notice this appeared in the first command, too). Periodically recheck these commands as you get suspicious-looking new neighbours or black vans and helicopters show up on your block. Consider replacing your router if there is no update; this won't help your Power Mac, but it would potentially help other connecting devices that were themselves updated.
If you are connecting to a router you can't control, like a public access point in your coffee shop or hotel, you should treat any WiFi connection you make to it as if it were open and unencrypted and that an attacker can see and forge any traffic you generate. Though the commands above can give you an idea of your instantaneous risk, even if AES-CCMP is in use a wily attacker may choose to deploy their malicious access point intermittently or when you're not checking, so your best defense is to encrypt what you send and receive. Only use https:// URLs and prefer sites that use HTTP Strict Transport Security and HTTP Public Key Pinning, both of which TenFourFox supports, so that an initial HTTP-to-HTTPS redirect is less likely to be intercepted and stripped and it is much harder for an attacker to impersonate a HPKP-secured site. There are still some sophisticated ways to get around even these added precautions, however, so if you need to do something highly secure like banking or taxes I'd strongly advise going home and plugging into your router's Ethernet ports directly. Even a VPN might not be enough.
Meanwhile, I guess I'll be rewriting that Power Mac security rollup post again. Assuming the current state of AES-CCMP holds, though, there may be a way to design a tool to programmatically/automatically detect a forged connection even if the underlying vulnerability cannot be corrected. I have a few ideas about that. More later.
Thursday, October 12, 2017
OverbiteWX is only for Firefox 56+. TenFourFox and Firefox 52ESR can still use OverbiteFF, which is a superior add-on in every respect for obvious reasons.
New OverbiteWX users, please read the directions thoroughly! And Mozilla, how about a spec for bug 1247628 so we can finally get TCP sockets working in WebExtensions? We can't even scratch our itch because you won't tell us what type of scratching you'll accept!