ia64/linux-2.6.18-xen.hg

view Documentation/seclvl.txt @ 897:329ea0ccb344

balloon: try harder to balloon up under memory pressure.

Currently if the balloon driver is unable to increase the guest's
reservation it assumes the failure was due to reaching its full
allocation, gives up on the ballooning operation and records the limit
it reached as the "hard limit". The driver will not try again until
the target is set again (even to the same value).

However it is possible that ballooning has in fact failed due to
memory pressure in the host and therefore it is desirable to keep
attempting to reach the target in case memory becomes available. The
most likely scenario is that some guests are ballooning down while
others are ballooning up and therefore there is temporary memory
pressure while things stabilise. You would not expect a well behaved
toolstack to ask a domain to balloon to more than its allocation nor
would you expect it to deliberately over-commit memory by setting
balloon targets which exceed the total host memory.

This patch drops the concept of a hard limit and causes the balloon
driver to retry increasing the reservation on a timer in the same
manner as when decreasing the reservation.

Also if we partially succeed in increasing the reservation
(i.e. receive less pages than we asked for) then we may as well keep
those pages rather than returning them to Xen.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
author Keir Fraser <keir.fraser@citrix.com>
date Fri Jun 05 14:01:20 2009 +0100 (2009-06-05)
parents 831230e53067
children
line source
1 BSD Secure Levels Linux Security Module
2 Michael A. Halcrow <mike@halcrow.us>
5 Introduction
7 Under the BSD Secure Levels security model, sets of policies are
8 associated with levels. Levels range from -1 to 2, with -1 being the
9 weakest and 2 being the strongest. These security policies are
10 enforced at the kernel level, so not even the superuser is able to
11 disable or circumvent them. This hardens the machine against attackers
12 who gain root access to the system.
15 Levels and Policies
17 Level -1 (Permanently Insecure):
18 - Cannot increase the secure level
20 Level 0 (Insecure):
21 - Cannot ptrace the init process
23 Level 1 (Default):
24 - /dev/mem and /dev/kmem are read-only
25 - IMMUTABLE and APPEND extended attributes, if set, may not be unset
26 - Cannot load or unload kernel modules
27 - Cannot write directly to a mounted block device
28 - Cannot perform raw I/O operations
29 - Cannot perform network administrative tasks
30 - Cannot setuid any file
32 Level 2 (Secure):
33 - Cannot decrement the system time
34 - Cannot write to any block device, whether mounted or not
35 - Cannot unmount any mounted filesystems
38 Compilation
40 To compile the BSD Secure Levels LSM, seclvl.ko, enable the
41 SECURITY_SECLVL configuration option. This is found under Security
42 options -> BSD Secure Levels in the kernel configuration menu.
45 Basic Usage
47 Once the machine is in a running state, with all the necessary modules
48 loaded and all the filesystems mounted, you can load the seclvl.ko
49 module:
51 # insmod seclvl.ko
53 The module defaults to secure level 1, except when compiled directly
54 into the kernel, in which case it defaults to secure level 0. To raise
55 the secure level to 2, the administrator writes ``2'' to the
56 seclvl/seclvl file under the sysfs mount point (assumed to be /sys in
57 these examples):
59 # echo -n "2" > /sys/seclvl/seclvl
61 Alternatively, you can initialize the module at secure level 2 with
62 the initlvl module parameter:
64 # insmod seclvl.ko initlvl=2
66 At this point, it is impossible to remove the module or reduce the
67 secure level. If the administrator wishes to have the option of doing
68 so, he must provide a module parameter, sha1_passwd, that specifies
69 the SHA1 hash of the password that can be used to reduce the secure
70 level to 0.
72 To generate this SHA1 hash, the administrator can use OpenSSL:
74 # echo -n "boogabooga" | openssl sha1
75 abeda4e0f33defa51741217592bf595efb8d289c
77 In order to use password-instigated secure level reduction, the SHA1
78 crypto module must be loaded or compiled into the kernel:
80 # insmod sha1.ko
82 The administrator can then insmod the seclvl module, including the
83 SHA1 hash of the password:
85 # insmod seclvl.ko
86 sha1_passwd=abeda4e0f33defa51741217592bf595efb8d289c
88 To reduce the secure level, write the password to seclvl/passwd under
89 your sysfs mount point:
91 # echo -n "boogabooga" > /sys/seclvl/passwd
93 The September 2004 edition of Sys Admin Magazine has an article about
94 the BSD Secure Levels LSM. I encourage you to refer to that article
95 for a more in-depth treatment of this security module:
97 http://www.samag.com/documents/s=9304/sam0409a/0409a.htm