linux-kernel - Re: linux-next: parsing mem=700M broken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Dec 2008 15:09:12 -0800
From:	"Yinghai Lu" <yinghai@...nel.org>
To:	"Rusty Russell" <rusty@...tcorp.com.au>
Cc:	"Ingo Molnar" <mingo@...e.hu>, "Hugh Dickins" <hugh@...itas.com>,
	"Stephen Rothwell" <sfr@...b.auug.org.au>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: linux-next: parsing mem=700M broken

On Wed, Dec 24, 2008 at 12:09 AM, Yinghai Lu <yinghai@...nel.org> wrote:
> Rusty Russell wrote:
>> On Wednesday 24 December 2008 01:03:27 Ingo Molnar wrote:
>>> * Yinghai Lu <yinghai@...nel.org> wrote:
>>>
>>>> On Mon, Dec 22, 2008 at 7:06 PM, Hugh Dickins <hugh@...itas.com> wrote:
>>>>> Hi Rusty,
>>>>>
>>>>> I find that bootparam "mem=700M" isn't working in linux-next or mmotm,
>>>>> and have bisected it down to your patch below; but now I'm off to bed
>>>>> without working out just what goes wrong (I'll bet it's the "=").
>>
>> Thanks for the report and analysis.
>>
>>> Rusty, will you fix or revert it?
>>
>> mem= is actually easy, memmap= is harder.  This is tested and pushed.
>>
>> This commit is actually orthogonal to the other changes, but makes most
>> sense I think in the bootparam tree.
>>
>> commit b69cab1078c69a568afdd2eb8ee6f8559b769e2c
>> Author: Rusty Russell <rusty@...tcorp.com.au>
>> Date:   Wed Dec 24 18:04:19 2008 +1030
>>
>>     Fix mem= and memmap= parsing: now it happens *before* e820 setup.
>>
>>     Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>
>>
>
> for cpu caps on boot cpu setup still need
>
> could be in tip your tree.
>
> ---
>
> [PATCH] x86: clean up setup_clear/force_cpu_cap handling
>
> Impact: fix and cleanup
>
> setup_force_cpu_cap() only have one user xen
> but it should not reuse cleared_cpu_cpus. it will have problem
> for smp.
>
> need to have cpu_cpus_set array too.
> also need to setup handling before all cpus cap AND
>
> Signed-off-by: Yinghai Lu <yinghai.lu@...nel.org>
>
> ---
> ---
> could be put in next:
>
> [PATCH] x86: update boot_cpu x86 cap according in early_identify_cpu
>
> Impact: fix
>
> early_param is moved more earlier. So need to update boot_cpu_data x86 cap
> in early_identify_cpu() to make sure that is right.
>
> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>
> ---
>  arch/x86/kernel/cpu/common.c |   10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> Index: linux-2.6/arch/x86/kernel/cpu/common.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/cpu/common.c
> +++ linux-2.6/arch/x86/kernel/cpu/common.c
> @@ -552,6 +552,16 @@ static void __init early_identify_cpu(st
>        if (this_cpu->c_early_init)
>                this_cpu->c_early_init(c);
>
> +       /*
> +        * Clear/Set all flags overriden by options, need do it
> +        * because early_param is done before early_cpu_init now.
> +        * We can get boot_cpu_data.x86_capability right.
> +        */
> +       for (i = 0; i < NCAPINTS; i++) {
> +               c->x86_capability[i] &= ~cpu_caps_cleared[i];
> +               c->x86_capability[i] |= cpu_caps_set[i];
> +       }
> +
>        validate_pat_support(c);
>
>  #ifdef CONFIG_SMP
> --

...


also

/*
 * noexec = on|off
 *
 * Control non executable mappings.
 *
 * on      Enable
 * off     Disable
 */
static int __init noexec_setup(char *str)
{
        if (!str || !strcmp(str, "on")) {
                if (cpu_has_nx) {
                        __supported_pte_mask |= _PAGE_NX;
                        disable_nx = 0;
                }
        } else {
                if (!strcmp(str, "off")) {
                        disable_nx = 1;
                        __supported_pte_mask &= ~_PAGE_NX;
                } else {
                        return -EINVAL;
                }
        }

        return 0;
}
early_param("noexec", noexec_setup);


they are using cpu_has_nx already.

wonder if just move early_cpu_init() and before in setup_arch() to
x86_start_kernel/x86_64_start_kernel
directly.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/