Quick fix for X.org screensaver bypass

This vulnerability is quite annoying if you're locking your desktop in work or anywhere else.

In short, one is able to kill xorg's xscreensaver's lock by just pressing alt-ctrl-* or alt-ctrl-/ (both * and / need to be from the keypad).

A workaround that was posted suggests to modify files in the system. If you don't want to (like me - for various reasons) then you can do this on-the-fly.

Put the following script in a file and make it run whenever you log in to your X session (e.g. by putting it in ~/.kde/Autostart/ if you're using KDE):

[code lang="shell"]
#!/bin/bash

xkbcomp :0 - > /tmp/xkbcomp
cat /tmp/xkbcomp \
| sed -n '/key <KPMU> {/,/^ *}/ !p' \
| sed -n '/key <KPDV> {/,/^ *}/ !p' \
> /tmp/xkbcomp.new
xkbcomp /tmp/xkbcomp.new :0
[/code]

On each login, this will get rid of the offending xkb entries.

fix for radeon + opensource driver + kde effects = crash

The problem

Kwin crashes when enabling opengl effects. It doesn't crash immediately but it crashes after specific actions so it is 100% reproducible. For example when exiting from desktop-grid effect.

The situation

I'm using:

• Radeon 4870 graphics card (RV770)


• Kernel 3.1.5 (but seems irrelevant)


• Open source ATI driver with KMS using Gallium


• Xorg 1.11.2.902 (but happened with previous versions)


• MESA 7.11.2


• KDE 4.7.4 from debian


• DRM 2.4.29


• xserver radeon driver 6.14.3

I'm not using the blur effect

The solution

cd to ~/.kde/env/ (create it if it doesn't exist)

create a file named gl.sh (or any other name) with execute permissions (should not be needed) and with the following contents:

[code]
#!/bin/bash

export LIBGL_ALWAYS_INDIRECT=1
[/code]

The first line should not be needed as this file most probably gets source'd, but it will not hurt.

The drawback

Every GL app you'll be using will inherit the LIBGL_ALWAYS_INDIRECT from environment, which may cause problems. If you want to play (for example) a game then open a terminal and run:

[code]
unset LIBGL_ALWAYS_INDIRECT
nexuiz # or whichever opengl app you want to launch
[/code]
Note: Fireofx is one of the applications that may use GL.

Big nfs_inode_cache

The story

Boxes with various kernel versions have weird free memory problems. After examining the memory usage it seems that processes don't add up to the actual memory that is being used.

Taking a look at /proc/meminfo we see something like this:

[code]
MemTotal:      8161544 kB
MemFree:        115676 kB
Buffers:          3900 kB
Cached:         200520 kB
SwapCached:      42336 kB
Active:         546824 kB
Inactive:       138336 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      8161544 kB
LowFree:        115676 kB
SwapTotal:     2096472 kB
SwapFree:       547480 kB
Dirty:            1020 kB
Writeback:           0 kB
AnonPages:      453480 kB
Mapped:          66928 kB
Slab:          7250176 kB
PageTables:      75408 kB
...
[/code]

Notice that Slab is about 7.5GB, almost the whole memory (8GB) (!).

Slab is the kernel memory and we can see where it is allocated by examining /proc/slabinfo. Here's an excerpt:

[code]
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
nfs_direct_cache       0      0    136   28    1 : tunables  120   60    8 : slabdata      0      0      0
nfs_write_data        62     63    832    9    2 : tunables   54   27    8 : slabdata      7      7      0
nfs_read_data        215    297    832    9    2 : tunables   54   27    8 : slabdata     33     33     54
nfs_inode_cache   5384386 5399040   1032    3    1 : tunables   24   12    8 : slabdata 1799680 1799680     40
nfs_page             534    750    128   30    1 : tunables  120   60    8 : slabdata     25     25    264
rpc_buffers            8      8   2048    2    1 : tunables   24   12    8 : slabdata      4      4      0
...
[/code]

Notice the nfs_inode_cache which is 5.3M objects of 1032 bytes each, adding up to about 5.4GB.

The workaround

Looking a bit about this on the internet we see that this is most probably a bug. Fortunately there are two workaround: A slow and a fast one:

Slow workaround: Login to that box and run "sync". Then leave it alone for a couple of minutes while the nfs_inode_cache memory goes down and down. It make take a couple of minutes before starting going down and there may be pauses in the process. It can take more than an hour to free the memory.

Fast workaround: Login to that box and run:

[code]
# sync
# echo 2 > /proc/sys/vm/drop_caches
[/code]

I'm not sure why the first one works, but it looks like it is triggering a chain reaction that frees the memory.