Had a friend do that... He bought 3 acres, spent a couple years building a cabin in his free time. Then one day just quit and went off to the woods.
Still visit him and he seems pretty happy with it. He doesn't need much income and makes enough money off odd jobs he seems to be doing pretty well.
2) http://americanbeejournal.com/insights-honey-pollination-pac...
This actually made the system boot but there are some leftovers being installed on first boot that I've been unable to disable that also causes the system to be unable to boot.
So now, the machine is running but as soon as it is restarted we have to re-image the disk, go through the process of manually removing patches, and then pray that we don't have a power shortage as we'd have to do everything yet again on next boot.
I'm not convinced that this patch will solve the issue either, because if this updates requires a reboot the fix won't be installed if we can't boot. I might try to install this update from the recovery console see if that works.
Quite frustrating.
On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; Therefore, if you want to replace a DLL (or any other file) that is in use, you have to kill any program that uses it before you can do that; And if it's a fundamental library everything uses (USER32.DLL COMCTL.DLL etc), the only effectively reliable way to do that is reboot.
On Unix, once you have a handle=descriptor of the file, the name is irrelevant; You can delete or rename the file, The descriptor still refers to the file that was opened. Thus, you can just replace any system file; Existing programs will keep using the old one until they close/restart, new programs will get the new file.
What this means is, that even though you don't NEED to restart anything for most upgrades in Unix/Linux, you're still running the old version until you restart the program that uses it. Most upgrade procedures will restart relevant daemons or user programs, or notify that you should, (e.g. Debian and Ubuntu do).
You always need a reboot to upgrade a kernel (kernel-splice and friends not withstanding), but otherwise it is enough in Unixes to restart the affected programs.
Can't speak for everyone else, but Windows fully supports shared file-access which prevents the kind of file-locks which causes reboot requirements.
The problem is that the default file-share permissions in the common Windows APIs (unless you want to get verbose in your code) is that the opening process demands exclusive access and locking to the underlying file for the lifetime of that file-handle.
So unless the programmer takes the time to research that 1. these file-share permissions exists, 2. which permissions are appropriate for the use-cases they have in their code, and 3. how to apply these more lenient permissions in their code...
Unless all that, you get Windows programs which creates exclusive file-locks, which again causes reboot-requirements upon upgrades. Not surprising really.
In Linux/UNIX, the default seems to be the other way around: Full-sharing, unless locked down, and people seem prepared to write defensive code to lock-down only upon need, or have code prepare for worst-case scenarios.
There is a registry key which allows an update to schedule a set of rename operations on boot to drop in replacement file(s). https://blogs.technet.microsoft.com/brad_rutkowski/2007/06/2...
We are getting there on Linux too - with atomic or image based updates of the underlying system. On servers you will (or already) have A/B partitions (or ostrees), on mobiles and IoT too, some desktops (looking at Fedora) also prefer reboot-update-reboot cycle, to prevent things like killing X while doing your update and leaving your machine in inconsistent state.
macOS also does system updates with reboot, for the same reasons.
At least on *nix, even when you need a reboot, once is enough.
Historically (Windows 95 and earlier) reboots were required to reload DLLs and so on but that’s not really true anymore. Still a lot of installers and docs say to reboot when it’s not really necessary as a holdover from then
I'm running with Windows Update service disabled till this is fixed for good !
[1] https://answers.microsoft.com/en-us/windows/forum/windows_10...
I actually like Win 10, but it's shit like this that keeps me from becoming a true convert. Oh, for $X00 I can get enterprise update, but IMO that's just Win 10 home being used as ransomware. /rant
That patch disables the use by the kernel of the new IBPB/IBRS features provided by the updated microcode, when it's of a "known bad" revision. Since Linux prefers the "retpoline" mitigation instead of IBRS, and AFAIK so far the upstream kernel (and most of the backports to stable kernels) doesn't use IBPB yet, that might explain why Linux seems to have been less affected by the microcode update instabilities than Windows.
Also interesting: that patch has a link to an official Intel list of broken microcode versions.
Linus probably won't pull it until it's truly known to be stable, because of his attitude towards having decent quality code and not causing needless system instability.
Without Linus... who knows what would have happened by now.
But yeah, upstream Linux kernel development is taking it slow. As far as I can see, variant 3 mitigations (PTI) are already in, variant 2 mitigations are partially in (retpoline) and partially not (the microcode dependent ones), and variant 1 mitigations are still under discussion.
There is an interesting paradox in our industry. If you pay enough attention (read: money) to security, you will be late to the market, your costs will be high and you lose profit. If you don't pay enough attention, you take the market, get your profits, but your product (be it hardware or software) and reputation will be screwed later. And worst of all: there's never enough attention to security.
So by simple logic, an optimal strategy is to forge your product quickly, take your profits within a [relatively] short period and vanish from the market. I guess we'll see this strategy executed from IoT vendors when market start to punish them for their bad sec.
For Intel, that "long period" just happened to be REALLY long.
All markets work like this. People bitch about the quality of products, but still buy the cheap stuff.
Interestingly, I think AMD has a lot of motive to create such a superflu, or at least encourage it's creation.
Intel may be too big for an abrupt failure, but they can absolutely fail in a decade-long slide into obscurity.
What's next? Repeat? Sounds like this could turn into a maintainance nightmare quickly. Also because I've introduced things like that myself in the past, and that was for normal applications and not a kernel or OS. Somewhere, someday, there's usually this one exception for which none of your rules hold true and the thing blows up in your face. Anyway, I'd love to see the actual code for this. Not a chance probably?
https://www.cnbc.com/2018/01/26/intc-intel-stock-jumps-to-hi...
I think it's our responsibility as technology literate folks and decision makers to explicitly highlight their failures so that mistakes and poor handling like this are not normalized.
I work in a bank and they are terrified of the possibility of user processes reading privileged memory. Not necessarily out of actual fear but out of the insane amount of paperwork this will require to satisfy the auditors that it is still safe.
Anecdotally, but you asked for "someone" and here is someone :)
Intel's actions seem to shout that they have cared far more about releasing Kaby/Skylake X and Coffee Lake in short order, as a response to Ryzen/ThreadRipper, than actually really digging into fixing their major security flaws. Their actions speak of them preferring to keep their market and mindshare over actually fixing any security issues.
Intel is still so deeply entrenched that they likely believe that they can get away with their lazy approach. They make millions upon millions, if not billions of dollars ~ why should they give a shit, when their monopoly and half-hearted attempt at a solution will get them by? Intel is being strangled by their shitty management, seemingly...
Intel certainly isn't making any friends these days...
https://www.bleepingcomputer.com/news/microsoft/microsoft-is...
for server, Epyic is now finally available to purchase for desktop workstation Threadripper for desktop RyZen
for mobile... not many newer cpus out yet.. need to wait :(
* How promptly did they address the issue via official channels, i.e. did they leave users in the dark as they appealed to vendors in their forums (hint: most of them seem to have gone down this route) or did they share updates directly on their official sites, social media accounts, etc.
* Did they provide some estimates as to when users could expect patches?
* How much of their product catalogue were they willing to cover with security updates? Since this is a unique security issue with high impact I would have expected them to cover motherboards at least 4-5 years old.
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
https://www.wired.com/2002/01/bill-gates-trustworthy-computi...
I still haven't had the time to debug it, but I wonder how many people are out there with their OS silently refusing to update.
After probably 9 months of this, and with Windows doing ever more intrusive pop overs whenever I launched it for updates that don't take, I wiped all boot sectors everywhere and installed from scratch. That seemed to work, but it was incredibly frustrating that the boot process was so buggy as was error reporting. I've never encountered a situation like it in the past 15 years of heavy Linux use. Problems there are usually solvable with a couple web searches, even for extremely obscure kernel bugs with obscure packages. Windows refused to tell me anything as did the web.
Maybe I just got lucky with the right combination of hardware.
Remember to use backups!
https://www.techrepublic.com/article/03175c88-5c9b-4ccd-ac62...
I sure hope Intel will face a class action suit over this botched update. Many professionals have wasted countless hours dealing with this junk.
https://support.microsoft.com/en-us/help/4078130/update-to-d...
https://support.microsoft.com/en-us/help/4072699/january-3-2...
Customers without Antivirus
In cases where customers can’t install or run antivirus software, Microsoft recommends manually setting the registry key as described below in order to receive the January 2018 security updates.
I thought stopping updates was only for the case of unpatched AVs that did not set the registry key...
Why he gets a pass for being the 'nice guy' and DeRaadt gets the bad rep is still a mystery to me
- Theo de Raadt
A part of me feels this stories like this are going to keep getting worse until Spectre is finally used in the wild.
The day this blew up we rented our first physical server for the express purpose of running secure critical workloads in unpatched environments. Yes, I know that there is nothing secure, but not everything we do is running a chunk of logic uploaded by an attacker, so we will take our chances.
> HP, Dell, Lenovo, VMware, Red Hat and others had paused the patches and now Microsoft has done the same.
