linux-kernel - Re: Regression in suspend to ram in 2.6.31-rc kernels

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:	Fri, 18 Sep 2009 20:15:17 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Chris Ball <cjb@...top.org>,
	Zdenek Kabelac <zdenek.kabelac@...il.com>,
	Pavel Machek <pavel@....cz>, Christoph Hellwig <hch@....de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-mmc@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: Regression in suspend to ram in 2.6.31-rc kernels

"Rafael J. Wysocki" <rjw@...k.pl> writes:

> On Saturday 12 September 2009, Chris Ball wrote:
>> Hi,
>> 
>>    > Well system could check basic card ids if they match after resume
>> 
>> No.  That (arguably) guarantees that it's the same card, but not that
>> it wasn't modified in another machine during the suspend.
>
> Generally speaking, we'd also need to check superblocks for this to work.
>  
>>    > if some users wants to crash his card by randomly swapping it
>>    > during suspend/resume - I'd have no problem with that....
>> 
>> You should have a problem with it.  Taking a card from a suspended
>> machine and working on it with a different machine is not a bizarre
>> thing to want to do.
>
> Agreed.

Um...

What happen if we moved remove event to resume sequence?  I.e. The
resume generates remove and insert event (or such revalidate).  With
this, I hope the suspend is not bothered by complex one, and the resume
just ignores (if needed) previous state and notify it to userland by
remove/insert event.

And, userland process should unmount for removal devices before suspend
process (as part of userland preparation)?

If we assumed the removable device can be changed before resume, fs
would need to recover process, to make sure in-core and on-disk state
has consistent.

Um..., for now, I feel the umount before suspend is only safe way.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
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/