RE: [PATCH v2] MIPS: Add nonxstack=on|off kernel parameter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Miodrag,

> When kernel is detecting the type of mapping it should apply :
> 
> fs/binfmt_elf.c:
> ...
> 	if (elf_read_implies_exec(loc->elf_ex, executable_stack))
> 		current->personality |= READ_IMPLIES_EXEC;
> ...
> 
> this effectively calls mips_elf_read_implies_exec() which performs a check:
> ...
> 	if (!cpu_has_rixi) {
> 		/* The CPU doesn't support non-executable memory */
> 		return 1;
> 	}
> 
> 	return 0;
> }
> 
> This will in turn make stack & heap executable on processors without 
> RIXI, which are practically all processors with MIPS ISA R < 6.
> 
> We would like to have an option to override this and force 
> non-executable mappings for such systems.

 Of course you can't force a non-executable mapping with a system where 
all valid pages are executable, as David has already noted.  Did you mean 
the other condition, that is:

	if (exstack != EXSTACK_DISABLE_X) {
		/* The binary doesn't request a non-executable stack */
		return 1;
	}

?  In which case you do want to respect the lack of the RIXI feature, 
i.e.:

int mips_elf_read_implies_exec(void *elf_ex, int exstack)
{
	if (!cpu_has_rixi) {
		/* The CPU doesn't support non-executable memory */
		return 1;
        }

	switch (nonxstack) {
	case EXSTACK_DISABLE_X:
		return 0;
	case EXSTACK_ENABLE_X:
		return 1;
	default:
		break;
	}

	if (exstack != EXSTACK_DISABLE_X) {
		/* The binary doesn't request a non-executable stack */
		return 1;
	}

	return 0;
}

(I'd replace `break' with `return exstack != EXSTACK_DISABLE_X' and 
discard the code that follows, but that can be a separate optimisation).

 What problem are you trying to solve anyway?  Is it not something that 
can be handled with the `execstack' utility?

 NB as someone has observed with programs that do not request a 
non-executable stack we actually propagate the execute permission to all 
data pages.  Is it not something we would want to handle differently?

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux