linux-kernel - Re: [RFC] [PATCH 10/16] x86

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:	Mon, 13 Nov 2006 12:57:02 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	vgoyal@...ibm.com
Cc:	Andi Kleen <ak@...e.de>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Reloc Kernel List <fastboot@...ts.osdl.org>, akpm@...l.org,
	hpa@...or.com, magnus.damm@...il.com, lwang@...hat.com,
	dzickus@...hat.com, pavel@...e.cz,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [RFC] [PATCH 10/16] x86_64: 64bit PIC ACPI wakeup

Vivek Goyal <vgoyal@...ibm.com> writes:

> On Mon, Nov 13, 2006 at 12:21:05PM -0700, Eric W. Biederman wrote:
>> Andi Kleen <ak@...e.de> writes:
>> 
>> >> This code (verify_cpu) is called while we are still in real mode. So it has
>> >> to be present in low 1MB. Now in trampoline has been designed to switch to
>> >> 64bit mode and then jump to the kernel hence kernel can be loaded anywhere
>> >> even beyond (4G). So if we move this code into say
> arch/x86_64/kernel/head.S
>> >> then we can't even call it.
>> >
>> > I didn't mean to call it. Just #include it from a common file
>> 
>> I believe the duplication winds up happening in setup.S
>> 
>
> Yes. So boot cpu code in setup.S is also doing these checks. So one 
> of the options is that I create a new file says verify_cpu.S and this
> code can be shared by setup.S, trampoline.S and wakeup.S.
>
> Or, I can simply drop the verify_cpu bit from trampoline.S and wakeup.S.
> This looks like a non-essential bit and in the past we did not perform
> these checks in trampoline.S and wakeup.S

We do it head.S instead.  Although the version in head.S is less
complete.

> At this point of time, I will prefer to go with second option of dropping
> extended checks in trampoline.S and wakeup.S to keep things simple.
>
> Does that make sense?

I think just making an arch/x86_64/kernel/verify_cpu.S that can
be included from setup.S wakeup.S and trampoline.S will be just
an exercise in code motion.  It provides a good sanity check in
case things are hideously wrong.

If we are looking at more then code motion then it make sense to
reevaluate and probably drop the code.

Deduping this code path makes a lot of sense.

Eric


-
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/