grsecurity patch failed to decipher disk encryption

[Construx]

I hope someone is listening. Well, I seem to be going from bad to really bad. First time I compiled the kernal after applying the patch, I found, when booting into the new kernel, that a couple of major programs were broken, badly. My strategy changed this time around and I compiled the kernel before I installed any major program. Although the compilation appeared to go rather well, when I then tried booting into the new kernel, it could not decipher my disk encryption, failing to recognize my passphrase. Do others have these sorts of difficulty with this patch as well?

I have no clue as to how to fix such an issue or what might have caused it. My only guess would be that one of the options made during "make menuconfig" was incompatible with my encryption, but that would just be a hunch. Can someone suggest an alternative notion or recommendation? I am using standard dmcrypt, no lvm, no truecrypt, no magic wand. Does it occur to anyone that lacking any particular one of the configuration options for the kernel would render the encryption support defunct? If not, does there seem to be a better question I ought to be asking at this point? Frankly, I don't believe that I have asked for much in the way of support, no hand-holding, no kiddie-gloves, not even any pointing out of the obvious. Am I expecting too much from the gresec team, impatiently? At this rate I would not be able to meet my self-appointed deadline for completion of this project, and I am wondering now whether I ought to consider settling for an alternative security program? That would not be my preference, to be sure.

There is nothing terribly complicated about my system, really nothing. I feel a bit frustrated, puzzled and, well, disappointed in that this procedure seems to lack a certain amount of empathy with my condition. Moreover, I do not see ANY pointers in the documentation concerning what steps I might take to progress merely to the point of having a fully functional kernel, much less how to administrate it afterwards, which is what I would expect to be the harder part of this whole process.

[GBit]

Make sure XTS support, and other encryption libraries are enabled.

It could also be that the encryption software isn't playing well with a PaX/Grsecurity feature, but I'd bet it's the above.

There is no way to document every issue, or what to do. There are a billion different hardware configurations and software configurations, each one will have specific issues with any software. I suggest you boot into a regular kernel (use the recovery in grub, assuming you can get into grub, which should be the case) and go to a default kernel. If the default kernel doesn't work, teh problem isn't grsec. If the default kernel *does* work, go ahead and make sure all of your relevant encryption is enabled (again, look for XTS) and then compile agian.

Still doesn't work? Disable features, provide your kernel config file here (via pastebin), provide any errors, and someone can work from there.

You're also apparently using 3.2.x, which isn't supported. Whatever bug you're experience may have already been fixed.

[Construx]

Gbit, no matter what you look like, smell like or dress like, I love you. You are my hero, today. Thank you for responding to me.

Now I want to talk about the points you mentioned so that I can proceed methodically. For starters, yes, I do have a Grub menu, which allows me to choose the kernel-3.2.48-grsec as well as the previous standard kernel-3.2.48. When I let the grsec kernel try to boot, it brought me to the passphrase entry point but failed to recognize my passphrase, which I entered several times correctly. Then I rebooted and tried that again, but it failed again. So, I rebooted and chose the standard unpatched kernel, which booted normally and brought me to a nice prompt.

First of all, You said, "You're also apparently using 3.2.x, which isn't supported." I am confused by this statement because when I look at this page, https://grsecurity.net/download_stable.php, it appears to be the most recent of all that is available, even updated as of 07-09-13. I see on that page this statement: "We currently maintain a stable version of the patch against the 2.6.32 and 3.2 stable trees", and I see these two download links:

https://grsecurity.net/stable/grsecurit ... 2217.patch
https://grsecurity.net/stable/grsecurit ... 2216.patch

Accordingly, when I look at those, I must be misunderstanding what I see, because they lead me to believe that I can get either of two kernels corresponding to them, namely:

linux-3.2.48 (or)
linux-2.6.32

I chose the first one, thinking there must be two current versions for some(?) reason. What am I missing?

Secondly, you said "...go ahead and make sure all of your relevant encryption is enabled (again, look for XTS) and then compile again." At which point exactly in the steps of the procedure can I start from, or do I have to start over completely? I mean to say, should I once again do this command "patch -p1 < ../grsecurity-2.9.1-3.2.48-201307050016.patch"? It would seem to me that, assuming I end up downloading a different kernel based on what you have said about my choice already, that I should remove everything I did so far and start over entirely. Is that not so?

Additionally, you want me to take extra care to be certain that I have not disabled cryptographic support when I use the menu options from "make menuconfig". So, can you please clarify whereabouts you intend for me to start and with which kernel and grsecurity patch. I will surely use the most recent one if I need to get it somewhere else. Thanks.

[GBit]

You're right, it is supported lol I got confused. Sorry about that.

In terms of finding XTS support it should go like this:

1) Download source from kernel.org

2) Download patch from grsecurity.net

3) Patch kernel with grsecurity

4) run make menuconfig

5) Ensure XTS support is enabled

alternatively you can modify the .config file manually.

If you've already done 1-3 you can just run make menuconfig and look for XTS.