grsecurity forums

Seems PHYSICAL_START is clamped to 0x1000000, which is causing some problems with Linodes that have the 1GB memory upgrade. Currently, only 512MB ram works.

The suggested fix is:
PHYSICAL_START=0x100000
PHYSICAL_ALIGN=0x100000

however, enabling this isn't possible due to grsecurity/pax. Any workarounds?

in arch/x86/Kconfig:

Code: Select all

config PHYSICAL_START
        default "0x1000000"
        range 0x400000 0x40000000


so it's a range between 4MB-1GB already. this was originially done for the i386 kernel which has to be in the direct mapped memory which is usually <1GB but it can certainly be made more fine grained. what i don't understand is why having 1GB memory causes problems with the current settings, can you elaborate? as for PHYSICAL_ALIGN, it has to be restricted when KERNEXEC is enabled (this too could be more refined in that under PAE a lower limit of 2MB is also possible, not just 4MB).

[quote="PaX Team"]in arch/x86/Kconfig:[code]config PHYSICAL_START
default "0x1000000"
range 0x400000 0x40000000
[/code]
so it's a range between 4MB-1GB already. this was originially done for the i386 kernel which has to be in the direct mapped memory which is usually <1GB but it can certainly be made more fine grained. what i don't understand is why having 1GB memory causes problems with the current settings, can you elaborate? as for PHYSICAL_ALIGN, it has to be restricted when KERNEXEC is enabled (this too could be more refined in that under PAE a lower limit of 2MB is also possible, not just 4MB).[/quote]

From what I gather (and I may be wrong here but using the information provided by me via support @ Linode), my Linode (and others apparently using the PAX-enabled kernels) have issues when the kernel is used on Xen with a VM that has more than 1000 MB of ram.

Map 2048 (<address>) at 0x418020000 failed: -22
Do exit called!

Only seems to be an issue when used allocating > 512MB memory. The suggested fix by support over there was to change the START and ALIGN values.

I'd like to throw in on this too, as I'm having the same issue.

Linode just upgraded all users to the next level of RAM. Basically they doubled everyone's RAM for free. What this means is that my 512 Linode has now become a 1024 Linode, and no longer boots. I was told the same thing by support, which is to modify CONFIG_PHYSICAL_[ALIGN|START] to be 0x100000 instead of 0x1000000. The problem is that GRSEC/PAX has hard coded them to 0x1000000, which prevents the kernel from booting. Someone else gave me this patch and said it was working for them, but I don't know the long-term consequences of using such a patch, so I thought I would share it first and ask for proper feedback and a solution.

sigh, this is getting out of hand . let's see what i understood so far and what the remaining issues are:

1. linode uses xen and i386 domU kernels.
2. until the RAM upgrade (as in, memory assigned to domU) the existing PaX config that sets the default values of PHYSICAL_START/ALIGN to 16MB worked fine.
3. after the upgrade to 1GB things suddenly began to fall apart (unspecified boot problem).
4. changing the above options to 1MB gets the kernel to boot again.

is this correct so far?

now my concerns:

1. if the 16MB start/alignment value worked before, i don't see how that can be the cause for the boot problem when the domU memory got increased. the kernel's placement in memory plays (or should play) no role in how much memory it'll handle later.
2. for this reason i believe that the suggested 1MB value is papering over the real problem.
3. the suggested patch is partly pointless since the PHYSICAL_ALIGN change only removes a KERNEXEC dependency that cannot be enabled together with Xen anyway. in other words, you can change the default 16MB without removing that line.
4. the PHYSICAL_START config option could be made more refined, but before i do so i'd like to learn the root cause of this problem (this in turn would determine whether i should relax the start dependency based on Xen or some other option instead).

1. if the 16MB start/alignment value worked before, i don't see how that can be the cause for the boot problem when the domU memory got increased. the kernel's placement in memory plays (or should play) no role in how much memory it'll handle later.
2. for this reason i believe that the suggested 1MB value is papering over the real problem.
3. the suggested patch is partly pointless since the PHYSICAL_ALIGN change only removes a KERNEXEC dependency that cannot be enabled together with Xen anyway. in other words, you can change the default 16MB without removing that line.
4. the PHYSICAL_START config option could be made more refined, but before i do so i'd like to learn the root cause of this problem (this in turn would determine whether i should relax the start dependency based on Xen or some other option instead).

1. I do not know what the previous start/align was. I don't believe it was specified in my previous configs, I think it was what ever the default kernel option was. Previously I was running GRSEC on 2.6.32, currently I tested on 3.2 which had the same issues.
2. I do not know enough to say
3. The patch does allow me to boot a 3.2.42 kernel with GRSEC. The portion that is incorrect may be useless, but some part of it is fixing the issue.
4. What do you need to know to assist with this?

in the end i reworked the ALIGN/START config bits in PaX, so the current patches should let you specify a 1MB start address if KERNEXEC is disabled.

PaX Team wrote:in the end i reworked the ALIGN/START config bits in PaX, so the current patches should let you specify a 1MB start address if KERNEXEC is disabled.

So the current stable patches should have this applied? Also I see you guys updated from 3.2.42 to 3.2.43 for the latest stable. Guess I'll just do a full rebuild on .43

mauvehead wrote:

PaX Team wrote:in the end i reworked the ALIGN/START config bits in PaX, so the current patches should let you specify a 1MB start address if KERNEXEC is disabled.

So the current stable patches should have this applied? Also I see you guys updated from 3.2.42 to 3.2.43 for the latest stable. Guess I'll just do a full rebuild on .43

Not sure if the latest is patched like you said, I tried the 4/14 3.2.43 and it won't take 0x100000 as a config_physical_start value. So I'm assuming the stable patch from 4/14 doesn't have it yet.

it wasn't backported to 3.2 yet, only 3.8 has this.

Gotcha. 3.8 is still beta, right? How far from stable is it? Should I just upgrade to 3.8 anyways or am I running too high of risk on "beta"?