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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1259775266.4314.10.camel@maxim-laptop>
Date:	Wed, 02 Dec 2009 19:34:26 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Cc:	linux-pm <linux-pm@...ts.linux-foundation.org>
Subject: Maybe we can make no_console_suspend fine grained?

Currently, if the no_console_suspend isn't set, as soon as system begins
the suspend, at core printk level output is suppressed.

However, I want to have a simple and clean way to have all console
messages in the memory, because on my laptop memory isn't cleared on
reboots.

My first approach was just to put printk buffer at predefined address.
This wasn't favored by kernel developers, and even I myself found this
to be not such great solution.

Other approach is to create a console driver, however it won't be used
by printk ether during suspend and resume.

So, maybe we can add a flag that console should always be used,
regardless of no_console_suspend?
(This is the particular console is safe for that purpose)

I can even make the new console pm aware, thus make is possible to avoid
collisions between  every stage of the hibernation.
( Which happen today because resume kernel overwrites the printk
predefined buffer, and that is annoying because my system works just
fine now, but I want to keep that feature on)

Best regards,
Maxim Levitsky

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ