+++ This bug was initially created as a clone of Bug #681600 +++

Description of problem:
There is a requirement for "clearing or overwriting TSF controlled display devices, making the current contents unreadable".

Screen only clears the display up to its dimensions, but not the content above it. By scrolling up with Shift+PgUp anything above those blanked dimensions is still visible. This behaviour does not seem to be desired and this should be fixed. One option/workaround could be to use no-scroll kernel boot argument.

Version-Release number of selected component (if applicable):
screen-4.0.3-15.el6.x86_64 (rhel6.0)
screen-4.0.3-16.el6.x86_64 (rhel6.1)

How reproducible:
always

Steps to Reproduce:
1. Update /etc/profile: 
cat >> /etc/profile << EOT
####
SCREENEXEC="screen"
export SCREENDIR=$HOME/.screen
if [ -w $(tty) ] ; then
        trap "exec $SCREENEXEC" 1 2 3 15
        echo -n 'Starting session in 2 seconds'
        sleep 2
        exec $SCREENEXEC
fi
EOT
2. Log into the system at runlevel 3 as any correct user
3. Work with some super secret information, e.g.:
for i in `seq 1 100` ; do cat /etc/profile ; done
4. Lock the screen session with "Ctrl+a x"
5. "scroll up" using "Shift+PgUp"
  
Actual results:
Everything that was above dimensions of cleared display is still visible.

Expected results:
When screen session is locked no other content than password prompt is visible, to meet requirement for "clearing or overwriting TSF controlled display devices, making the current contents unreadable".

Additional info:
This is not a regression against RHEL 6.0, David is checking RHEL 5.6 now ...

--- Additional comment from dkutalek on 2011-03-02 12:33:04 EST ---

I can confirm that this issue is present also on RHEL 5.4 with screen-4.0.3-1.el5.

Scrolling which causes problems is not a screen specific scrolling, but kernel virtual terminal based one. Which eg. means, another "workaround" is to switch to another virtual terminal and back always after locking. Yes, that is not a real workaround :-).

So, disabling kernel based scrolling by using no-scroll as kernel boot param should work. But user have to make sure that this param is present eg. after kernel update, so not nice.

I believe it is possible for userland program to clear complete text buffer by using appropriate ioctl. Eg. resizing terminal size to smaller and back using stty does clear all buffer. 

Another possibility could be detecting kernel scrolling buffer size and writing out enough of blank lines.

It is also possible to check what kind of terminal is screen running on, so we won't mess things on other terminals like xterm.

See this link for some info about virtual terminal scrolling done by kernel:
http://www.faqs.org/docs/Linux-HOWTO/Keyboard-and-Console-HOWTO.html#s18

--- Additional comment from mlichvar on 2011-03-03 07:40:09 EST ---

Unfortunately "tput reset" doesn't seem to work on linux console, I think that would be the nicest approach.

The other options to clear the scrollback buffer:
- switching to another console and back
  what if only one console is configured?

- set number of rows (TIOCSWINSZ) to one less and back
  couldn't this make kernel change the screen resolution and thus flicker?

- fill the buffer with blank lines
  is there a maximum buffer size or does this depend on the hardware?

Any other options?

Also, mingetty seems to have the same problem.

--- Additional comment from ppisar on 2011-03-03 10:30:56 EST ---

Number of lines depends on video memory size and number of allocated consoles (if not using software scrolling). Because loosing scroll-back buffer on terminal size change is intended behavior, I guess Linux can clear the buffer. The only missing thing is appropriate IOCTL.

Which IOCTL / control sequence causes xterm to lose buffer? Can it be reused in Linux virtual console implementation?

There is SUID tool `vlock' that can block VT switching. Maybe it's possible to block VT scrolling too.

--- Additional comment from mlichvar on 2011-03-03 10:49:33 EST ---

xterm and other terminal emulators reset the scrollback buffer on the reset control sequence (\Ec, named rs1 in terminfo).

It would be very nice if kernel reset the buffer on this sequence too.

--- Additional comment from ppisar on 2011-03-03 12:12:58 EST ---

According drivers/char/vt.c, the reset_terminal() re-sets everything (including loaded font, UTF mode, LED state, visible area) except scroll buffer.

The \Ec is dispatched by calling reset_terminal(vc, 1) in do_con_trol(). The last argument says to clear display and calls csi_J(vc, 2). csi_J() can erase from cursor to the end (value 0), from start of visible area to the cursor (value 1), and whole visible area (our value 2).

I can try to implement value 3 to squash not only visible area (vc_origin pointer), but scroll buffer (vc_screenbuf) too.

VT resize (vc_do_resize()) checks if new and old size differs (did you know you cannot have more then 2^15 columns or lines in a terminal :) and then allocates new memory, copies area around cursor, and puts the new memory region (that contains all zeros and copied area) into video memory. This is not done in reset_terminal().

--- Additional comment from mlichvar on 2011-03-04 10:00:51 EST ---

Hm, I don't think an application like screen should be resetting utf8 mode, numlock or font on console.

--- Additional comment from mlichvar on 2011-03-04 10:56:23 EST ---

Another option is to use an external lock program like vlock in a script which resets the scrolling buffer by means suitable in that particular configuration.
When the LOCKPRG environment variable is set, screen will run this program instead of the internal screenlock.

For example:

#!/bin/sh

case `tty` in
        /dev/tty[0-9]*)
                vt=`/usr/bin/fgconsole`
                /usr/bin/chvt 63 &> /dev/null
                /usr/bin/chvt $vt &> /dev/null
                ;;
esac

exec /usr/bin/vlock


Would this be an acceptable solution to include it in the CC configuration?

--- Additional comment from dkutalek on 2011-03-04 11:15:21 EST ---

One more question is, whether is screen lockscreen function supposed to 
1) clear only content created since screen was started (actual behaviour), or
2) whole terminal content. 

Do someone know what is actually specified and required, whether 1) or 2)? Personally, I would prefer 2) - wouldn't implementing it upset users and upstream?

But anyway, even in case 1), there is problem not only in vt, but also in gnome-terminal, while eg. in xterm it is ok. I would say that the difference is whether screen usage makes terminal scroll or not. It shouldn't, screen as a whole should be working on exactly same number of lines as are visible lines.

So to fix 1), perhaps some termcap/terminfo tweaking is enough?

Btw, regarding \Ec:
 - does screen uses \Ec at all somewhere? I cannot find its usage in sources
 - \Ec outside screen in xterm/gnome-terminal clears its scrollback, while in screen it clears only screen scrollback. Well, not in gnome-terminal, only in xterm :-o

--- Additional comment from mlichvar on 2011-03-04 11:44:10 EST ---

screen doesn't use \Ec. As it turned out it would reset numlock, utf8 mode, etc. on linux console.

The difference between xterm and gnome-terminal is that in the alternate screen (entered by smcup sequence) xterm doesn't scroll lines into the scrollback buffer.

The best option still seems to be the kernel boot parameter disabling scrolling, this would fix the problem with mingetty too.

--- Additional comment from ppisar on 2011-03-07 04:47:11 EST ---

There is \E[n;J sequence to erase terminal. The `n' can be 0 (erase from cursor to the end of terminal), 1 (from start to cursor), or 2 (whole terminal). The only problem is it erases visible area only. We could implement modifier 3 or change modifier 2 to erase scroll-back buffer too.

HP terminals support \El to `lock memory above the cursor' and \Em to unlock the memory. I have no clue what does it mean. It's not implemented by Linux virtual console, nor by xterm. I guess it forbids writing data before cursor. We could reuse it as switch to disable/enable scrolling back. However user can send the unlock sequence to the terminal while typing the password, so it's not good idea.

(Also screen running as different user has a problem: The PTY device remains in original user ownership, this he could manipulate the terminal just by accessing appropriate device i-node.)

I think the most clean solution is to add a sequence to discard buffers and implemented it in all supported terminal emulators. I can ask Thomas Dickey, xterm developer, for some hints. I believe such a feature must be already implemented in some army/intelligence equipments and we just don't know about it.

--- Additional comment from dickey on 2011-03-07 19:34:51 EST ---

Changing the behavior of an existing feature such as \E[2J would
annoy more users than adding a new feature such as \E[3J.

Erasing the display + scrollback (don't forget the alternate
screen) seems to be the only reliable way to prevent the user
from seeing what was there before the vlock starts.

--- Additional comment from rvokal on 2011-03-09 03:05:25 EST ---

(In reply to comment #14)
> Changing the behavior of an existing feature such as \E[2J would
> annoy more users than adding a new feature such as \E[3J.
> 
> Erasing the display + scrollback (don't forget the alternate
> screen) seems to be the only reliable way to prevent the user
> from seeing what was there before the vlock starts.

Sounds to me that the solution proposed in comment #12, eg. disabling scrolling by passing a kernel parameter is the best option. Do we have an agreement here?

--- Additional comment from mlichvar on 2011-03-09 03:25:41 EST ---

If we decide to add support for the new \E[3J sequence in kernel, there are two options how to use it. Either hardcode it in screen (and mingetty) or its configuration, or change the clear sequence in the linux terminfo entry in the ncurses package which will affect all applications including bash.

--- Additional comment from ppisar on 2011-03-09 03:34:35 EST ---

(In reply to comment #15)
> Sounds to me that the solution proposed in comment #12, eg. disabling scrolling
> by passing a kernel parameter is the best option. Do we have an agreement here?

It would work around Linux VT only. User would lost scroll-back capability. I  consider it as quick hack. Not a permanent solution.

Also it would not solve other terminal emulators (xterm, gnome-terminal etc.). (Does minicom have it's own buffer?)

--- Additional comment from ppisar on 2011-03-09 03:42:39 EST ---

(In reply to comment #16)
> If we decide to add support for the new \E[3J sequence in kernel, there are two
> options how to use it. Either hardcode it in screen (and mingetty) or its
> configuration, or change the clear sequence in the linux terminfo entry in the
> ncurses package which will affect all applications including bash.

Changing termininfo record for clear-screen is as bad as changing implementation of \E[2;J in all terminals.

I would like to see \E3;J in all terminals and new terminfo entry for safe-clear-screen. Then applications can request safe-clear-screen command explicitly when they need it. That means adding it into *getty, screen, and other applications willing to perform safe clear.

--- Additional comment from dkutalek on 2011-03-09 04:04:32 EST ---

(In reply to comment #15)
> (In reply to comment #14)
> > Changing the behavior of an existing feature such as \E[2J would
> > annoy more users than adding a new feature such as \E[3J.
> > 
> > Erasing the display + scrollback (don't forget the alternate
> > screen) seems to be the only reliable way to prevent the user
> > from seeing what was there before the vlock starts.
> 
> Sounds to me that the solution proposed in comment #12, eg. disabling scrolling
> by passing a kernel parameter is the best option. Do we have an agreement here?

I would like to point out that this bug was reported because of Common Criteria requirement for "clearing or overwriting TSF controlled display devices, making the current contents unreadable". This has to be fulfilled for 6.1 to be CC certified.

Because RHEL6 is going to be certified to CC without X, no-scroll as a quick-hack should fulfil this requirement.

Otherwise, I would be happy to see implemented safe-clear-screen as described by Petr in comment 18. Not sure whether we are able to have it done for RHEL6.1 though.

Radek, perhaps we can split this bug: one for fulfilling CC reqs in 6.1 and another for well-done implementation of safe-clear-screen?

David

--- Additional comment from sgrubb on 2011-03-09 09:22:23 EST ---

If it helps, the common criteria certification is only concerned with run level 3. A more general solution can be worked out in Fedora.

--- Additional comment from tmraz on 2011-03-09 09:59:03 EST ---

Note that when you connect from the Linux console login with screen running to another certified machine (perhaps a KVM guest on this machine) you can scroll back within the screen on the console login with the Ctrl-a Esc key sequence. I am not sure whether it is a critical problem as the contents of this scrollback buffer will be protected by the lock in this console screen instance. Of course there might be discrepance between the timeouts set on the machines.

Other than this the 'no-scroll' boot option seems to me like the best solution for the problem for the certification. Of course in the future it would be nice if there was any way how to signal the client that it should clear also its scrollback buffers. However it would be always possible that the various terminal clients ignore the command.