not an issue, but lack of issues

[miroR]

And so I think this is the place to let people know about it.
It's complex to explain. I have had at least these issues:
minipli/linux-unofficial_grsec#17
minipli/linux-unofficial_grsec#18
minipli/linux-unofficial_grsec#19
minipli/linux-unofficial_grsec#20
minipli/linux-unofficial_grsec#23
on one particular system, that could be due to bugs there, or could be due to attack.

I'm posting here about it because what I couldn't get with grsecunoff, I'm getting with dappersec: long hours and days without any issues like the above.

The complexity stands in that those issues could have been due to some Amd64 PSP feature(s) abused by attacker... Who knows?

OTOH, I perfectly understand how meltdown and spectre fixes are necessary. But to be missing features that this fork of grsec offers, by opting for upstream kernel, where there are no protection that this fork of grsec offers, I think that is even worse.

I have run 4.9.92 dappersec (available at: https://www.croatiafidelis.hr/gnu/deb/linux-4.9.92-dappersec180601-06/ )
and now 4.9.105 dappersec.

[miroR]

Again, while #6 is not negligeable,and while I can not be sure yet. I've now tested

$ uname -r
4.9.105-dappersec180605-23
$

a lot. I've tested it with all the tasks that I had had lots of breakages with previously, which I had lots of bugs showing up, freezes, lockups...

And I have had no other issues but what I reported in #6.

I have prepared more on this, for a separate post.

[miroR]

kernel config same as:

segfaults upon install of uBlock0 in Pale Moon on grsecunoff kernel-based Linux #27
minipli/linux-unofficial_grsec#27 (comment)

except for:

# diff -u config-4.9.105-dappersec180605-23  config-4.9.74-unofficial+grsec180216-23 
--- config-4.9.105-dappersec180605-23   2018-06-06 00:09:27.000000000 +0000
+++ config-4.9.74-unofficial+grsec180216-23     2018-02-17 04:53:11.000000000 +0000
@@ -1,6 +1,6 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Linux/x86 4.9.105 Kernel Configuration
+# Linux/x86 4.9.74 Kernel Configuration
 #
 CONFIG_64BIT=y
 CONFIG_X86_64=y
@@ -53,7 +53,7 @@
 CONFIG_INIT_ENV_ARG_LIMIT=32
 CONFIG_CROSS_COMPILE=""
 # CONFIG_COMPILE_TEST is not set
-CONFIG_LOCALVERSION="180605-23"
+CONFIG_LOCALVERSION="180216-23"
 # CONFIG_LOCALVERSION_AUTO is not set
 CONFIG_HAVE_KERNEL_GZIP=y
 CONFIG_HAVE_KERNEL_BZIP2=y
@@ -378,6 +378,7 @@
 CONFIG_X86_FAST_FEATURE_TESTS=y
 # CONFIG_X86_MPPARSE is not set
 # CONFIG_GOLDFISH is not set
+CONFIG_RETPOLINE=y
 # CONFIG_X86_EXTENDED_PLATFORM is not set
 # CONFIG_X86_INTEL_LPSS is not set
 # CONFIG_X86_AMD_PLATFORM_DEVICE is not set
@@ -4141,6 +4142,7 @@
 CONFIG_HAVE_PAX_INITIFY_INIT_EXIT=y
 CONFIG_PAX_LATENT_ENTROPY=y
 CONFIG_PAX_RAP=y
+CONFIG_PAX_RAP_VERBOSE=y
 
 #
 # Memory Protections

which is the whole difference.

Since we're at it, almost nothing is, or just one line

(
just the:

CONFIG_PAX_RAP_VERBOSE=y

I had previously had added, and now I have removed again, I think.
)

So, nothing has changed since also:

NULL pointer deref in do_blockdev_direct_IO() #13
minipli/linux-unofficial_grsec#13 (comment)

That's the dappersec, the grsecurity's fork, configuration of mine.

Next is one important thing to understand when I talk about the whole plethora of bugs that I had.

I clone my systems, and by proper dd-backing up of my Air-Gapped system (truly Air-Gapped, I very well control what gets into it, no internet, not even local network, mostly) into images with the good old dd program, I get the Air-Gapped system restored to-the-bit (yes!) into another two types of MBO, both AMD64 processor based, that are compatible enough.

These are the two MBOs that I use, the old and the new as per:
Use old amd64 gentoo image on new amd64 hardware, possible?
https://forums.gentoo.org/viewtopic-t-940916.html

Soo, my Air-Gapped images get into some two to four other systems to-the-bit. Well, once I restore them the right way, of course there's some grub-install and update-initramfs do do to get those to boot, but basically, that's it!

And here's the important thing to understand about all those plethora of bugs that I have reported until recently only on https://github.com/minipli/linux-unofficial_grsec/issues/:

they all occur (it's a lot of reports, and I've re-read a lot but not all, so this is to my best remembrances):

almost all, if not really all those issues occur in only one system, one of all my cloned systems.

And how is that possible? Software same or similar, and yet bugs only in one set of hardware? Istance of hardware, not just model.

You tell me how that is possible!

I can say that the only one major difference in hardware is the presence of two old Hauppauge cards in the one system that gets all the bugs to show in it...

It's two Hauppauge HVR3000 cards. The description of concrete scripts that I use on them can be found at:

kernel tried to execute NX-protected page - exploit attempt? (uid: 1000, task: Xorg, pid: 3433)
minipli/linux-unofficial_grsec#20 (comment)

I have run those maybe even hundreds of times in these two days, with no issues, on my:

$ uname -r
4.9.105-dappersec180605-23
$

And, just a few more clarifications, for the lack of bugs showing to be more plain and clear to appreciate, in case it remains so, with this dappersec grsecurity fork... I'll try and make it soon, but this is a lot of work to present...

So, just a few more clarifications, in the next post, hopefully...

[miroR]

But before the next post, pls. visitors, be aware of blueness strong suspicion, and how hard those bugs of mine, which are mostly missing with dappersec, so far, are hard to nail down at:
eudev-3.2.5 waits 10 seconds before processing an event #153
eudev-project/eudev#153 (comment)

Not trying to teach anybody, but that is the guy who maintained grsec in Gentoo since, I guess, the very first adoption into Gentoo portage, that is Anthony Basile, blueness, talking.

So, maybe, if this lack of bugs lasts with this system of mine, maybe @msr50 's approach shows good work, and shows clear work with the code, and ought to be followed.... But let's see if all those plethora of bugs that I had with grsecunoff really keep missing from dappersec to try and draw conclusions...

Still one "next" clarifications post to make...

[miroR]

When minipli suggested I seemed to

change kernels frequently
at:
kernel tried to execute NX-protected page - exploit attempt? (uid: 1000, task: Xorg, pid: 3433) #20
minipli/linux-unofficial_grsec#20 (comment)
I gave the explanation in the post right after his statement.

With dappersec, I'm currently using 4.9.105, and it is in, just as I explained there:

two sets of kernels, one is no-modules-loading my own hardware only, for my regular use, and the other is what I offer to others, which has all the modules as any general-purpose kernel,

One, the general purpose one (not on
https://www.croatiafidelis.hr/gnu/deb/linux-deb-grsec-current/ , but the 4.9.92 is and I plan to offer 4.9.107), that I've tested for some two or so days is:

$ uname -r
4.9.105-dappersec180605-13
$

and the other, the my own hardware only, that I've tested for even longer, and that I'm still currently testing as I write, is:

$ uname -r
4.9.105-dappersec180605-23
$

[miroR]

The https://www.croatiafidelis.hr/gnu/deb/linux-deb-grsec-current/
now points to:
https://www.croatiafidelis.hr/gnu/deb/linux-4.9.107-dappersec180615-20/
I've tested it on three systems (two types of MBO).
Been working great since this morning, without issues on two systems, and basically without issues on the problematic system where I had many bugs with grsecunoff and just a few, at bootime, with dappersec... well... so far that is...

[miroR]

I think I should point eventual readers to:

Re: Grsecurity/Pax installation on Debian GNU/Linux
http://forums.debian.net/viewtopic.php?f=16&t=108616&p=675341#p675341

as well...

[miroR]

The packages 4.9.111 offered for download and "dpkg -i" installing at:
http://forums.debian.net/viewtopic.php?f=16&t=108616&p=676760#p676760
and:
https://dev1galaxy.org/viewtopic.php?id=596#p10698
( i. e.:
https://www.croatiafidelis.hr/gnu/deb/linux-4.9.111-dappersec180710-21/ )
Tested, works w/o issues on two of my systems.

[miroR]

Anybody wants deb packages, these should work, as reported on Debian/Devuan:
http://forums.debian.net/viewtopic.php?f=16&t=108616&p=677645#p677645
or:
https://dev1galaxy.org/viewtopic.php?pid=10945#p10945
i.e.:
https://www.croatiafidelis.hr/gnu/deb/linux-4.9.115-dappersec180727-10/

[miroR]

https://www.croatiafidelis.hr/gnu/deb/linux-4.9.119-dappersec180810-06/
see previous post (and around) for how to install it and other stuff.

[miroR]

https://www.croatiafidelis.hr/gnu/deb/linux-4.9.120-dappersec180816-16/
see previous posts (and around) for how to install it and other stuff.

[miroR]

https://www.croatiafidelis.hr/gnu/deb/linux-4.9.122-dappersec180820-16/
see previous posts (and therefrom) for how to install it and other.

[miroR]

https://www.croatiafidelis.hr/gnu/deb/linux-4.9.126-dappersec180914-10/
see previous posts (and therefrom) for how to install it and other.

[miroR]

https://www.croatiafidelis.hr/gnu/deb/linux-4.9.128-dappersec180924-07/
see previous posts (and therefrom) for how to install it and other.

[miroR]

It's pretty sad, but I'm afraid I'm leaving grsec/dappersec as user/packager... See here:
minipli/linux-unofficial_grsec#30 (comment)

spender and PaX Team, if you are by some chance, reading this, it's pretty probable the grsec in the GNU world will die if you don't give us a boost with the Meltdown and Specter patches...
But there is probably no more arguing... you have chosen your way in life, and I wish you good luck!

Thanks @msr50 it's been a pleasure, but no, it's too vulnerable without those patches... Good luck to you too!

[matthewruffell]

That's okay @miroR, I understand. Thanks for being a user and giving your reviews.
I'm thinking much the same these days, and I will soon move to upstream, and perhaps use the time I spent maintaining dappersec into sending some patches upstream.

For those that are reading, I will continue to maintain dappersec for a little while longer. My current plan is to continue on until the original EOL for Linux 4.9, which is Jan 2019.

I will attempt to land GCC 8 support soon, which will help out anyone wishing to continue maintenance. Although I probably would not recommend it, 4.9 is starting to age now, and probably shouldn't be used on the desktop in 2019.

This post by Greg K-H is pretty good: What stable kernel should I use?

This part is the most relevant:

There is one huge caveat when using a kernel like this. The number of security fixes that get backported are not as great as with the latest LTS release, because the traditional model of the devices that use these older LTS kernels is a much more reduced user model. These kernels are not to be used in any type of “general computing” model where you have untrusted users or virtual machines, as the ability to do some of the recent Spectre-type fixes for older releases is greatly reduced, if present at all in some branches.

So again, only use older LTS releases in a device that you fully control, or lock down with a very strong security model (like Android enforces using SELinux and application isolation). Never use these releases on a server with untrusted users, programs, or virtual machines.

While dappersec is a strong security model, it still is not perfect. There have been a lot of vulnerabilities reported by syzkaller that have been fixed upstream and not backported to 4.9 yet, and probably never will be. While dappersec keeps you safe from most classes of vulnerabilities, it will never compare with running a newer kernel + new grsecurity.