From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <54FFF842.1010504@suse.cz> Date: Wed, 11 Mar 2015 09:09:38 +0100 From: Jiri Slaby MIME-Version: 1.0 To: One Thousand Gnomes CC: Raymond Jennings , gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, john_paul.perry@alcatel-lucent.com, stable@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH 1/1] tty: fix up atime/mtime mess, take four References: <1425058831-13923-1-git-send-email-jslaby@suse.cz> <1425647774.14441.1.camel@avalar.dragonrealms> <54FD6F68.2010708@suse.cz> <20150310224100.48b1adf6@lxorguk.ukuu.org.uk> In-Reply-To: <20150310224100.48b1adf6@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: On 03/10/2015, 11:41 PM, One Thousand Gnomes wrote: > On Mon, 09 Mar 2015 11:01:12 +0100 > Jiri Slaby wrote: > >> On 03/06/2015, 02:16 PM, Raymond Jennings wrote: >>> On Fri, 2015-02-27 at 18:40 +0100, Jiri Slaby wrote: >>>> So check the absolute difference of times and if it large than "8 >>>> seconds or so", always update the time. That means we will update >>>> immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the >>>> check, but it was always that way. >>> >>> If I may ask, what is supposed to happen normally when you write to a >>> tty device? I always thought the tty device was treated just like a >>> normal file wrt. timestamps. >>> >>> Now I see a patch for 8 seconds something. >> >> Yes, because you do not want to be given any clue when users are typing >> passwords. You could intercept the length of the password from the >> pauses between key strokes (tty timestamps). > > On any vaguely idle box I can do the same and in fact probably far > better by measuring latencies via rdtsc and continually forcing a dword > out of cache in a tight loop. I don't know, I have to study and try this first, before I can take any action. > It's a pointless change, second granularities are not useful for most > kinds of attack of this nature. Yes, that was actually the whole point of the exercise: move from current_fs_time() (one nanosecond granularity (for devtmpfs)) to get_seconds() & 7 (8 seconds). thanks, -- js suse labs