This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 681600

Summary: Content above dimensions of cleared display is still visible for locked screen session
Product: Red Hat Enterprise Linux 6 Reporter: Eduard Benes <ebenes>
Component: DocumentationAssignee: Ryan Lerch <rlerch>
Status: CLOSED NOTABUG QA Contact: ecs-bugs
Severity: medium Docs Contact:
Priority: high    
Version: 6.0CC: dickey, dkutalek, ovasik, ppisar, rvokal, sgrubb, smueller, tmraz
Target Milestone: rcKeywords: Documentation
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
: 683733 (view as bug list) Environment:
Last Closed: 2011-03-24 11:53:35 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 584498, 846801, 846802    

Description Eduard Benes 2011-03-02 12:16:11 EST
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 ...
Comment 1 David Kutálek 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
Comment 2 Eduard Benes 2011-03-02 12:36:18 EST
The same behaviour is also present in RHEL 5.6 screen version screen-4.0.3-3.el5
Comment 5 Miroslav Lichvar 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.
Comment 6 Petr Pisar 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.
Comment 7 Miroslav Lichvar 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.
Comment 8 Petr Pisar 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().
Comment 9 Miroslav Lichvar 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.
Comment 10 Miroslav Lichvar 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?
Comment 11 David Kutálek 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
Comment 12 Miroslav Lichvar 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.
Comment 13 Petr Pisar 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.
Comment 14 Thomas E. Dickey 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.
Comment 15 Radek Vokal 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?
Comment 16 Miroslav Lichvar 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.
Comment 17 Petr Pisar 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?)
Comment 18 Petr Pisar 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.
Comment 20 Steve Grubb 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.
Comment 21 Tomas Mraz 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.
Comment 23 Miroslav Lichvar 2011-03-10 03:50:32 EST
    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.
Comment 24 Stephan Mueller 2011-03-10 11:34:20 EST
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.
Comment 25 Eduard Benes 2011-03-17 05:35:31 EDT
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
Comment 26 Stephan Mueller 2011-03-17 06:19:57 EDT
I cannot scroll back on a RHEL6.1 system using no-scroll. I also tried it without the option and I could scroll back
Comment 27 David Kutálek 2011-03-21 10:25:57 EDT
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"
Comment 28 Eduard Benes 2011-03-22 05:37:36 EDT
(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.
Comment 30 Eduard Benes 2011-03-23 08:28:55 EDT
(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
Comment 32 David Kutálek 2011-03-23 08:41:45 EDT
    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.
Comment 33 Stephan Mueller 2011-03-23 08:45:48 EDT
> 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.
Comment 39 Eduard Benes 2011-03-24 11:53:35 EDT
Since there is nothing to fix and we have a working solution I think we can close the bug at this point.