compilation error with grsecurity patch to Debian kernel

[Construx]

If this post should be elsewhere, please advise. Best I could tell, it appeared to belong here.

I am trying to make use of grsecurity in my Debian kernel on a server. I am not a programmer, but I managed to understand the instructions for patching the kernel by following the well-written procedure given here: http://en.wikibooks.org/wiki/Grsecurity#Installation. I believe all proceeded nicely until the very end, when I encountered two errors (at least it appeared to me to be only two). I had just entered the following command, "fakeroot make deb-pkg", and quite a bit of activity was passing by, apparently successfully, until the end when it stopped finally back at the prompt. These are the last several lines of the output before stopping:

xpressions [-Wsign-compare]
scripts/selinux/genheaders/genheaders.c:129:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
HOSTCC scripts/selinux/mdp/mdp
HOSTCC scripts/kallsyms
HOSTCC scripts/conmakehash
CC init/main.o
In file included from init/main.c:40:0:
include/linux/cpuset.h: In function âput_mems_allowedâ:
include/linux/cpuset.h:121:2: error: decrement of read-only location â*(const volatile int *)&get_current()->mems_allowed_change_disableâ
init/main.c: In function âdo_initcallsâ:
init/main.c:779:3: error: implicit declaration of function âadd_device_randomnessâ [-Werror=implicit-fun ction-declaration]
cc1: some warnings being treated as errors
make[3]: *** [init/main.o] Error 1
make[2]: *** [init] Error 2
make[1]: *** [deb-pkg] Error 2
make: *** [deb-pkg] Error 2
----------------------------------------

Not being a programmer, and not having much experience in kernel building, unfortunately, I have no clue as to what can be done about this now. I am not sure whether what I have done so far has affected my system already in any kind of adverse way, but I suppose the next reboot will answer some of that one way or another. Nor am I sure whether I ought to "clean up" what I now have before proceeding. If my system appears to function as it is, then I will just "wait it out" till I hear something back from someone here. The server is not in production mode as yet because I wanted to get these conditions in order first. Otherwise, I will need to completely restore the backup image I had made and loose whatever state it has currently, and possibly regroup with plan B. Please advise. Thanks.

[spender]

Which patch was used for this kernel? We only support patching of vanilla kernels. I do recall a compile failure like this several months ago but it was solved at that time.

-Brad

[Construx]

Hi, Brad.

I downloaded everything from the sources listed on the procedure page here: http://en.wikibooks.org/wiki/Grsecurity ... grsecurity, which included these:

grsecurity-2.9.1-3.2.48-201306302051.patch
linux-3.2.21.tar.gz

And I used the keys to verify them too. Thanks.

[spender]

Ah, you missed this part:

For this reason we will download the official unmodified kernel from http://www.kernel.org/. Download the full kernel source package and its signature (the ‘’.sign'’ file), and make sure its version matches the version of the grsecurity patch you downloaded. In this document the version is 3.2.21. The required version is most likely not the latest, so you need to get it from the kernel archives.

Feel free to update the Wiki to make it more clear for other users, that's what it's there for.

Since the patch you downloaded was for the latest 3.2 kernel, 3.2.48, then you need to download the 3.2.48 kernel from kernel.org and patch against that. When you patched, you likely saw many errors in the patch process (a find -name "*.rej" in the kernel source tree would have shown many files). When the patching is done correctly against the right kernel, you'll see none of these errors.

-Brad

[Construx]

"...make sure its version matches the version of the grsecurity patch you downloaded...." I should have used this kernel with my chosen patch file: linux-3.2.48.tar.gz


MY Bad!

Have you ever heard the saying, "You can lead a horse to water, but you can't make it drink"? Right now I feel like one of them there horses in front of a troth, or, more accurately perhaps, a donkey. But you can just call me jack.

Do I need to remove anything I have deposited on my system before proceeding with a rerun using the "right" parts of this wonderful program, or can I just go right on top of it but use a separate build folder from the get-go? Alternatively, if you can point me to a generally good guide for doing this sort of thing, I would be much obliged, again. There is a plethora of instruction on these procedures, and I have to believe that much of it is lacking. Thank you, brad.

[spender]

Just remove the old build directory as you won't use it. Start again with the patch and the appropriate kernel version (3.2.48). There are no changes to the system when you are building a kernel, it's all self-contained within the build directory. The "make modules_install" and "make install" commands are what modify the system to install the newly built kernel and its modules. If the instructions you've found are too difficult, you could instead look at any other instructions for installing custom kernels, as the only additional step here is patching in grsecurity and enabling it in the configuration.

-Brad

[timbgo]

There was an unlikely, and modest and ugly because not apparent at first, reason why people got uncertain whether they were compiling the right kernel, in Debian, me included.
I think I've corrected the subterfuge-like reason. Read on.
Here:
https://en.wikibooks.org/wiki/Grsecurity/Configuring_and_Installing_grsecurity
precisely at the end of the section entitled:
On Debian and Ubuntu
the link opened the section of the Debian kernel Handbook that was misleading, this one:
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-building
because it instructed to:
$ apt-get install linux-source-3.2
et cetera. Which is wrong. It leads you wrong, to compile Debian modified, and not vanilla kernel!
I corrected that now, and that very last link in the Debian and Ubuntu section of that page, is now:
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package
Now the page and the references therefrom are consistent! It instructs you to compile the vanilla kernel!
Just to mention, that was the sole minor edit I just made to the page.
However, Jimmy Wales and co. are not Spender and Pax Team, so they can't deal with Tor browser, and I was forced to use a plain browser, in this case, lightweight Hv3 is what I settled for, but that wasn't even https... I hope my MiroR2 and password weren't stolen as they can be, and by those that tap the world full and complete.
Namely, now everybody could learn how all the Internet is tapped by the Police State No1 and this is one more obvious reason for my absolute support for honest security people like grsecurity/pax devs.
I'm compiling testing grsecurity patch on 3.9.8 kernel on my Debian systems, slow, take loong.
I recommend Gentoo (my faster systems) and grsecurity/pax hardened kernels to all of you. It's a charm on Gentoo. I posted strong support for grsecurity and against NSA's SeLinux way back, two or more years ago there, as user MiroR!
I am still very very confident that SeLinux it purposefully full of holes, exactly because NSA is as sick as needing to spy on the whole world. Gosh! Miro, shut up, else you'll get killed like other "small fry", like Aaron Schwartz, or people who figured the inside job on some nice towers in some great City on the East Coast or like Navy Seals who served their country but needed to be silenced after they killed some person by the name Osama...
Pls. support Edward Snowden!
And I'll shut up now!

If I'm not back for help, grsecurity-2.9.1-3.9.8-201306302052.patched vanilla linux-3.9.8 on my updated Debian works fine!
Some, call it instructions for begiinners, I managed to arrive at here on this forum, as this user timbgo, about two or three months ago, and also here:
http://forums.debian.net/viewtopic.php?f=16&t=103425
Pls. don't delete this post, it's free speech along with strong and honest support for your work! Thank you!

[Construx]

"I am still very very confident that SeLinux it purposefully full of holes,..."

Grsecurity over SeLinux (even on pure principle) +1

[timbgo]

"I am still very very confident that SeLinux it purposefully full of holes,..."

Grsecurity over SeLinux (even on pure principle) +1

I figured that out back when I read:

http://www.crmbuyer.com/story/39565.html

which I was now able to find thanx to me having drawn attantion to it in thei post of mine:
http://forums.gentoo.org/viewtopic-t-905472-start-0.html#6901826

That on crmbuyer.com was Spender in 2005.

GNU/Linux is one of the strongest bastion left for us all of Internet freedom, but only due to people who haven't sold out to the growing secret NSA afficionados club.

I have a few problems left with the Debian grsecurity install. But I'm still new to Debian, so it could be time figuring what it is...
But before I move on to presenting the problems left in my current grsecurity patched kernel compilation, I only wish to try and point investigative minds of today, to try and promote the truth on GNU/Linux security...
The freedom in computing which is absolutely fundamental in all aspects of freedom in the world culture, the world politics/activism, in science, in you name it in the world today...
The freedom in computing hinges on true security of users.
I cannot imagine my own, and it is typical of so many "small fry" like me world wide, IMO, I cannot imagine having any true defence against the Googles and the Microsofts of the day without Grsecurity/Pax!
You, bigger businesses who can fund and donate, don't follow Soroszes and any other Builderburg group's infatuated mighty men of effemeral glory that ends in Hell... They ruin even countries (Sorosz ruined a lot in my Croatia), for the sake of their stupid infatuation with what they can with the wealth they made with all their legalized frauds and gimmicks on masses of the world, after haveing bought most all in among the political "elites". I wouldn't be under your skin for a second, fools!
I hope to God there are still honest people, I know there are, in amongst the rich of this day.
Donate here, to these true and honest developers!
Journalists, promote the truth of these paramount programs in view of what GNU/Linux means for freedom in the world.
Teachers, teach children the free GNU/Linux (which is not the sold out SuSE's or Fedoras or Mandrakes)!
Stories here many to be kept for next generations! Such as:
I want to remind people that, I'm sorry, I can't find the link now, but Spender was, back years ago, on the verge of abandoning Grsecurity project, due to poverty.
You who own riches have the obligation to not ruin the world, if not to actually use you money for at least somewhat, somewhat, somewhat at least relatively good and useful purposes for everybody! This here too is an arena of the fight btwn Good and Evil.
I'll now prepare to present where my testing grsecurity compilation is, more purely technically, in next post.
But it's just a minor hurdle, or what appears as such...

[timbgo]

I'll start by showing what just above the compilation directory the (I now know: incomplete) deb packages looked like for at least 40 (forty) minutes.
They looked like this (from the linux-3.9.8/ grsecurity patched compilation directory, and towards the end of the 'fakeroot make deb-pkg' run, all as per instructions from wikibooks and Debian Kernel Handbook, all pointed at in previous posts above):

Code: Select all

$ ls -ltr ../*.deb
-rw-r--r-- 1 mr mr 1136130 Jul  5 10:52 ../linux-firmware-image_3.9.8-grsec130704-1_amd64.deb
-rw-r--r-- 1 mr mr 8351468 Jul  5 10:52 ../linux-headers-3.9.8-grsec130704_3.9.8-grsec130704-1_amd64.deb
-rw-r--r-- 1 mr mr  926398 Jul  5 10:53 ../linux-libc-dev_3.9.8-grsec130704-1_amd64.deb
-rw-r--r-- 1 mr mr   64572 Jul  5 10:53 ../linux-image-3.9.8-grsec130704_3.9.8-grsec130704-1_amd64.deb
$

I back then (that was about two hours ago), issued:

Code: Select all

# dpkg -i --dry-run *.deb
(Reading database ... 170789 files and directories currently installed.)
Preparing to replace linux-firmware-image 3.2.43-grsec130418-1 (using linux-firmware-image_3.9.8-grsec130704-1_amd64.deb) ...
Selecting previously unselected package linux-headers-3.9.8-grsec130704.
Unpacking linux-headers-3.9.8-grsec130704 (from linux-headers-3.9.8-grsec130704_3.9.8-grsec130704-1_amd64.deb) ...
Selecting previously unselected package linux-image-3.9.8-grsec130704.
Unpacking linux-image-3.9.8-grsec130704 (from linux-image-3.9.8-grsec130704_3.9.8-grsec130704-1_amd64.deb) ...
Preparing to replace linux-libc-dev:amd64 3.9.6-1 (using linux-libc-dev_3.9.8-grsec130704-1_amd64.deb) ...
root@debinv38:/Cmn/dLo#


I thought I could go on and run:

Code: Select all

# dpkg -i *.deb

but I'm now glad I didn't! Read on.

I just came home from local market (minute "small fry" vendors' fruit and groceries sales, those that tourists like to visit in Europe, because of the nostalgic feeling of times past) in Zapruđe (pronounce zaaproojey), a suburrb of Zagreb in Croatia, where I live (just another satellite to the US, the dangerous self-ruining and worldwidely criminal superpower (who betrayed their own forefathers and ideals and constitution), as most any state of the EU beauro-over-state), because I was flagmatic enough to let the matter wait or work itself out as slowly as it went, even though my system is *not* that slow.
And I now find that the fakeroot, which I saw like this for at least 40 minutes:

Code: Select all

mr@debinv38:/Cmn/dLo/linux-3.9.8$ jobs
[1]+  Running                 fakeroot make deb-pkg &
mr@debinv38:/Cmn/dLo/linux-3.9.8$

while there wasn't any progress to be made for that time and very probably longer, except the system going strong on resources, just as it is going at this time as well, even without anything legitimately using those resources!
The gkrellm is at 99% all the time, but let's show top, which shows the same.

Code: Select all

# top
...[snip]...
KiB Mem:   4054260 total,  3672492 used,   381768 free,    90772 buffers
KiB Swap: 13631484 total,      704 used, 13630780 free,  2636832 cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM     TIME+ COMMAND                     
 4086 root      20   0  495m 9224 2924 R 19.7  0.2 200:05.17 gnome-shell                 
 3327 mr        20   0  496m 9224 2924 R 19.4  0.2 205:23.49 gnome-shell                 
 3932 root      20   0  496m 9224 2924 R 19.4  0.2 201:16.58 gnome-shell                 
 3162 mr        20   0  496m 9236 2924 R 19.1  0.2 206:39.38 gnome-shell                 
 3472 mr        20   0  496m 9232 2924 R 19.1  0.2 204:57.14 gnome-shell                 
 ...[snip]...
 

And that was the case even when I shut all the shells down and out, leaving only the one shell where the fakeroot wasn't about to finish till apparently doomsday...

I looked up in /var/log, but I wasn't able to find anything that I recognized as indication.
I also wonder why I don't have /var/log/grsec.log in Debian, as I have in Gentoo, and I guess that is either down to manu configure, which I will try to find time and go and study more deeply, or down to developers, which in Gentoo there are people who really do apply Grsecurity in Gentoo hardened kernel as it is due, so here I express my appreciation and my thanks to them...
I just find that dmesg got all the grsec messages, but that's pretty limited by default, and even if I wanted I wouldn't be able to find what grsec was telling me before those 100 or 200 lines that are left to see when firing

Code: Select all

# dmesg

So... Somebody tell me what this could be, if they know.
what is spending resources of my system, when nothing I run remotely need that much of them.

Code: Select all

root@debinv38:/var/log# cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family   : 15
model      : 47
model name   : AMD Athlon(tm) 64 Processor 3800+
...

root@debinv38:/var/log# cat /proc/meminfo
MemTotal:        4054260 kB
...

Anyway, back a half hour ago, when I just came home from local market, I found that:

Code: Select all

mr@debinv38:/Cmn/dLo/linux-3.9.8$ jobs
[1]+  Done                    fakeroot make deb-pkg
mr@debinv38:/Cmn/dLo/linux-3.9.8$

and that those files were all now really complete:

Code: Select all

mr@debinv38:/Cmn/dLo$ ls -ltr *.deb
total 1036988
-rw-r--r--  1 mr mr   1136130 Jul  5 10:52 linux-firmware-image_3.9.8-grsec130704-1_amd64.deb
-rw-r--r--  1 mr mr   8351468 Jul  5 10:52 linux-headers-3.9.8-grsec130704_3.9.8-grsec130704-1_amd64.deb
-rw-r--r--  1 mr mr    926398 Jul  5 10:53 linux-libc-dev_3.9.8-grsec130704-1_amd64.deb
-rw-r--r--  1 mr mr 533732250 Jul  5 13:14 linux-image-3.9.8-grsec130704_3.9.8-grsec130704-1_amd64.deb
mr@debinv38:/Cmn/dLo$ $

And it appeared that the system was doing nothing real for those 10:53 to 13:14, two hours and twenty minutes... I did search for activities in /tmp and elsewhere, none real activities...

It is my suspicion that some vitrioloids who made their way into Debian decision makering circles apparently do not accomodate Debian for anything other than SeLinux and his associates, and that they seem to do it stubbornly and on purpose. That is my suspicion.
I also hope there are still forces for good at Debian that could turn the tide back into what Debian has been, and that is truly free computing, which SeLinux and lookalikes are certainly not.
That is my suspicion, and I wish I were wrong.

I am a little lost again.
But since I spend so much time already, I'll wait a little longer, an hour or two, and if I don't get any advice, I'll go on and install the packages

Code: Select all

# dpkg -i *.deb 

and report back if I installed my grsecurity patched kernel fine.

[timbgo]

Again, mkinitrd problems, just like with the previous attempt of mine, 2-3 months ago, where it was clear to me that nkinitrd wouldn't install my kernel...
More research to find out about these versions is due...

Just what happened is, dpkg -i *.deb installed all fine, no complaining, ran grub-mkconfig fine, no errors, but upon reboot into the new kernel, it don't recognize the root device, because it didn't properly include lvm2 manager program...
...and no boot, dumped into mkinitrd shell, or whatever it's called.

But, there's more changes...
It was, the resources expenditure at 99% all the time, probably due to one or two reboots to little upon my Debian upgrade, from IIRC Wheezy to Jessie, the interval being a little too long, the two months and a week or two. That's normal to incur a penalty after such long interval without upgrades...
And that 99% resources in /dev/null (I'm joking, but it is invisible resources expenditure to a user like me), is gone now.
And the kernel patched with testing grsecurity, is now at least 5 times faster in compilation, same procedure as above.

[timbgo]

I haven't given up, and neither have I successfully compiled in the grsecurity patched kernel.

I am stuck with initramfs's very strange:
"No-boot kernel, working lvm in initramfs, volumes not found"
( http://forums.debian.net/viewtopic.php?f=5&t=105549 )
error, and, as you can see in that topic on Debian fori (that's the Latin plural), to get support, since very scant support is (even deliberately no support, even hurdles against --sic! pls. find in my 2 or three months old post, for anyrhing non-SELinux, which shifts default for new Debian users... Sorry that's the end of Debian as truly free, let alone secure, if the vitrioloids take entire Debian over that way...)...

...And to get support, having two same arch Debian systems. siblings, almost twins in hardware, I am now compiling also the Debian testing 3.9.6 kernel, as well as 3.9.8 separately, because the grsecurty-patched 3.9.8 and their 3.9.6 from testing branch hold up at that exact same initramfs error, and throw the same or similar error and just don't boot.

It is wrong time, Sunday, the weekend, little Internet ,more barbecue, or everything else, time... and it is even dead time of night over in the American continents right now... Only 24 people even saw my post in 6 (six) hours over there...
So, no hurry...
But it would be great if we could get our grsecurity patched vanilla 3,9,8 kernel to work on Debian, for the sake of freedom and true security.
Never mind how acutely broken my nerves got (it's over now, may God forgive me for all the ranting, keyboard smashing and the likes, I'm back calm and peaceful), I am willing to stick around here and show all the details of my compilations to fix this, if anyone can get us expert insight into this...

I see:
https://forums.grsecurity.net/viewtopic.php?f=3&t=3596
Construx has successfully installed 3.2.48 grsec-patched! I'm glad for him! Glad for you, Construx, if you're reading this!
But, I'cite what I wrote on my Debian post last night (link further above):
Anyways, I could probably install the stable 6 (six) or more months old kernel, but I'm a little despondent at the very fact that so old stuff seems to be the only option.

Anyway, no hurry here, wrong time of week...

[timbgo]

Here's how my, at the time of publishing: complete, posts end up referencing non-issue, made-wrong links:
viewtopic.php?f=3&t=3032&p=12873#p12873

I looked up my old post, because I wanted to give links to people like Construx, on deliberate hurdles in Debian distro against grsecurity, but I had to post the EDIT into the old post, and this is wasting my strength to no avail.

People who want freedom and who want to own your own lives, and not some overpowering minority of arrogant fools going against constitutions of their own states, which is the case for the US and our EU US-satellite states...

I can not emphasize enough how important for the best in computing, and that is GNU/Linux, Grsecurity/Pax is!

Anyone who can, do something about it!

Debian developers, Christian Marillat can not be the sole honest developer left amongst you!

Pls., do something, Debian devs, about these vitriolisms that will ruin Debian completely if they are not curbed!

[timbgo]

I don't do things behind people's back:
http://forums.debian.net/viewtopic.php?f=5&t=105549&p=504746#p504746

Ah, this is some SHA256, just in case:
c08db3fb174ac6df9da7ca4dfd8617e03c47a6c9dd7997b54d5a90ab5941e1ee

[timbgo]

Grsecurity/Pax kernel compilation, and things Grsecurity, have actually in this thread, and with the testing grsecurity branch, been solved rather quickly.

What I have struggled with, and seem to have solved, is initramfs issues in Debian.

(I am running: 3.9.8-grsec-130706 kernel on one, and am confident will run equivalent on the other of my two Debian systems.)

So whoever needs to find solution if they run into same or similar issues as I did, the rest of the story of getting Debian testing branch with the testing branch (which may be not the latest testing branch at this time) of Grsecurity/Pax, go the the already referenced Debian Forums thread of mine, where I'll post, next, how I solved the initramfs issue that kept me with no-boot kernel 3.9.8 for a few days.
OTOH, I would like to try and contribute more here, modestly according to my means, so I'll try and keep up with the testing branche, but I can not do it just yet.
Rather, hopefully if I survive different problems in my life that all hold heavy sway and pressure on me, not the more difficult one among them being keeping up with my understanding and use of GNU/Linux... in week(s) or more time from now.
Really appreciate these great programs!