linux-kernel - Re: invalidate caches before going into suspend

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, 13 Aug 2008 19:01:33 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Mark Langsdorf <mark.langsdorf@....com>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: invalidate caches before going into suspend


* H. Peter Anvin <hpa@...or.com> wrote:

> Ingo Molnar wrote:
>>
>> also, we might be safer if the wbinvd(), the CLI and the halt was in a  
>> single assembly sequence:
>>
>> 	if (cpu >= i486)
>> 		asm ("cli; wbinvd; cli; 1: hlt; jmp 1b")
>> 	else
>> 		asm ("cli; 1: hlt; jmp 1b")
>>
>> to make sure the compiler doesnt ever insert something into this  
>> codepath? [ And note the double cli which would be further  
>> robustification - in theory we could get a spurious interrupt straight  
>> after the wbinvd. ] Hm?
>>
>
> Spurious interrupt of what kind?  The only things that could come in 
> would not be non-INT type interrupts, and those aren't affected by 
> CLI.

nothing should come in really at that point - but say IRQ#7 on older 
platforms used to trigger at various points in time, even unprompted. Or 
an APIC error interrupt in the last moment? All device irqs should 
indeed be turned off at this stage, but since it costs us nothing to add 
another cli, and because the failure mode is subtle memory corruption, 
does it hurt to have it?

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