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

The same behaviour is also present in RHEL 5.6 screen version screen-4.0.3-3.el5

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.

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.

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.

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().

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

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?

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

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.

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.

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.

(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?

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.

(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?)

(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.

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

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.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Due to not clearing the terminal scrollback buffer on locked screen or new login, the screen and mingetty utilities do not pass the Common Criteria certification requirements. This issue can be avoided by disabling the terminal scrollback buffer via the "no-scroll" kernel parameter.

For the evaluation, we are good with either a kernel command line addition, using vlock or the real fix you discuss here. There is no preference, you decide.

I've (re)tested this today on my workstation and agreed workaround to use no-scroll parameter does NOT seem to provide desired results. It is still possible to scrollback with Shift+PgUp. Is anyone else experiencing the same behaviour?

$ tty
/dev/tty1
$ cat /proc/cmdline 
ro root=/dev/mapper/VolGroup01-root rd_LVM_LV=VolGroup01/root rd_LVM_LV=VolGroup01/LvSwap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=129M@0M rhgb quiet no-scroll
$ uname -a
Linux dhcp-24-228.brq.redhat.com 2.6.32-114.0.1.el6.x86_64 #1 SMP Thu Feb 10 16:04:24 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

I cannot scroll back on a RHEL6.1 system using no-scroll. I also tried it without the option and I could scroll back

Seems like no-scroll is not enough, because it covers only default system vga console driver. Using just no-scroll doesn't help in my case, too.

I figured out frame buffer is used for console on my notebook. I found a solution which works for me:

"no-scroll fbcon=scrollback:0"

(In reply to comment #27)
> Seems like no-scroll is not enough, because it covers only default system vga
> console driver. Using just no-scroll doesn't help in my case, too.
> 
> I figured out frame buffer is used for console on my notebook. I found a
> solution which works for me:
> 
> "no-scroll fbcon=scrollback:0"

Good point David, I'll test it and post results hopefully today or tomorrow.

(In reply to comment #28)
> (In reply to comment #27)
> > Seems like no-scroll is not enough, because it covers only default system vga
> > console driver. Using just no-scroll doesn't help in my case, too.
> > 
> > I figured out frame buffer is used for console on my notebook. I found a
> > solution which works for me:
> > 
> > "no-scroll fbcon=scrollback:0"
> 
> Good point David, I'll test it and post results hopefully today or tomorrow.

Tested on RHEL 6.1 and it works while using both options:
  no-scroll fbcon=scrollback:0

I believe the difference was caused by use of a framebuffer console in my case while not in Stephan's testing env.

# uname -a
Linux dhcp-24-228.brq.redhat.com 2.6.32-114.0.1.el6.x86_64 #1 SMP Thu Feb 10 16:04:24 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
# cat /proc/cmdline 
ro root=/dev/mapper/VolGroup01-root rd_LVM_LV=VolGroup01/root rd_LVM_LV=VolGroup01/LvSwap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=129M@0M rhgb quiet no-scroll fbcon=scrollback:0

# dmesg
 ...
nouveau 0000:0f:00.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
nouveau 0000:0f:00.0: setting latency timer to 64
[drm] nouveau 0000:0f:00.0: Detected an NV50 generation card (0x096c00a1)
[drm] nouveau 0000:0f:00.0: Attempting to load BIOS image from PRAMIN
[drm] nouveau 0000:0f:00.0: ... appears to be valid
[drm] nouveau 0000:0f:00.0: BIT BIOS found
[drm] nouveau 0000:0f:00.0: Bios version 62.94.6e.00
[drm] nouveau 0000:0f:00.0: TMDS table version 2.0
[drm] nouveau 0000:0f:00.0: Found Display Configuration Block version 4.0
[drm] nouveau 0000:0f:00.0: Raw DCB entry 0: 02000300 00000028
[drm] nouveau 0000:0f:00.0: Raw DCB entry 1: 01000302 00020030
[drm] nouveau 0000:0f:00.0: Raw DCB entry 2: 04011310 00000028
[drm] nouveau 0000:0f:00.0: Raw DCB entry 3: 02011312 00020030
[drm] nouveau 0000:0f:00.0: DCB connector table: VHER 0x40 5 16 4
[drm] nouveau 0000:0f:00.0:   0: 0x00001030: type 0x30 idx 0 tag 0x07
[drm] nouveau 0000:0f:00.0:   1: 0x00002130: type 0x30 idx 1 tag 0x08
[drm] nouveau 0000:0f:00.0:   2: 0x00000210: type 0x10 idx 2 tag 0xff
[drm] nouveau 0000:0f:00.0:   3: 0x00000211: type 0x11 idx 3 tag 0xff
[drm] nouveau 0000:0f:00.0:   4: 0x00000213: type 0x13 idx 4 tag 0xff
[drm] nouveau 0000:0f:00.0: Parsing VBIOS init table 0 at offset 0xD7C1
[drm] nouveau 0000:0f:00.0: Parsing VBIOS init table 1 at offset 0xDC17
[drm] nouveau 0000:0f:00.0: Parsing VBIOS init table 2 at offset 0xEBE0
[drm] nouveau 0000:0f:00.0: Parsing VBIOS init table 3 at offset 0xED01
[drm] nouveau 0000:0f:00.0: Parsing VBIOS init table 4 at offset 0xF028
[drm] nouveau 0000:0f:00.0: Parsing VBIOS init table at offset 0xF08D
[drm] nouveau 0000:0f:00.0: 0xF08D: Condition still not met after 20ms, skipping following opcodes
[drm] nouveau 0000:0f:00.0: 2 available performance level(s)
[drm] nouveau 0000:0f:00.0: 0: memory 100MHz core 208MHz shader 450MHz voltage 1000mV fanspeed 100%
[drm] nouveau 0000:0f:00.0: 3: memory 700MHz core 450MHz shader 1100MHz voltage 1000mV fanspeed 100%
[drm] nouveau 0000:0f:00.0: c: memory 702MHz core 400MHz shader 800MHz voltage 1000mV
[drm] nouveau 0000:0f:00.0: Detected 256MiB VRAM
[TTM] Zone  kernel: Available graphics memory: 1952834 kiB.
[TTM] Initializing pool allocator.
[drm] nouveau 0000:0f:00.0: 512 MiB GART (aperture)
[drm] nouveau 0000:0f:00.0: Allocating FIFO number 1
[drm] nouveau 0000:0f:00.0: nouveau_channel_alloc: initialised FIFO 1
[drm] nouveau 0000:0f:00.0: allocated 1600x1200 fb: 0x40280000, bo ffff880117348800
fbcon: nouveaufb (fb0) is primary device
Console: switching to colour frame buffer device 200x75
fb0: nouveaufb frame buffer device
drm: registered panic notifier
Slow work thread pool: Starting up
Slow work thread pool: Ready
[drm] Initialized nouveau 0.0.16 20090420 for 0000:0f:00.0 on minor 0

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-Due to not clearing the terminal scrollback buffer on locked screen or new login, the screen and mingetty utilities do not pass the Common Criteria certification requirements. This issue can be avoided by disabling the terminal scrollback buffer via the "no-scroll" kernel parameter.+Due to not clearing the terminal scrollback buffer on locked screen or new login, the screen and mingetty utilities do not pass the Common Criteria certification requirements. This issue can be avoided by disabling the terminal scrollback buffer via the "no-scroll fbcon=scrollback:0" kernel parameters.

> I believe the difference was caused by use of a framebuffer console in my case
> while not in Stephan's testing env.

Right. I do not have any FB set up as my test system happens to be a KVM. Thanks for finding this issue and clarifying the solution!

I will change the kickstart script to add the command line option.

Since there is nothing to fix and we have a working solution I think we can close the bug at this point.