linux-kernel - Re: [PATCH] Fix emergency_restart (sysrq-b) with kvm loaded on Intel hosts

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]

Message-ID: <48B27AFE.3080704@qumranet.com>
Date:	Mon, 25 Aug 2008 12:27:26 +0300
From:	Avi Kivity <avi@...ranet.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] Fix emergency_restart (sysrq-b) with kvm loaded on	Intel
 hosts

Ingo Molnar wrote:
> * Avi Kivity <avi@...ranet.com> wrote:
>
>   
>> Enabling Intel VT has the curious side effect whereby the INIT signal 
>> is blocked.  Rather than comment on the wisdom of this side effect, 
>> this patch adds an emergency restart reboot notifier, and modifies the 
>> kvm reboot notifier to disable VT on emergency reboot.
>>     
>
> looks good to me - i was bitten by that problem on a testbox.
>   

I'm a little worried about making emergency restart more complex.

Another thing that worries me is that emergency_restart() doesn't reset 
the box -- it sends INIT.  We could do better by using the ACPI FADT 
reset register (hopefully that's connected to RESET).

The ACPI spec says:

> 4.7.3.6 Reset Register
>
> The optional ACPI reset mechanism specifies a standard mechanism that 
> provides a complete system reset.
> When implemented, this mechanism must reset the entire system. This 
> includes processors, core logic, all
> buses, and all peripherals. From an OSPM perspective, asserting the 
> reset mechanism is the logical
> equivalent to power cycling the machine. Upon gaining control after a 
> reset, OSPM will perform actions in
> like manner to a cold boot.
> The reset mechanism is implemented via an 8-bit register described by 
> RESET_REG in the FADT (always
> accessed via the natural alignment and size described in RESET_REG). 
> To reset the machine, software will
> write a value (indicated in RESET_VALUE in FADT) to the reset 
> register. The RESET_REG field in the
> FADT indicates the location of the reset register.
> The reset register may exist only in I/O space, Memory space, or in 
> PCI Configuration space on a function
> in bus 0. Therefore, the Address_Space_ID value in RESET_REG must be 
> set to I/O space, Memory space,
> or PCI Configuration space (with a bus number of 0). As the register 
> is only 8 bits, Register_Bit_Width
> must be 8 and Register_Bit_Offset must be 0.
> The system must reset immediately following the write to this 
> register. OSPM assumes that the processor
> will not execute beyond the write instruction. OSPM should execute 
> spin loops on the CPUs in the system
> following a write to this register.

Which seems to be what we want? Maybe we should just try acpi_reboot() 
before the other stuff.

>   Acked-by: Ingo Molnar <mingo@...e.hu>
>
> Seems best to merge this via the KVM tree, right?
>
>   

I'm happy to do that, if everyone feels the patch is fine.

-- 
error compiling committee.c: too many arguments to function

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