Driver hack lets you run Linux after Windows BSODs, no reboot required | Hacker News Reader

Driver hack lets you run Linux after Windows BSODs, no reboot required

tomshardware.com

127 pointsdragonbonheur55 comments

Now we need to have a linux driver that lets run Windows after kernel panic and we can switch between them without reboot, just like we wanted 20 years ago...

I had that working very briefly for a short period of time circa 2010.

Linux -> kexec grub -> NTLDR

Windows -> Winkexec[1] grub -> linux kernel

It was extremely fiddly, and the majority of hardware I threw it at really didn't like complying with what I was trying to do, in spite of the fact that it ought to work, at least on paper.

1: https://github.com/stump/winkexec

Been using Linux as my daily driver for 5 years and have never seen a Kernel panic, so there's probably no drive to do it :P

I have been using Linux since 1999. I have seen lots of kernel panics. But recently much less, unfortunately replaced by more problems in platform and userspace.

I know Linux works more reliably for some people and less reliably for some others. It probably has much to do what you do with it. What kind of hardware you are running it on, do you just install it and use it as it is or you are the kind of person like me who likes to change everything to his liking.

I also tend to not like to reinstall my machines. For about 15 years my daily driver was a single Debian unstable installation which was continuously updated until I faced too much problems and had to completely replace it. I would have fixed it all but I just did not have the time and I needed it working.

My experience is that Linux is rock solid as long as you're not running it on super duper expensive hardware and doing crazy-big things on it.

Randomly in my career so far, notable kernel panic causes were:

- when a spark job finishes and deallocates close to a TB of memory, kernel panic. jobs using below 750GB were typically not seeing this happen, so it was something in there. this just kind of stopped happening after we updated the kernel and spark in a semi-unrelated push, so never really got a root cause here.

- bad hardware

- a spark job that was doing simply insane amounts of shuffle output (which goes to disk) was hitting kernel panics which ended up being related to a kernel bug that only impacted ridiculously high-disk-io-using applications, with some additional spin that made me think "ah so this is basically only affecting spark jobs"

- bad hardware

Did I mention bad hardware? I've spent way too much time hunting down "bugs" that ended up just being a bad mobo and linux was kind enough to inform you of it. But "this is the only program that causes the kernel panics!" and yet when we move it to a temp server for a few days the program mysteriously stops crashing. Another reason I do like "the cloud" - I can just cycle out an ec2 box I suspect is bad instead of fighting with the IT guy about whether the 2 year old expensive server is already busted or not.

Bad hardware is probably the main reason for Windows Bluescreens as well.

Corrupt registry hive, corrupt or missing OS file, or bad drivers are mostly the cause of Windows BSOD. Actually bad hardware is more rare. My experience during my IT consulting days.

I've seen too many systems which started to work fine after replacing a PSU.

As someone who worked L1 and L2 - %he major reason for BSODs is the faulty hardware.

My favourite story on this topic is when after a ~4 human hours of diag by L1 tech, I came to the client site, confirmed the BSOD, opened the case, straithened the SATA cable and the OS installed sucessfully.

EDIT: another one is the cheap PSU cut thr power too fast on the shutdoen, so the HDD never written 'good shutdoen' to the disk, triggering the scandisk on the startup. Fixed with a good PSU, BTW.

I thought the same. Till I bought a surface (first version)... BOY that thing was unstable. Was the last chance I gave to Microsoft. After that switched to Mac. Not coming back anytime soon.

I've worked and developed on Linux, for Linux, for 10+ years, I've seen my fair share of panics, especially using the bleeding edge releases. Most (not all!) of them were my own making though. :>

Yeah I've been using Linux exclusively for maybe 9 years and the only time I've ever seen a kernel panic was when I was messing around with Gentoo on a cheap machine I have just for that sort of screwing around, and I accidentally told it to literally overwrite the kernel. It got pretty far giving itself a lobotomy before it died, too.

Meanwhile, the last time I used Windows (in order to install Linux on a new laptop, lol), it blue screened four times just trying to mount a simple USB flash drive.

> it blue screened four times just trying to mount a simple USB flash drive

With Linux these problems can typically be solved by googling it on your phone then appending a text file with some nonsense string you found on a 10 year old forum post. I'm still holding my breath for Windows to catch up with that level of UX.

The basic difference and reason for me to have stuck with Linux for so long is that when there is a problem with Linux it is all about how much I can persevere trying to fix it. All code is there and I have the skills to fix it.

With Windows, if it doesn't work, there is a chance there simply is nothing you can do about it. There is no source code. The support people are completely useless. If you can't fiddle with it until it somehow works or find a person on the Internet that fiddled with it until it worked and they were gracious to share the solution, your only option tends to be to reinstall the entire thing and hope for the best.

So true lmao. One of the things that I noticed after moving from Mac OS to Linux is that like, yes, sometimes things don't work perfectly on Linux, and sometimes the Linux user experience is more awkward or arcane, but you can always, always figure out how to fix it or get it to work the way you want with like an hour of Googling tops and a little simple modification of configuration files or running a few terminal commands. There's no point at which something is so far gone that you can't just fix it yourself if you want to, so the choice is always there, it's just a matter of what's worth the effort for you. Meanwhile, with Mac OS, the last time I used it for a couple years I couldn't get it to consistently connect to external monitors correctly, and it was just an endless pain in the ass and there was nothing I could do about it.

That means you're not doing anything interesting with it :P

I've been using GNU/Linux exclusively since 2012 and while I've seen fewer kernel panics than blue screens, I have seen some. Usually due to the Intel graphics driver (of all things). I don't recall ever having one caused by AMDGPU, but that may just be a lucky coincidence. But every OS has problems, my favourite one was OSX Yosemite hard rebooting whenever I ran a Xubuntu VM on VirtualBox.

its called kvm and is just 2 years shy of turning 20

Nah, it's call loadlin and so old that no one seems to remember its birth.

I remember loadlin. Netware used to boot that way, too - load DOS, then replace everything.

I vaguely remember you could exit NetWare and it would drop you back at the DOS prompt. Do I remember this correctly?

It's been a while but I don't remember that, under 3.x at least. However, according to Wikipedia:

> NetWare 286 2.x normally requires a dedicated PC to act as the server, where the server uses DOS only as a to execute the operating system file NET$OS.EXE. All memory is allocated to NetWare; no DOS ran on the server. However, a "non-dedicated" version was also available for price-conscious customers. In this, DOS 3.3 or higher remains in memory, and the processor time-slices between the DOS and NetWare programs, allowing the server computer to be used simultaneously as a network file server and as a user workstation. Because all (RAM above 1 MiB) is allocated to NetWare, DOS is limited to only 640 KiB; managers that used the MMU of 80386 and higher processors, such as EMM386, do not work; 8086-style expanded memory on dedicated plug-in cards is possible however. Time slicing is accomplished using the keyboard interrupt, which requires strict compliance with the IBM PC design model, otherwise performance is affected.

So, maybe that's what you're thinking of? Also, time slicing via keyboard interrupt is something.

You are an old head. Thankfully, your memory is better than mine.

Naturally using umsdos.

I think this already existed. https://youtu.be/q5M0TwnkWUM?si=X6WdLHNfXNZ-FSrD

Somewhat related, there was a Laptop that could quick switch between Windows and Linux by abusing ACPI Sleep Support and rewiring the return vectors for the wake-up: https://www.youtube.com/watch?v=q5M0TwnkWUM (technical explanation starts at around 48:10)

It's all kinds of "I don't approve of the idea, but I tip my hat to the engineer that came up with it for sheer ingenuity."

tl;dw: It reserves half the RAM only to keep a sleeping windows/linux there.

> While this driver is more or less just a funny joke about Windows and Linux, it does bring up the possibility of doing more with the same bug check callback feature. It's not clear what you can and can't do, but if it's possible to run an emulator after crashing, then surely it's possible to do other things, too. That's all assuming Microsoft doesn't revisit this feature of Windows and concludes it's just a bit too easy to exploit.

Anyone else getting ChatGPT vibes from this conclusion?

No, but I can see why you’re seeing it. The “It’s not clear”, “While this”, and similar are common starts in GPT3/4 replies. There’s enough stuff in the later half of the sentences that don’t feel GPT-y to me.

Where do you think ChatGPT learnt it from? I can see people having to get ChatGPT to write stuff for them to make sure what they wrote didn't accidentally look like what ChatGPT would have written. Then the weird feedback loops start...

They might've started with GPT and edited.

Not enough "it's important to consider"

Or "Ultimately, ..."

What a strange conclusion for the author to reach.

What they're doing requires you to have code execution in the kernel. You're not just over the walls at that point, you've beheaded the king.

> it does bring up the possibility of doing more with the same bug check callback feature.

Personally I would just want a power off that does not make me guess if will cause the raid volumes to need to rebuild.

But since we are in the realm of possibilities and wishlists, Magic SysRq commands for the windows kernel would rank fairly high. [0]

[0] https://www.kernel.org/doc/html/latest/admin-guide/sysrq.htm...

Not really an exploit if you have to have Test Mode turned on. https://learn.microsoft.com/en-us/windows-hardware/drivers/i...

Nobody says it’s an exploit

The hack is not how the driver is loaded, the hack is how the driver abuses the bug check callback pointer.

Once upon a time, there was a more serious effort at running Linux in a Windows device driver. It was called coLinux:

http://www.colinux.org/

You could run the Cygwin X server on the Windows side, and run X clients on the Linux side. It worked, and it was fast.

I think it required a lot of work whenever a new Linux kernel came out to put the appropriate "yield" code in, so probably maintenance was abandoned?

The last update on the homepage is a decade old. I wonder if it still works? It's all been made obsolete though by WSL, I reckon.

It was basically the same idea as WSL1, i.e. running the Linux kernel (or equivalent) in Windows userspace.

It actually worked decently when I tried it back then.

WSL1 implemented Linux syscalls inside the NT kernel (not in userspace).

Drat, I was hoping for a chainload of the Linux kernel. A sort of "here's a quarter, kid, go get yourself a real operating system" option.

"It would seem that either it wasn't possible to run a full Linux distro, or it was simply too much of a hassle to get it to work"

If it could get that far, getting an older DSL distro or similar is probably not that far behind, honestly. Using a BSoD as an environment bootstrap mechanism is hilariously jank, but I've seen worse in my hacking days.

This wins the award for most elaborate boot loader.

How do you emulate linux with 400 loc?

You don't emulate linux, you emulate a rv32ima system that happens to boot a linux firmware.

Devs website: https://nsg650.github.io

"I am a random 16 year old who likes messing with computers."

Things like this give me hope for the future!

This reminds me of using crashes in PSP games to run homebrew apps.

I had a PSP Go, The trick was to crash a certain game by loading a compromised save game file. Wonderful times.

Would it be possible to save open files with this, so that you don't lose your work after a BSOD?

Well, that would depend on whether the code leading up to the BSOD scrambled the memory of how your disks are laid out or not.

It would be ironic if trying to save the files you were currently working on overwrote your partition table or filesystem superblock(s) so you were no longer able to access any of your files any more.

Good point! It would have to save the files with another filename... or propose a UI to tell which programs were open, so that you can take note of what you were doing

With 400 lines, it's probably more of a shell / terminal emulator than a Linux emulator.

It does emulate risc-v that runs Linux, so why not call it a Linux emulator?

Though https://github.com/cnlohr/mini-rv32ima is indeed impressively small. Here's the dispatch switch-case: https://github.com/cnlohr/mini-rv32ima/blob/eeeaaa0609558c84...

Because it doesn't emulate linux? It emulates risc-v.

A game boy emulator doesn't emulate what ever game you play. It emulates the hardware.

Now this is the kind of crazy stuff I come to HN for.

Reply on news.ycombinator.com