Tails

#2 Updated by anonym 2017-01-13 20:10:59

This one was added to the agenda for the January 2017 contributor’s meeting, but do you really expect that any one except you and me that will have opinions, intrigeri?

Any way, given Bug #12139 I’m deadly tired of supporting VirtualBox, and would not mind at all to drop it and sneak this into Tails 2.10 (final).

My only worry with removing DKMS support is that we will want it for something else in the future. What is your take on this aspect of it?

#4 Updated by intrigeri 2017-01-16 11:07:40

> This one was added to the agenda for the January 2017 contributor’s meeting,

Do you know if it was discussed there?

> but do you really expect that any one except you and me that will have opinions, intrigeri?

Yes, it’s a matter of balancing UX vs. maintenance costs. You and I can bring input about the maintenance costs, but I’d like to hear other people’s thoughts and knowledge about the UX part, including things we might want dkms for in the future.

> Any way, given Bug #12139 I’m deadly tired of supporting VirtualBox, and would not mind at all to drop it and sneak this into Tails 2.10 (final).

Understood. I personally wouldn’t mind either.

> My only worry with removing DKMS support is that we will want it for something else in the future. What is your take on this aspect of it?

Indeed, the ticket description mentions Bug #7505.

I’m personally ready to drop dkms support (be it stuff that’s been vaguely working for years, but super painful to support; or new stuff like Bug #7505 that nobody but me has ever shown any interest for) in favour of lowering our maintenance costs, and increasing security thanks to grsec.

#5 Updated by anonym 2017-01-16 11:55:32

intrigeri wrote:
> > This one was added to the agenda for the January 2017 contributor’s meeting,
>
> Do you know if it was discussed there?

It was not.

> > but do you really expect that any one except you and me that will have opinions, intrigeri?
>
> Yes, it’s a matter of balancing UX vs. maintenance costs. You and I can bring input about the maintenance costs, but I’d like to hear other people’s thoughts and knowledge about the UX part, including things we might want dkms for in the future.

“UX” as in “without DKMS we won’t be able to build some kernel modules that improve UX” (e.g. the virtualbox guest modules, and Bug #7505)? Or am I missing something else?

> > Any way, given Bug #12139 I’m deadly tired of supporting VirtualBox, and would not mind at all to drop it and sneak this into Tails 2.10 (final).
>
> Understood. I personally wouldn’t mind either.

Let’s consider it as an option, then: at the moment we can consider to “just” drop the VirtualBox guest modules because they are a major PITA to maintain and not worth the small benefits they add these days (clipboard sharing, filesystem shares, host-to-guest time syncing). I say “just” because this is the only current use of DKMS we have, so in effect this drops DKMS, even though we haven’t decided (collectively) on dropping it yet. That can be done later.

The question is then, is it enough that you and me agree that we drop VirtualBox support in Tails 2.10? Or do we need to involve some UX people?

> > My only worry with removing DKMS support is that we will want it for something else in the future. What is your take on this aspect of it?
>
> Indeed, the ticket description mentions Bug #7505.

But not what the future beyond that might bring! :)

Would some sort of historic perspective of what has been depending on DKMS throughout the years be helpful when trying to predict what we will miss out on? Or is that too hard?

Any way, this is not really a decision that we will have to stick with forever — DKMS support for the GrSec kernel may be fixed at some point.

> I’m personally ready to drop dkms support (be it stuff that’s been vaguely working for years, but super painful to support; or new stuff like Bug #7505 that nobody but me has ever shown any interest for) in favour of lowering our maintenance costs, and increasing security thanks to grsec.

Given the current situation (and ignoring the future beyond Bug #7505), I agree.

#6 Updated by intrigeri 2017-01-16 13:03:46

>> > but do you really expect that any one except you and me that will have opinions, intrigeri?
>>
>> Yes, it’s a matter of balancing UX vs. maintenance costs. You and I can bring input about the maintenance costs, but I’d like to hear other people’s thoughts and knowledge about the UX part, including things we might want dkms for in the future.

> “UX” as in “without DKMS we won’t be able to build some kernel modules that improve UX” (e.g. the virtualbox guest modules, and Bug #7505)? Or am I missing something else?

Yes, “UX” as in “if we break things for purely technical reasons, how bad is it for actual users of these things?”.

> Let’s consider it as an option, then: at the moment we can consider to “just” drop the VirtualBox guest modules because they are a major PITA to maintain and not worth the small benefits they add these days (clipboard sharing, filesystem shares, host-to-guest time syncing). I say “just” because this is the only current use of DKMS we have, so in effect this drops DKMS, even though we haven’t decided (collectively) on dropping it yet. That can be done later.

> The question is then, is it enough that you and me agree that we drop VirtualBox support in Tails 2.10? Or do we need to involve some UX people?

Just to be clear, I didn’t mean we need to involve UX people. I wrote “other people” and meant just that :) For some things we need UX experts, for some other things (like this one IMO) we just need input coming from more diverse people than you and I.

Now, to answer your question: yes, I would like to

1. know what’s the actual breakage (the feedback you provided, that I quoted in the ticket description, contain “IIRC” and “I guess”, which is a bit too vague for me to draw conclusions, so I’d like to now what’s the situation with a bit more certainty);
2. hear what’s what a few other people think of breaking those things. It should be easy enough to ask them via tails-dev@ or XMPP.

> Would some sort of historic perspective of what has been depending on DKMS throughout the years be helpful when trying to predict what we will miss out on? Or is that too hard?

It might be that some of our team-mates will want this info before we can make a decision on the general DKMS topic.

> Any way, this is not really a decision that we will have to stick with forever — DKMS support for the GrSec kernel may be fixed at some point.

Sure. Let’s not expect it’ll be fixed (and maintained!) if we don’t fix it ourselves though. At least the src:linux-grsec maintainer has no plans to work on it himself.

#7 Updated by segfault 2017-03-08 14:11:45

We talked about this during the contributors meeting. We acknowledge that losing clipboard sharing is an important UX hit for VirtualBox user. Whether that’s a good enough reason to 1. spend tons of time maintaining the DKMS thing; 2. making grsec much harder to get in Tails; was not something we could make up our mind firmly about. But we were leaning towards ‘no’ as an answer.

#8 Updated by cypherpunks 2017-03-09 08:23:57

segfault wrote:
> We talked about this during the contributors meeting. We acknowledge that losing clipboard sharing is an important UX hit for VirtualBox user. Whether that’s a good enough reason to 1. spend tons of time maintaining the DKMS thing; 2. making grsec much harder to get in Tails; was not something we could make up our mind firmly about. But we were leaning towards ‘no’ as an answer.

Please note that not only do the VirtualBox Guest Additions pose a greatly increased attack surface area, but the lack of grsecurity is even worse. Putting up barriers to its adoption means allowing an incredible number of vulnerabilities which are being actively traded and sold by blackhats and by government contractors. Raytheon SI alone has hundreds of people who work full time, several dozen of which work on the Linux kernel alone. You would shit bricks if you saw their internal wiki. It really makes the CIA leak look amateur. And there are hundreds of such contractors. Leidos. Vencore. L3. BAE. Exodus…

They will risk vanilla Linux exploits on Tails users, even en masse, and AppArmor does not mitigate the majority of kernel vulnerabilities. They will not risk a grsecurity exploit on a Tails user, in part even because any grsecurity exploit they have will, in all likelihood, be highly unreliable.

A friend of mine, who is an exploit developer, does not develop exploits for Debian kernels because it activates everything under the sun in the kernel configuration, which opens gaping holes, making it not worth it and too easy to exploit. All the things that can exploit it typically do not affect other distros which don’t activate all these dangerous kernel configuration settings (such as CONFIG_VM86, CONFIG_USELIB, CONFIG_MODIFY_LDT, etc).

Please do not let this severely impact the security of Tails users.

Why can’t Tails just have a fallback, non-grsecurity kernel which has DKMS for these poor souls, anyway?

#9 Updated by intrigeri 2017-03-09 08:58:50

> Why can’t Tails just have a fallback, non-grsecurity kernel which has DKMS for these poor souls, anyway?

If there’s a way for syslinux to auto-detect when that other kernel must be used (like we do for 32-bit vs. 64-bit, git grep ifcpu to see how): fine. If not, then adding one more choice to make at boot time is likely to confuse not only those who are supposed to benefit from it (VirtualBox users), but worse: everyone else.

#10 Updated by cypherpunks 2017-03-09 09:08:29

intrigeri wrote:
> > Why can’t Tails just have a fallback, non-grsecurity kernel which has DKMS for these poor souls, anyway?
>
> If there’s a way for syslinux to auto-detect when that other kernel must be used (like we do for 32-bit vs. 64-bit, git grep ifcpu to see how): fine. If not, then adding one more choice to make at boot time is likely to confuse not only those who are supposed to benefit from it (VirtualBox users), but worse: everyone else.

Yes, I syslinux can, at the least, detect when virtualization is being used (by detecting virtualization flags). In fact, ifcpu itself is the tool which does that. See: http://www.syslinux.org/wiki/index.php?title=Ifcpu.c32

However it would be ideal to detect VirtualBox specifically. I would not be surprised if that could be done in some way with syslinux. Even if it could not though, having a few VirtualBox users be able to have an automatic clipboard is not worth having everyone highly vulnerable to people who are only 5 years into exploit dev and the underground.

#11 Updated by intrigeri 2017-03-09 09:14:47

> Yes, I syslinux can, at the least, detect when virtualization is being used (by detecting virtualization flags). In fact, ifcpu itself is the tool which does that. See: http://www.syslinux.org/wiki/index.php?title=Ifcpu.c32

This is a good start but what we would really need to go this way is:

> However it would be ideal to detect VirtualBox specifically. I would not be surprised if that could be done in some way with syslinux.

FTR I’m not going to investigate this myself.

#12 Updated by cypherpunks 2017-03-09 09:31:06

intrigeri wrote:
> > Yes, I syslinux can, at the least, detect when virtualization is being used (by detecting virtualization flags). In fact, ifcpu itself is the tool which does that. See: http://www.syslinux.org/wiki/index.php?title=Ifcpu.c32
>
> This is a good start but what we would really need to go this way is:
>
> > However it would be ideal to detect VirtualBox specifically. I would not be surprised if that could be done in some way with syslinux.
>
> FTR I’m not going to investigate this myself.

No problem.

http://www.syslinux.org/wiki/index.php?title=Lua.c32#Example:_Act_on_system.product_name_DMI_information

This should return 0 if the system is run under VirtualBox, and 1 otherwise. It’s called with lua.c32 scriptname.lua.

if (dmi.supported()) then
    dmitable = dmi.gettable()
    if (string.match(dmitable["system.product_name"], "Virtualbox")) then
        return 0
    else
        return 1
    end
end

#13 Updated by cypherpunks 2017-03-09 09:40:29

I just hacked that together from looking at the example Lua script usage on the syslinux wiki page without testing it btw, so it may even fail spectacularly. But as long as the Product Name in the DMI table is “Virtualbox”, then that, or something similar, should work. One way to test if that’s the Product Name is to report the output of dmidecode on such a system.

Does that look good?

#14 Updated by intrigeri 2017-03-09 10:09:07

> This should return 0 if the system is run under VirtualBox, and 1 otherwise.

Amazing, thanks a lot!

tl;dr: we could provide one kernel for VirtualBox users (no grsec, VirtualBox dkms modules) and another one for everybody else (grsec, no VirtualBox dkms modules), which looks like the best of both worlds, i.e. we can protect most users with grsec without harming usability for those poor souls who have to use VirtualBox. The only downside I can think of (aside of code complexity) is a bigger ISO and bigger upgrades. We should measure this before deciding whether we should go this way.

#15 Updated by cypherpunks 2017-03-09 10:43:07

intrigeri wrote:
> > This should return 0 if the system is run under VirtualBox, and 1 otherwise.
>
> Amazing, thanks a lot!
>
> tl;dr: we could provide one kernel for VirtualBox users (no grsec, VirtualBox dkms modules) and another one for everybody else (grsec, no VirtualBox dkms modules), which looks like the best of both worlds, i.e. we can protect most users with grsec without harming usability for those poor souls who have to use VirtualBox. The only downside I can think of (aside of code complexity) is a bigger ISO and bigger upgrades. We should measure this before deciding whether we should go this way.

It’s a win-win because most likely we’d end up providing a non-grsec kernel anyway for the troubleshooting boot option. Every once in a while, you’ll find someone who’s hardware pulls in drivers which are exercised in some way that triggers an unintentional grsecurity violation. While spender and pipacs take steps to prevent this (all their tests are on allyesconfig), but no one can find every bug. So using the troubleshooting/fallback kernel for VirtualBox users seems like the sane and efficient thing to do.

#16 Updated by cypherpunks 2017-03-09 11:33:04

From searching online, the values for various relevant DMI table entries (as Lua key-value pairs from dmi.gettable()) are:

• system.manufacturer: innotek GmbH
• system.product_name: VirtualBox
• bios.bios_revision: VirtualBox

Oh, and another idea comes to mind. VirtualBox Guest Additions present themselves in hardware as:

00:04.0 System peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Service

Lua scripts for syslinux can get PCI device info with pci.getinfo(). I wonder if this would allow an even finer grained test that would be able to give VirtualBox users the DKMS kernel only when they actually have guest additions enabled, instead of making all VirtualBox users suffer just because some of them may happen to want to sync clipboard contents.

I’ll test lua.c32 next time I restart Tails (if I can remember, at least).

#17 Updated by anonym 2017-03-09 12:12:41

segfault wrote:
> We acknowledge that losing clipboard sharing is an important UX hit for VirtualBox user. Whether that’s a good enough reason to 1. spend tons of time maintaining the DKMS thing; 2. making grsec much harder to get in Tails; was not something we could make up our mind firmly about.

I wasn’t present at the meeting, but here are some questions and opinions about this:

What do we base the statement “losing clipboard sharing is an important UX hit for VirtualBox users” on? Do we have any data supporting this, or are we simply assuming it based on our own workflows?

For me the situation is similar to our decision of dropping 32-bit support. That cost us a ton in maintenance over the years, and made security and some other features worse for all other users. In the end, we did the switch because we deemed the number of 32-bit users to be low enough for these sacrifices to not be worth it any more. When it comes to VirtualBox support, I think we’ve probably spent a comparable amount of work maintaining it. According to our estimates (from Feature #8183) we have 2.5% users running Tails through VirtualBox (with the 32-bit kernel), and some subset of these use the features provided by the kernel modules.

My take on the conclusion of the meeting is that: now we are considering to (even “leaning towards”) sacrifice an arguably important security improvement (Grsecurity-patched kernel) for all users because of a UX improvement that some among 2.5% of our users benefit from (not depend on, as in the “drop 32-bit support” case). This does not feel right, even borderline irresponsible. Am I lacking some perspective from the meeting that was not included in the summary?

#18 Updated by intrigeri 2017-03-09 18:26:18

> My take on the conclusion of the meeting is that: now we are considering to (even “leaning towards”) sacrifice an arguably important security improvement (Grsecurity-patched kernel) for all users because of […]

I think you’ve understood exactly the opposite meaning of what Feature #12104#note-7 is trying to say: we were leaning towards dropping the DKMS modules (despite the UX hit).

#19 Updated by cypherpunks 2017-03-10 01:37:03

intrigeri wrote:
> > My take on the conclusion of the meeting is that: now we are considering to (even “leaning towards”) sacrifice an arguably important security improvement (Grsecurity-patched kernel) for all users because of […]
>
> I think you’ve understood exactly the opposite meaning of what Feature #12104#note-7 is trying to say: we were leaning towards dropping the DKMS modules (despite the UX hit).

It did sound ambiguous. And actually, I misunderstood the meaning of the meeting consensus as well, which is why I scrambled to find a solution. Luckily, at least the ability to detect the specific virtualization type may come in handy later in order to disable UDEREF for the users who are using VMWare with hardware virtualization disabled, or to warn them of the caveats of using VMWare in specific configurations (which triggers extreme performance degradations[1]).

Here’s where I got confused:

>Decide whether we can drop DKMS modules support

>But we were leaning towards ‘no’ as an answer.

[1] https://forums.grsecurity.net/viewtopic.php?f=3&t=2191

#20 Updated by sajolida 2017-03-10 07:40:43

From the WB reports in 2016, VBox is more like 6% of user base:

But yes, other than that I have no clue how much these features are important.

#21 Updated by intrigeri 2017-03-10 08:15:58

> From searching online, the values for various relevant DMI table entries (as Lua key-value pairs from dmi.gettable()) are:

Thanks, this is great!

#22 Updated by intrigeri 2017-03-10 08:18:16

> It’s a win-win because most likely we’d end up providing a non-grsec kernel anyway for the troubleshooting boot option.

I hadn’t thought of this. I’m not 100% convinced it’s worth the increased ISO and upgrades size. My current take on this is we’ll decide based on early testing results by our community: if indeed “hardware pulls in drivers which are exercised in some way that triggers an unintentional grsecurity violation” happens often enough, then I guess we’ll have to do that. But that’s a point against grsec IMO (not to say it’s a blocker, of course) :/

#23 Updated by cypherpunks 2017-03-10 09:48:22

intrigeri wrote:
> > It’s a win-win because most likely we’d end up providing a non-grsec kernel anyway for the troubleshooting boot option.
>
> I hadn’t thought of this. I’m not 100% convinced it’s worth the increased ISO and upgrades size. My current take on this is we’ll decide based on early testing results by our community: if indeed “hardware pulls in drivers which are exercised in some way that triggers an unintentional grsecurity violation” happens often enough, then I guess we’ll have to do that. But that’s a point against grsec IMO (not to say it’s a blocker, of course) :/

The extra size for a compressed kernel and kernel modules (which can be compressed too, remember) should be negligible compared to an already huge ISO image, right?

The free grsecurity image is the testing kernel. While the linux-grsec in Debian is more stable (it’s not the patch immediately as it’s released), there is still the occasional issue with false positive violations from latent bugs or upstream kernel devs being stupid. Check out https://forums.grsecurity.net/viewforum.php?f=3 to see what kinds of problems people typically experience. Usually it’s in much less tested drivers or 3rd party drivers.

Here’s a shot in the dark idea. We could have the grsecurity kernel set to kexec into the non-grsec kernel immediately upon kernel panic (which is a supported feature for Linux, usually in order to start a kgdb shell to debug the crash). The non-grsec kernel could check the crash dump, which is in memory, to see if the panic was caused by a common grsecurity false positive (such as RAP and PaX size overflow). If it is, then it could display a friendly dialog telling the user that the system has crashed, and recommending a course of action (perhaps explaining that, if the crash always occurs in the same area, to boot with the non-grsec kernel instead). That would be instead of risking an increase of people who’s computers simply lock up (as kernel panics do not display anything in a framebuffer like Xorg). That would be much more user-friendly than simply freezing or rebooting instantly. IIRC, this is how Chrome OS displays its error message.

And, of course, it would let the user see the exact error message if they want. Things like the PaX size overflow plugin and RAP have been able to find real exploit attempts before, and even 0days. I have one in my possession which came from that, so it’s an incredibly useful method to both capture exploits, and to dissuade attackers from risking burning their 0days on Tails user when they know that everyone using Tails is going to see the panic message along with a suggestion to report it.

#24 Updated by intrigeri 2017-03-10 10:02:40

> The extra size for a compressed kernel and kernel modules (which can be compressed too, remember) should be negligible compared to an already huge ISO image, right?

Probably correct for the ISO, but probably wrong for “automatic” (incremental) upgrades.

#25 Updated by cypherpunks 2017-03-10 10:13:42

intrigeri wrote:
> > The extra size for a compressed kernel and kernel modules (which can be compressed too, remember) should be negligible compared to an already huge ISO image, right?
>
> Probably correct for the ISO, but probably wrong for “automatic” (incremental) upgrades.

How large is an average kernel upgrade for Tails? On my system, it’s around 3 MiB, but that’s a custom kernel which is stripped down and uses no modules. I don’t know how large it is for Tails.

Even if it is large, by default, modules are uncompressed. Compressing them with ZX gives you BCJ filters, which makes a real difference. A few extra MiB shouldn’t matter. But maybe I’m underestimating how many modules Tails users need.

#26 Updated by intrigeri 2017-03-10 13:00:31

> How large is an average kernel upgrade for Tails?

I wanted real-world data so I’ve just rebuilt one of our IUKs (the file that Tails Upgrader downloads, which is what matters in practice) without the (single) kernel upgrade that the original IUK had. The size difference is much smaller than I was expecting: it’s 34 MB (diff of the old to new root filesystem, compressed with SquashFS with crazy slow+efficient options) + 4 MB (compressed kernel) + 21 MB (compressed initramfs) = 59 MB. I assume that going from 1 to 2 kernel upgrades would yield similar results as going from 0 to 1 (I expect that the grsec and non-grsec kernels are different enough to prevent much space saving via compression). So upgrade and ISO size should not be a real blocker, especially considering we’ve been shipping 2 kernels already for years :)

#27 Updated by anonym 2017-03-10 13:03:29

cypherpunks wrote:
> Here’s where I got confused:

> > Decide whether we can drop DKMS modules support

> > But we were leaning towards ‘no’ as an answer.

Me too! I’m relieved! :)

sajolida wrote:
> From the WB reports in 2016, VBox is more like 6% of user base:

Note that we only care about the VirtualBox users that virtualize a 32-bit CPU architecture.

#28 Updated by anonym 2017-03-10 13:30:39

cypherpunks wrote:
> The extra size for a compressed kernel and kernel modules (which can be compressed too, remember)[…]

Our root filesystem is already xz-compressed, and so is the initramfs, so all modules we ship are already compressed.

> Here’s a shot in the dark idea. We could have the grsecurity kernel set to kexec into the non-grsec kernel immediately upon kernel panic (which is a supported feature for Linux, usually in order to start a kgdb shell to debug the crash). The non-grsec kernel could check the crash dump, which is in memory, to see if the panic was caused by a common grsecurity false positive (such as RAP and PaX size overflow). If it is, then it could display a friendly dialog telling the user that the system has crashed, and recommending a course of action (perhaps explaining that, if the crash always occurs in the same area, to boot with the non-grsec kernel instead). That would be instead of risking an increase of people who’s computers simply lock up (as kernel panics do not display anything in a framebuffer like Xorg). That would be much more user-friendly than simply freezing or rebooting instantly.

Wow, I love this idea! So is the userland actually surviving the kexec (sounds crazy!) so the error can be shown in the already running Xorg session? Or do you mean it would quickly boot into a minimal system that checks the origin of the crash of the previous kernel, and then displays a suitable message?

Do you have a link to an implementation? Perhaps…

> IIRC, this is how Chrome OS displays its error message.

… this one? :)

#29 Updated by cypherpunks 2017-03-10 23:35:47

anonym wrote:
> cypherpunks wrote:
> > The extra size for a compressed kernel and kernel modules (which can be compressed too, remember)[…]
>
> Our root filesystem is already xz-compressed, and so is the initramfs, so all modules we ship are already compressed.

The initramfs only contains a small portion of important modules. The majority of modules are put in /lib/modules and are typically not compressed unless you see them end in .ko.xz or so. That’s where a lot of the size comes from.

> Wow, I love this idea! So is the userland actually surviving the kexec (sounds crazy!) so the error can be shown in the already running Xorg session? Or do you mean it would quickly boot into a minimal system that checks the origin of the crash of the previous kernel, and then displays a suitable message?

No, the userland doesn’t survive kexec (I don’t think that would be possible in any situation where the kernel wasn’t able to simply recover and keep running), but a new userland can be loaded. It’d allow Tails to give a modern Windows-like stop error in the framebuffer: light blue screen, soft white letters saying that an error occurred. Isn’t that better than the mouse suddenly stopping and the whole system freezing, and the caps light blinking on and off rapidly? As long as a kernel panic can trigger a kexec (using a system called kdump[1]), which it typically can unless the panic is from such incredibly massive memory corruption that all the relevant code is crippled, it should work.

Note that grsecurity may interfere with kexec. There’s nothing that fundamentally prevents this (as mentioned in another ticket and in a mailing list thread with PaXTeam), but kexec() and related functionality may be disabled when certain grsecurity features are enabled, in order to prevent root from hijacking the system by using a malicious kernel.

> Do you have a link to an implementation? Perhaps…
>
> > IIRC, this is how Chrome OS displays its error message.
>
> … this one? :)

I looked into it more and I think it might not have been implemented by them yet. I thought they had, from memory, but I must have been remembering this, from their system hardening wiki page[2]:

>kexec-on-panic: While kdump is meant to aid in enterprise-grade kernel debugging, we can automatically boot over to a standby kernel if something goes wrong with our primary kernel. This means that we will gain the long term option of uploading kernel crash dumps, but at the very least, we could boot a kernel that displays “Awww, snap!” and safely reboots—or calls the autoupdater.

However, a minimal implementation which simply displays a friendly error without caring about the kernel crash dump should be absolutely trivial. It could even just display an image directly to /dev/fb0 using fbi or so. In fact, it could even kexec into the memory-wiping kernel, which could, while it’s wiping memory, display the error message. Since it wasn’t a wipe initiated by the user shutting down, it wouldn’t shut off immediately after finishing, but wiping memory is still good.

A more complex implementation that would parse the previous kernel log to see the source of the error and display it to the user, possibly with a “click here to see more information about the crash”, would be slightly harder, but still likely not difficult. The new kernel will expose the previous crashed kernel’s crash dump at /proc/vmcore (assuming you want it to be kept in memory and not written to disk), and then debug utilities[3], will be able to read its log buffer to find the exact cause of the crash, parse it, and display it in a terse or full form in the framebuffer.

[1] https://www.kernel.org/doc/Documentation/kdump/kdump.txt
[2] https://www.chromium.org/chromium-os/chromiumos-design-docs/system-hardening
[3] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-kdump-crash-log.html

#30 Updated by cypherpunks 2017-03-11 04:10:12

In order to get the kernel log buffer, the new kernel would use makedumpfile(8) in a POSIX script like this:

clear

makedumpfile --dump-dmesg /proc/vmcore | \
    sed -Ene '/^(OOPS|WARN|BUG|PAX|grsec): / { p;:a' -e 'n;p;ba' -e '}' > \
    /tmp/vmcore.dmesg

echo "A system error has occurred and a reboot is needed."
echo "The error causing the crash is:"
echo

head -n1 /tmp/vmcore.dmesg

echo
echo "Press Enter to see full details, or any other key to reboot now."
read -s -n1 key
test -z "$key" && reboot -f

cat /tmp/vmcore.dmesg
echo "Press any key to reboot."
read -s -n1
reboot -f

Obviously this is just an example, and uses the terminal to display the messages instead of a graphical framebuffer. The text could of course be passed through anything which converts it into an image which could be passed to a tool like fbi which can write it directly to the framebuffer. GraphicsMagick for example can do everything needed.

#31 Updated by cypherpunks 2017-03-11 07:01:28

cypherpunks wrote:
>

test -z "$key" && reboot -f

Oops. That was supposed to be -n, not -z.

#32 Updated by cypherpunks 2017-03-13 02:16:08

cypherpunks wrote:
> anonym wrote:
> > Our root filesystem is already xz-compressed, and so is the initramfs, so all modules we ship are already compressed.
>
> The initramfs only contains a small portion of important modules. The majority of modules are put in /lib/modules and are typically not compressed unless you see them end in .ko.xz or so. That’s where a lot of the size comes from.

Oh now I get what you meant. You’re right, disregard.

Does SquashFS use BCJ filters for ZX compression in Tails?

#33 Updated by intrigeri 2017-03-13 07:01:42

> Does SquashFS use BCJ filters for ZX compression in Tails?

Here are the options we pass to mksquashfs: -comp xz -Xbcj x86 -b 1024K -Xdict-size 1024K.

#35 Updated by intrigeri 2017-03-17 11:04:43

sajolida wrote:
> From the WB reports in 2016, VBox is more like 6% of user base:

Interestingly, the shared clipboard feature of VirtualBox has apparently been broken since 3.0~beta1 (Bug #12357), and AFAIK only 2 users reported it.

#36 Updated by intrigeri 2017-03-17 11:05:34

anonym wrote:
> sajolida wrote:
> > From the WB reports in 2016, VBox is more like 6% of user base:
>
> Note that we only care about the VirtualBox users that virtualize a 32-bit CPU architecture.

I don’t understand what you mean here. Can you please rephrase?

#37 Updated by anonym 2017-03-17 11:17:35

intrigeri wrote:
> anonym wrote:
> > sajolida wrote:
> > > From the WB reports in 2016, VBox is more like 6% of user base:
> >
> > Note that we only care about the VirtualBox users that virtualize a 32-bit CPU architecture.
>
> I don’t understand what you mean here. Can you please rephrase?

It’s only the users on 32-bit that have had the kernel modules (clipboard sharing) and thus only those that would experience a regression; any 64-bit users have not had them for years, so it’s not a regression for them. I thought it was fair to make this distinction here.

#38 Updated by intrigeri 2017-03-17 15:22:20

> It’s only the users on 32-bit that have had the kernel modules (clipboard sharing) and thus only those that would experience a regression; any 64-bit users have not had them for years, so it’s not a regression for them. I thought it was fair to make this distinction here.

OK, thanks for clarifying! Let’s keep it mind, though, that our doc has been recommending for a while to set up 32-bit guests on VirtualBox (regardless of what CPU the host has), and we’ve been pointing to it anyone complaining about suboptimal integration, such as lack of clipboard sharing. So in practice, this will affect not only the users who have a 32-bit CPU, but also those who have followed our doc, e.g. because they wanted this feature :)

#39 Updated by anonym 2017-03-17 15:29:52

intrigeri wrote:
> > It’s only the users on 32-bit that have had the kernel modules (clipboard sharing) and thus only those that would experience a regression; any 64-bit users have not had them for years, so it’s not a regression for them. I thought it was fair to make this distinction here.
>
> OK, thanks for clarifying! Let’s keep it mind, though, that our doc has been recommending for a while to set up 32-bit guests on VirtualBox (regardless of what CPU the host has), and we’ve been pointing to it anyone complaining about suboptimal integration, such as lack of clipboard sharing. So in practice, this will affect not only the users who have a 32-bit CPU, but also those who have followed our doc, e.g. because they wanted this feature :)

Yes — when I said “user on 32-bit” above, I mean users that virtualize a 32-bit CPU in VirtualBox regardless of real CPU. Sorry for being unclear! My point was more about that users that virtualize a 64-bit CPU in VirtualBox can be ignored when counting how many users will experience the regression of losing clipboard sharing (etc) if we drop these modules.

#40 Updated by intrigeri 2017-03-17 17:52:36

> My point was more about that users that virtualize a 64-bit CPU in VirtualBox can be ignored when counting how many users will experience the regression of losing clipboard sharing (etc) if we drop these modules.

ACK!

#41 Updated by cypherpunks 2017-04-01 03:41:20

So does it look like we’ll be autodetecting VirtualBox users and giving them a DKMS kernel with a bootloader script like in Feature #12104#note-12, or dropping DKMS support entirely? It seems like the latter because the 32-bit VirtualBox support will be dropped anyway, and 64-bit VirtualBox users aren’t going to be counted.

#43 Updated by intrigeri 2017-04-01 06:44:58

> So does it look like we’ll be autodetecting VirtualBox users and giving them a DKMS kernel with a bootloader script like in Feature #12104#note-12,

IMO yes, but only if/when we can ship a grsec kernel for everyone else: at this point this ticket is blocked by progress on the parent one, not the opposite anymore.