linux-kernel - RE: [PATCH] x86: add a new SMP bring up way for tboot case

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, 15 May 2013 07:44:59 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Ren, Qiaowei" <qiaowei.ren@...el.com>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tboot-devel@...ts.sourceforge.net" 
	<tboot-devel@...ts.sourceforge.net>,
	"Wei, Gang" <gang.wei@...el.com>
Subject: RE: [PATCH] x86: add a new SMP bring up way for tboot case

No, this does not really answer the question of what the CPU state looks like.

"Ren, Qiaowei" <qiaowei.ren@...el.com> wrote:

>On 2013-05-14, H. Peter Anvin wrote:
>> On 05/14/2013 02:21 PM, Qiaowei Ren wrote:
>>> tboot provides a better AP wakeup mechanism based on cpu MWAIT
>>> feature for OS/VMM. With this mechanism, system will boot faster and
>>> will NOT require VT to be enabled. But it requires that OS/VMM must
>>> have support it, otherwise system can never boot up.
>>> 
>>> Once this mechanism is enabled, tboot will put APs waiting in MWAIT
>>> loops before launching kernel. kernel can check the new flag field
>>> in
>>> v6 tboot shared page for the hint. If the bit
>>> TB_FLAG_AP_WAKE_SUPPORT in flag field is set, kernel BSP has to
>>> write the monitored memory
>>> (tboot->ap_wake_trigger) to bring APs out of MWAIT loops. The sipi
>>> vector should be written in
>>> tboot->ap_wake_addr before waking up APs.
>>> 
>> 
>> This really needs a *detailed* specification about the state the CPU
>is parked in.
>> Most BIOSes do in fact park the CPUs in an mwait loop, but we can't
>> use it because the CPU state they are parked in is ill-defined.
>> 
>> This is a good idea, but please write (or point to) a spec about what
>> the parked CPU state looks like and how the OS gets control.  From
>the
>> *looks* of the code I assume it is entered in 16-bit real mode but
>> then it is important to know what parts of the register state are
>well-defined.
>
>The following is how to do mwait for tboot & kernel:
>
>For bootstrap processor (BSP), "tboot TXT pre-launch" is executed after
>BIOS. In this stage, tboot will issue GETSEC[SENTER], which broadcasts
>messages to the chipset and other physical or logical processors in the
>platform. In response, other logical processors perform basic cleanup
>and other tasks, and then finally enter SENTER sleep state.
>
>Next, for BSP, SINIT will run and then enter "tboot post-launch", which
>will start all sleeping APs. If tboot command line option "
>ap_wake_mwait=true" is set, APs will do some work and then enter mwait
>loop. Kernel will be launched in BSP by tboot post-launch, and bring
>APs out of mwait loop.
>
>Tboot works in protected mode (but paging is disabled), and closes
>interrupt. For APs, MONITOR and MWAIT related code in tboot is as
>follows:
>    while ( _tboot_shared.ap_wake_trigger != cpuid ) {
>        cpu_monitor(&_tboot_shared.ap_wake_trigger, 0, 0);
>        mb();
>        if ( _tboot_shared.ap_wake_trigger == cpuid )
>            break;
>        cpu_mwait(0, 0);
>    }
>Their extension and hint are all 0. According Intel manual:
>	Extension=0: Treat interrupts as break events even if masked (e.g.,
>even if EFLAGS.IF=0).
>	Hint=0: the preferred optimized state the processor should enter is
>C0.
>So, when "tboot->ap_wake_trigger" is set by kernel, APs can exit from
>mwait loop.
>
>Peter, I don't know whether I explain your problem. What do you think
>about it?
>
>Thanks,
>Qiaowei

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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/