The future of AppArmor
By Jake Edge
October 17, 2007
Late last month, Novell laid off the
development team for the AppArmor security tool. AppArmor is widely
deployed by SUSE Linux users to restrict programs from accessing things
that they shouldn't. Novell intends to keep shipping AppArmor, while two
other distributions are adding support for it, which makes this move a bit
puzzling. Reasons are hard to come by when a "reduction in force" (a
common euphemism for layoff) happens, but Novell did clearly indicate that
they had no plans to stop using AppArmor as the "core security technology
in SUSE Linux Enterprise."
When a project team is laid off, it is common for the team to lose
interest in the project – go off to find other things to do –
but that does not appear to be the case here. Some of the laid-off team members have
formed Mercenary Linux to do
AppArmor consulting. They intend to work with Novell and others to guide
AppArmor
through the kernel submission process, with the goal of getting merged into
the mainline. There are some hurdles to clear before that
can happen – if it does – but AppArmor does not have the look
of a project being abandoned, at least yet.
AppArmor was originally a proprietary program, which Novell acquired in
2005 when they bought Immunix, the company that developed it. In January
2006, Novell released it under the GPL and in April of that year, submitted
it as a patch for inclusion in the kernel. The reaction was rather unfavorable,
with the main issue being the reliance on paths, rather than information
stored in the filesystem inode, to determine security policy. The main
advantage cited by AppArmor proponents is that it is much easier to
understand and manage compared to SELinux, its main competitor in the Linux
security module arena.
AppArmor is included in SUSE Linux and has become popular, so much
so that both Mandriva and Ubuntu are shipping it in their next releases.
Because of that, Crispin Cowan, founder of Immunix and former AppArmor team lead at
Novell, guesses that "by early 2008 a majority of all Linux
users will have AppArmor running on their desktop."
After letting the developers go, Novell has no plans to stop shipping AppArmor according to
Kevan Barney, senior public relations
manager:
We remain committed to AppArmor as our application security solution inside
SUSE Linux Enterprise. We have no plans to change to SELinux or another
alternative technology, although we always reserve the right to evaluate
market conditions to provide the maximum value to our customers.
AppArmor is shifting to an open source development model,
where Novell will still be participating as part of the community. As Barney
puts it:
[...] we partner with the community to provide a part of the innovation and
testing efforts, which we complement with our own focused efforts and
investments. Novell will continue its maintenance of the core kernel code
and will continue in our efforts to move this upstream. We will also invest
in key new features as driven by market need.
Cowan agrees that the project is moving away from a one-company model: "AppArmor is becoming a truly
distributed open source
project, and Mercenary Linux hopes to be the hub of that community."
He and the other former team members who formed Mercenary Linux are
poised to assist with AppArmor development:
We have an ongoing commitment to the community that we will work to
fulfill - distribution vendors needing integration help, consulting
firms looking for even better management tools, and bug fixes for the
distributions that AppArmor is deployed in.
Both Novell and Mercenary will be pushing to get AppArmor into the kernel,
with another patch submission from Novell expected soon. The impediments
to getting those patches accepted are outlined by Cowan:
The barriers to acceptance are both technical and
political. Technical is "the way you want to do something conflicts with
the way I want to do something" and political is "... and mine is more
important than yours" :-) An unfortunate resolution to that is a
slugfest of whose really is more important, and an adroit solution is to
find a way to achieve both that doesn't conflict. Developers at Novell and
Mercenary are working on that latter path.
AppArmor provides some amount of protection against programs trying to
access files or perform actions that they shouldn't. Just how much
protection it provides is the subject of much debate. There are valid
concerns that it papers over the complexities of securing Linux, providing
a false sense of security, but it would appear that there is a clear path
for it to be included in the kernel. After Linus Torvalds's recent pronouncement that the Linux
Security Modules API would stay in the kernel, one potential barrier to
AppArmor acceptance has fallen.
It remains to be seen if Novell, Mercenary, and the AppArmor community
can work with the kernel hackers to resolve some outstanding issues. The
path-based architecture of AppArmor, while contentious, is not likely to
keep it out of the kernel. It has been a year and a half since the first
submission, though; it will require a concerted effort to work through the
process. With three distributions shipping it and minimal impact on those
who do not enable it, it seems pretty unlikely that it will stay out
forever.
Comments (2 posted)
A visit from the trolls
By Jonathan Corbet
October 15, 2007
We have been hearing the warnings for years: sooner or later, software
patents were destined to be used against free software. When dire warnings
are repeated over a long period of time, it can become easy to shrug them
off and assume that nothing will ever really come of them. But complacency
does not make the problem go away. And now we have, in the form of a
lawsuit filed against Red Hat and Novell by IP Innovation LLC, a reminder
that the software patent threat is real.
Three patents are named in the brief complaint [PDF]:
- #5,072,412,
"User interface with multiple workspaces for sharing display system
objects". Filed in March, 1987.
- #5,533,183,
which has the same title. Filed in February, 1995.
- #5,394,521,
again with the same title. Filed in May, 1993.
As might be imagined, the three patents all read about the same. Those who
are not afraid of patentese can get a feel for what has been patented by
reading the first claim of #5,072,412 - one of the claims alleged to be
violated by the defendants:
A system comprising:
- a display;
- first and second workspace data structures relating respectively to
first and second workspaces that can be presented on the display; each of
the first and second workspaces including a respective set of display
objects; each of the display objects being perceptible as a distinct,
coherent set of display features; the display objects of each respective
set being perceptible as having spatial positions relative to each other
when the respective workspace is presented on the display;
- display object means for generating first and second display objects;
the first workspace data structure being linked to the display object means
so that the first display object is in the respective set of display
objects of the first workspace; the second workspace data structure being
linked to the display object means so that the second display object is in
the respective set of display objects of the second workspace; and
- control means for accessing the first workspace data structure to
cause the display to present the first workspace including the first
display object; the control means further being for accessing the second
workspace data structure to cause the display to present the second
workspace including the second display object; the display object means
generating the first and second display objects so that the second display
object is perceptible as the same tool as the first display object when the
second workspace is presented after the first workspace.
This claim seems like a fairly straightforward description of a window
manager which provides multiple virtual desktops. It does not take a whole
lot of imagination to extend this reading to describe the behavior of two windows on
the same desktop. Finding software within a Linux system which can be said
to infringe upon these patents is probably not all that hard to do.
Eliminating all code which could be said to infringe, instead, could be
difficult indeed. (Bear in mind, though, that your editor is fortunate
enough not to be a patent attorney; anybody needing a definitive
interpretation of this patent should consult people who know what they are
talking about).
The defense against this attack will require either (1) the location
of sufficient prior art to invalidate the patents, or (2) an argument
that, by the allegedly tightened definition of "obviousness" in the U.S.,
the technology patented is not sufficiently innovative. Red Hat and Novell
have not shared their defensive strategy with the world, and they are
unlikely to do so in the near future. We will almost certainly have to wait and see how
they answer the charges in court.
As an alternative, the two companies could pay the troll in exchange for an
agreement allowing the patented technology to be used in GPL-licensed
software. Assuming an agreement could be reached, this approach would
solve the immediate problem. But it would also encourage every other
patent troll out there to head to court in search of a turn at the trough.
It would be far better to defeat this attack if at all possible.
Regardless of how this case plays out, though, we can be sure that it will
not be the last. There is no shortage of software patents in the U.S. and
no shortage of lawyers willing to turn them into lawsuits. The system
encourages this sort of litigation.
For this reason, your editor feels that the current focus on finding links
between this suit and Microsoft is misplaced. It may well be that
Microsoft is lurking in the shadows somewhere, directing the entire
operation. Your editor has no way of knowing. But there's a couple of
things which should be kept in mind when trying to make that connection.
The first is that Microsoft's presence is in no way necessary to explain
this series of events. Patent trolls are not in short supply, and neither
are patent infringement lawsuits. It was a certainty that one of these
trolls was going to turn its attention to free software companies sooner or
later. IP Innovations, owned by well-known patent troll Acacia, is no
stranger to this sort of litigation; it could have easily decided on this
course of action on its own.
Second, it's not clear that this attack, at this time, is in Microsoft's
interest. For all the talk of the safety provided by Novell's purchase of
a patent non-license from Microsoft, Novell, too, has been sued. No users
have been sued, but, should the plaintiffs decide to target Linux users,
Novell's customers will be just as exposed as Red Hat's customers. Any
other company which might be considering the purchase of a "covenant not to
sue" from Microsoft need only look at this case to see that the covenant
has not solved the problem: the company which bought the covenant is in
the same position as the company which refused to do so. This attack can
also only serve to clarify the problems with software patents in parts of
the world which do not currently allow software to be patented.
In other words, this lawsuit has driven home the fact that, with regard to
software patents in the U.S., Microsoft is not the problem. Microsoft's
own experience on the receiving end of patent infringement lawsuits should
also make that clear. Whether or not Microsoft is behind this suit, the
real problem is the current software patent regime in the U.S. and the
litigation-friendly environment which supports it. If Microsoft were to
vanish tomorrow, the threat would not be reduced in any appreciable way.
So putting the focus on Microsoft is a mistake; we have a much bigger
problem than that.
Comments (78 posted)
Memory part 4: NUMA support
October 17, 2007
This article was contributed by Ulrich Drepper
[
Editor's note: welcome to part 4 of Ulrich Drepper's "What every
programmer should know about memory"; this section discusses the particular
challenges associated with non-uniform memory access (NUMA) systems. Those
who have
not read part 1, part 2, and part 3
may wish to do so
now. As always, please send typo reports and the like to lwn@lwn.net
rather than posting them as comments here.]
5 NUMA Support
In Section 2 we saw that, on some machines,
the cost of access to specific regions of physical memory
differs depending on where the access originated. This
type of hardware requires special care from the OS and the
applications. We will start with a few details of NUMA hardware,
then we will cover some of the support the Linux kernel provides for
NUMA.
5.1 NUMA Hardware
Non-uniform memory architectures are becoming more and more common.
In the simplest form of NUMA, a processor can have local memory (see
Figure 2.3) which is cheaper to access than memory local to
other processors. The difference in cost for this type of NUMA system is
not high, i.e., the NUMA factor is low.
NUMA is also—and especially—used in big machines. We have described
the problems of having many processors access the same memory. For
commodity hardware all processors would share the same Northbridge
(ignoring the AMD Opteron NUMA nodes for now, they have their own
problems). This makes the Northbridge a severe bottleneck since
all memory traffic is routed through it. Big machines can, of
course, use custom hardware in place of the Northbridge but, unless the
memory chips used have multiple ports—i.e. they can be used from multiple
busses—there still is a bottleneck. Multiport RAM is complicated and
expensive to build and support and, therefore, it is hardly ever used.
The next step up in complexity is the model AMD uses where an
interconnect mechanism (Hypertransport in AMD's case, technology
they licensed from Digital) provides access for processors which are not
directly connected to the RAM. The size of the structures which can
be formed this way is limited unless one wants to increase the
diameter (i.e., the maximum distance between any two nodes)
arbitrarily.
Figure 5.1: Hypercubes
An efficient topology for the nodes is the hypercube, which limits the
number of nodes to 2C where C is the number of interconnect
interfaces each node has. Hypercubes have the smallest diameter for
all systems with 2n CPUs. Figure
5.1 shows the first
three hypercubes. Each hypercube has a diameter of C which is the
absolute minimum. AMD's first-generation Opteron processors have three
hypertransport links per processor. At least one of the processors
has to have a Southbridge attached to one link, meaning, currently, that a
hypercube with C=2 can be implemented directly and efficiently. The
next generation is announced to have four links, at which point C=3
hypercubes will be possible.
This does not mean, though, that larger accumulations of processors
cannot be supported. There are companies which have developed crossbars
allowing larger sets of processors to be used (e.g., Newisys's
Horus). But these crossbars increase the NUMA factor and they stop
being effective at a certain number of processors.
The next step up means connecting groups of CPUs and implementing a
shared memory for all of them. All such systems need specialized
hardware and are by no means commodity systems. Such designs exist at several
levels of complexity. A system which is still quite close to a
commodity machine is IBM x445 and similar machines. They can be
bought as ordinary 4U, 8-way machines with x86 and x86-64 processors.
Two (at some point up to four) of these machines can then be connected
to work as a single machine with shared memory. The interconnect used
introduces a significant NUMA factor which the OS, as well as
applications, must take into account.
At the other end of the spectrum, machines like SGI's Altix are
designed specifically to be interconnected. SGI's NUMAlink
interconnect fabric is very fast and has a low latency; both of these are
requirements for high-performance computing (HPC), especially when
Message Passing Interfaces (MPI) are used. The drawback is, of course, that such
sophistication and specialization is very expensive. They make a
reasonably low NUMA factor possible but with the number of CPUs these
machines can have (several thousands) and the limited capacity of the
interconnects, the NUMA factor is actually dynamic and can reach
unacceptable levels depending on the workload.
More commonly used are solutions where clusters of commodity machines
are connected using high-speed networking. But these are not NUMA
machines; they do not implement a shared address space and therefore
do not fall into any category which is discussed here.
5.2 OS Support for NUMA
To support NUMA machines, the OS has to take the distributed
nature of the memory into account. For instance, if a process is run
on a given processor, the physical RAM assigned to the process's address
space should come from local memory. Otherwise each instruction has
to access remote memory for code and data. There are special cases to
be taken into account which are only present in NUMA machines. The
text segment of DSOs is normally present exactly once in a machine's
physical RAM. But if the DSO is used by processes and threads on all
CPUs (for instance, the basic runtime libraries like libc) this
means that all but a few processors have to have remote accesses. The OS
ideally would mirror such DSOs into each processor's physical RAM
and use local copies. This is an optimization, not a requirement, and
generally hard to implement. It might not be supported or only in a
limited fashion.
To avoid making the situation worse, the OS
should not migrate a process or thread from one node to another. The
OS should already try to avoid migrating processes on normal
multi-processor machines because
migrating from one processor to another means the cache content is
lost. If load distribution requires migrating a process or thread off
of a processor, the OS can usually pick an arbitrary new processor
which has sufficient capacity left. In NUMA environments the
selection of the new processor is a bit more limited. The newly
selected processor should not have higher access costs to the memory
the process is using than the old processor; this restricts the list
of targets. If there is no free processor matching that criteria
available, the OS has no choice but to migrate to a processor
where memory access is more expensive.
In this situation there are two possible ways forward. First, one can
hope the situation is temporary and the process can be migrated back
to a better-suited processor. Alternatively, the OS can also migrate the
process's memory to physical pages which are closer to the newly-used processor.
This is quite an expensive operation. Possibly huge amounts of memory
have to be copied, albeit not necessarily in one step. While this is
happening the process, at least briefly, has to be stopped so that
modifications to the old pages are correctly migrated. There are a
whole list of other requirements for page migration to be efficient
and fast. In short, the OS should avoid it unless it is really
necessary.
Generally, it cannot be assumed that all processes on a NUMA machine
use the same amount of memory such that, with the distribution of processes across
the processors, memory usage is also equally
distributed. In fact, unless the applications running on the machines
are very specific (common in the HPC world, but not outside) the
memory use will be very unequal. Some applications will use vast amounts
of memory, others hardly any. This will, sooner or later, lead to
problems if memory is always allocated local to the processor where
the request is originated. The system will eventually run out of memory local to
nodes running large processes.
In response to these severe problems, memory is, by default, not allocated
exclusively on the local node. To utilize all the system's memory the
default strategy is to stripe the memory. This guarantees equal use
of all the memory of the system. As a side effect, it becomes
possible to freely migrate processes between processors since, on
average, the access cost to all the memory used does not change. For
small NUMA factors, striping is acceptable but still not optimal (see
data in Section 5.4).
This is a pessimization which helps the system avoid severe problems and
makes it more predictable under normal operation. But it does
decrease overall system performance, in some situations significantly.
This is why Linux allows the memory allocation rules to be selected by
each process. A process can select a different strategy for itself and
its children. We will introduce the interfaces which can be used for
this in Section 6.
5.3 Published Information
The kernel publishes, through the sys pseudo file system (sysfs),
information about the processor caches below
/sys/devices/system/cpu/cpu*/cache
In Section 6.2.1 we will see interfaces which can be used to query
the size of the various caches. What is important here is the topology of
the caches. The directories above contain subdirectories
(named index*) which list information about the various caches the CPU
possesses. The files type, level, and shared_cpu_map
are the important files in these directories as far as the topology is
concerned. For an Intel Core 2 QX6700 the information looks as in
Table 5.1.
| type | level | shared_cpu_map |
| cpu0 |
index0 | Data | 1 | 00000001 |
| index1 | Instruction | 1 | 00000001 |
| index2 | Unified | 2 | 00000003 |
| cpu1 |
index0 | Data | 1 | 00000002 |
| index1 | Instruction | 1 | 00000002 |
| index2 | Unified | 2 | 00000003 |
| cpu2 |
index0 | Data | 1 | 00000004 |
| index1 | Instruction | 1 | 00000004 |
| index2 | Unified | 2 | 0000000c |
| cpu3 |
index0 | Data | 1 | 00000008 |
| index1 | Instruction | 1 | 00000008 |
| index2 | Unified | 2 | 0000000c |
Table 5.1: sysfs Information for Core 2 CPU Caches
What this data means is as follows:
- Each core {The knowledge that cpu0 to cpu3
are cores comes from another place that will be explained shortly.}
has three caches: L1i, L1d, L2.
- The L1d and L1i caches are not shared with anybody—each core
has its own set of caches. This is indicated by the bitmap
in shared_cpu_map having only one set bit.
- The L2 cache on cpu0 and cpu1 is shared, as is the
L2 on cpu2 and cpu3.
If the CPU had more cache levels, there would be more index*
directories.
For a four-socket, dual-core Opteron machine the cache information
looks like Table 5.2:
| type | level | shared_cpu_map |
| cpu0 |
index0 | Data | 1 | 00000001 |
| index1 | Instruction | 1 | 00000001 |
| index2 | Unified | 2 | 00000001 |
| cpu1 |
index0 | Data | 1 | 00000002 |
| index1 | Instruction | 1 | 00000002 |
| index2 | Unified | 2 | 00000002 |
| cpu2 |
index0 | Data | 1 | 00000004 |
| index1 | Instruction | 1 | 00000004 |
| index2 | Unified | 2 | 00000004 |
| cpu3 |
index0 | Data | 1 | 00000008 |
| index1 | Instruction | 1 | 00000008 |
| index2 | Unified | 2 | 00000008 |
| cpu4 |
index0 | Data | 1 | 00000010 |
| index1 | Instruction | 1 | 00000010 |
| index2 | Unified | 2 | 00000010 |
| cpu5 |
index0 | Data | 1 | 00000020 |
| index1 | Instruction | 1 | 00000020 |
| index2 | Unified | 2 | 00000020 |
| cpu6 |
index0 | Data | 1 | 00000040 |
| index1 | Instruction | 1 | 00000040 |
| index2 | Unified | 2 | 00000040 |
| cpu7 |
index0 | Data | 1 | 00000080 |
| index1 | Instruction | 1 | 00000080 |
| index2 | Unified | 2 | 00000080 |
Table 5.2: sysfs Information for Opteron CPU Caches
As can be seen these processors
also have three caches: L1i, L1d, L2. None of the cores
shares any level of cache. The interesting part for this system is the
processor topology. Without this additional information one cannot
make sense of the cache data. The sys file system exposes this
information in the files below
/sys/devices/system/cpu/cpu*/topology
Table 5.3 shows the interesting files in this hierarchy
for the SMP Opteron machine.
|
physical_ package_id |
core_id |
core_ siblings |
thread_ siblings |
| cpu0 | 0 | 0 | 00000003 | 00000001 |
| cpu1 | 1 | 00000003 | 00000002 |
| cpu2 | 1 | 0 | 0000000c | 00000004 |
| cpu3 | 1 | 0000000c | 00000008 |
| cpu4 | 2 | 0 | 00000030 | 00000010 |
| cpu5 | 1 | 00000030 | 00000020 |
| cpu6 | 3 | 0 | 000000c0 | 00000040 |
| cpu7 | 1 | 000000c0 | 00000080 |
Table 5.3: sysfs Information for Opteron CPU Topology
Taking Table 5.2 and Table 5.3 together we
can see that no CPU has hyper-threads (the thread_siblings
bitmaps have one bit set), that the system in fact has four processors
(physical_package_id 0 to 3), that each processor has two cores,
and that none of the cores share any cache. This is exactly what
corresponds to earlier Opterons.
What is completely missing in the data provided so far is information
about the nature of NUMA on this machine. Any SMP Opteron machine is
a NUMA machine. For this data we have to look at yet another part of
the sys file system which exists on NUMA machines, namely in the
hierarchy below
/sys/devices/system/node
This directory contains a subdirectory for every NUMA node on the
system. In the node-specific directories there are a number of files. The
important files and their content for the Opteron machine described in the
previous two tables are shown in Table 5.4.
| cpumap | distance |
| node0 | 00000003 | 10 20 20 20 |
| node1 | 0000000c | 20 10 20 20 |
| node2 | 00000030 | 20 20 10 20 |
| node3 | 000000c0 | 20 20 20 10 |
Table 5.4: sysfs Information for Opteron Nodes
This information ties all the rest together; now we have a complete
picture of the architecture of the machine. We already know that the
machine has four processors. Each processor constitutes its own node
as can be seen by the bits set in the value in cpumap file in the
node* directories. The distance files in those
directories contains a set of values, one for each node, which
represent a cost of memory accesses at the respective nodes. In this
example all local memory accesses have the cost 10, all remote access
to any other node has the cost 20. {This is, by the way,
incorrect. The ACPI information is apparently wrong since, although
the processors used have three coherent HyperTransport links, at least
one processor must be connected to a Southbridge. At least one pair of nodes
must therefore have a larger distance.} This means that, even though the
processors are organized as a two-dimensional hypercube (see
Figure 5.1), accesses between processors which are not directly connected is
not more expensive. The relative values of the costs
should be usable as an estimate of the actual difference of the access
times. The accuracy of all this information is another question.
5.4 Remote Access Costs
The distance is relevant, though. In [amdccnuma] AMD documents
the NUMA cost of a four socket machine. For write operations the
numbers are shown in Figure 5.3.
Figure 5.3: Read/Write Performance with Multiple Nodes
Writes are slower than
reads, this is no surprise. The interesting parts are the costs of
the 1- and 2-hop cases. The two 1-hop cases actually have slightly
different costs. See [amdccnuma] for the details. The fact we
need to remember from this chart is that 2-hop reads and writes are
30% and 49% (respectively) slower than 0-hop reads. 2-hop writes
are 32% slower than 0-hop writes, and 17% slower than 1-hop writes.
The relative position of processor and memory nodes can make a big
difference. The next generation of processors from AMD will feature
four coherent HyperTransport links per processor. In that case a four
socket machine would have diameter of one. With eight sockets the
same problem returns, with a vengeance, since the diameter of a
hypercube with eight nodes is three.
All this information is available but it is cumbersome to use. In
Section 6.5 we will see an interface which helps accessing and
using this information easier.
The last piece of information the system provides is in the status of
a process itself. It is possible to determine how the memory-mapped
files, Copy-On-Write (COW) pages and anonymous memory are distributed over
the nodes in the
system.
{Copy-On-Write is a method
often used in OS implementations when a memory page has one user at
first and then has to be copied to allow independent users. In
many situations the copying is unnecessary, at all or at first, in
which case it makes sense to only copy when either user modifies the
memory. The operating system intercepts the write operation,
duplicates the memory page, and then allows the write instruction to
proceed.}
Each process has a file /proc/PID/numa_maps,
where PID is the ID of the process, as shown in
Figure 5.2.
00400000 default file=/bin/cat mapped=3 N3=3
00504000 default file=/bin/cat anon=1 dirty=1 mapped=2 N3=2
00506000 default heap anon=3 dirty=3 active=0 N3=3
38a9000000 default file=/lib64/ld-2.4.so mapped=22 mapmax=47 N1=22
38a9119000 default file=/lib64/ld-2.4.so anon=1 dirty=1 N3=1
38a911a000 default file=/lib64/ld-2.4.so anon=1 dirty=1 N3=1
38a9200000 default file=/lib64/libc-2.4.so mapped=53 mapmax=52 N1=51 N2=2
38a933f000 default file=/lib64/libc-2.4.so
38a943f000 default file=/lib64/libc-2.4.so anon=1 dirty=1 mapped=3 mapmax=32 N1=2 N3=1
38a9443000 default file=/lib64/libc-2.4.so anon=1 dirty=1 N3=1
38a9444000 default anon=4 dirty=4 active=0 N3=4
2b2bbcdce000 default anon=1 dirty=1 N3=1
2b2bbcde4000 default anon=2 dirty=2 N3=2
2b2bbcde6000 default file=/usr/lib/locale/locale-archive mapped=11 mapmax=8 N0=11
7fffedcc7000 default stack anon=2 dirty=2 N3=2
Figure 5.2: Content of /proc/PID/numa_maps
The important information in the file is the
values for N0 to N3, which indicate the number of pages
allocated for the memory area on nodes 0 to 3. It is a good
guess that the program was executed on a core on node 3. The program
itself and the dirtied pages are allocated on that node. Read-only
mappings, such as the first mapping for ld-2.4.so and
libc-2.4.so as well as the shared file locale-archive are
allocated on other nodes.
As we have seen in Figure 5.3 the read performance across
nodes falls by 9% and 30% respectively for 1- and 2-hop reads.
For execution, such reads are needed and, if the L2 cache is missed,
each cache line incurs these additional costs. All the costs measured
for large workloads beyond the size of the cache would have to be
increased by 9%/30% if the memory is remote to the processor.
Figure 5.4: Operating on Remote Memory
To see the effects in the real world we can measure the bandwidth as
in Section 3.5.1 but this time with the memory being on a
remote node, one hop away. The result of this test when compared
with the data for using local memory can be seen in
Figure 5.4. The numbers have a few big spikes
in both directions which are the result of a problem of measuring
multi-threaded code and can be ignored. The important information in
this graph is that read operations are always 20% slower. This is
significantly slower than the 9% in Figure 5.3, which is,
most likely, not a number for uninterrupted read/write operations and might
refer to older processor revisions. Only AMD knows.
For working set sizes which fit into the caches, the performance of
write and copy operations is also 20% slower. For working sets
exceeding the size of the caches, the write performance is not
measurably slower than the operation on the local node. The speed of
the interconnect is fast enough to keep up with the memory. The
dominating factor is the time spent waiting on the main memory.
Comments (6 posted)
Page editor: Jonathan Corbet
Security
Cross-site request forgery
By Jake Edge
October 17, 2007
Cross-site request forgery (CSRF or XSRF) is yet another web
application flaw that can have serious impacts. By exploiting
the trust that the targeted site has in a logged-in user, usually
encapsulated in a cookie, CSRF can perform actions on behalf of that user,
without any indication that the action took place. It shares many traits with
its better-known sibling, cross-site scripting (XSS), but,
unlike a site targeted via XSS (for login spoofing or cookie stealing for
example), the target web site can make changes to avoid CSRF.
A CSRF attack targets a specific web site, one that requires credentials
to perform actions. Financial and shopping sites are common targets, but
as described in last week's article on this page, home
routers and similar equipment are also targets. Another popular target is
sites like Digg, where users vote on
particular stories to increase their popularity; an attacker can drive more
traffic to a site of their choosing by using a CSRF exploit to add votes.
The exploit itself is typically contained in an <img> tag or form
submission, with Javascript sometimes used to hide the form submission.
The URL used causes some kind of side effect on the target website as long
as a properly authenticated cookie is delivered with the request. For
example, if LWN had a voting system, a tag like the
following could perform a CSRF exploit:
<img src="http://lwn.net/vote?type=y;story=some_lame_story_URL" width=0 height=0>
When the browser goes to fetch that "image", it helpfully sends along any
cookies that correspond to the domain; if the vote application wasn't
written correctly, anyone viewing the web page - and who was also logged-in to
LWN - would add a vote for the story. There would be no indication that
anything had happened, other than possibly a fleeting notice in the browser
noting a connection to LWN.
Getting the user to visit the page with the CSRF is done in the usual way,
via a link in email, instant message, or on another web page. CSRF does not
require inserting code into the vulnerable website, which is the hallmark of
XSS; instead it exploits the target from afar. The link the victim follows will
not in any way indicate the target site.
There are a few things that web application programmers can do to eliminate
CSRF problems; the basic idea is not to perform actions solely based on a
proper cookie. Just as some non-internet authentications require two forms
of identification, web applications should do the same. The second
identification should come from something other than the cookie, something
that can be known only by a properly authenticated user.
Two basic techniques are used, random form tokens or re-authentication.
For sensitive operations, the best protection is to require the user to
provide their credentials (username and password for example) before
performing the action. This can be cumbersome, so, for less sensitive
actions, hidden fields with random names and values can be inserted into
each form, associated with a particular session, and checked on form
submission. This isn't completely secure, as the values might be guessed,
but with sufficient randomness, it is good enough for many operations.
It should be noted that preventing CSRF requires that all XSS problems are
removed first. An XSS flaw can be used to retrieve the form,
then grab the random tokens before submitting the CSRF request. XSS may
also be able to spoof the user into entering their credentials, which would
allow the CSRF to bypass re-authentication as well.
CSRF has been called the "sleeping giant" of web application security
flaws, because it has yet to be exploited widely. It is only a matter of
time, web programmers should be making the changes needed to ensure that
their sites are not vulnerable.
Comments (15 posted)
New vulnerabilities
ampache: multiple vulnerabilities
| Package(s): | ampache |
CVE #(s): | CVE-2007-4437
CVE-2007-4438
|
| Created: | October 15, 2007 |
Updated: | October 17, 2007 |
| Description: |
SQL injection vulnerability in albums.php in Ampache before 3.3.3.5 allows
remote attackers to execute arbitrary SQL commands via the match
parameter. Session fixation vulnerability in Ampache before 3.3.3.5 allows
remote attackers to hijack web sessions via unspecified vectors. |
| Alerts: |
|
Comments (none posted)
balsa: buffer overflow
| Package(s): | balsa |
CVE #(s): | CVE-2007-5007
|
| Created: | October 17, 2007 |
Updated: | October 17, 2007 |
| Description: |
Evil Ninja Squirrel discovered a stack-based buffer overflow in the
ir_fetch_seq() function when receiving a long response to a FETCH
command (CVE-2007-5007).
|
| Alerts: |
|
Comments (none posted)
denyhosts: denial of service
| Package(s): | denyhosts |
CVE #(s): | CVE-2007-4323
|
| Created: | October 15, 2007 |
Updated: | October 17, 2007 |
| Description: |
DenyHosts 2.6 does not properly parse sshd log files, which allows remote
attackers to add arbitrary hosts to the /etc/hosts.deny file and cause a
denial of service by adding arbitrary IP addresses to the sshd log file, as
demonstrated by logging in via ssh with a client protocol version
identification containing an IP address string, a different vector than
CVE-2006-6301. |
| Alerts: |
|
Comments (1 posted)
hplip: arbitrary command execution
| Package(s): | hplip |
CVE #(s): | CVE-2007-5208
|
| Created: | October 12, 2007 |
Updated: | January 14, 2008 |
| Description: |
Kees Cook discovered a flaw in the way the hplip hpssd daemon handled user
input. A local attacker could send a specially crafted request to the hpssd
daemon, possibly allowing them to run arbitrary commands as the root user. |
| Alerts: |
|
Comments (none posted)
initscripts: information exposure
| Package(s): | initscripts |
CVE #(s): | |
| Created: | October 12, 2007 |
Updated: | October 26, 2007 |
| Description: |
The initscripts package do not set sufficiently restrictive permissions on
the /var/log/btmp file, leading to an information exposure vulnerability in
which users' passwords may be revealed to unprivileged users in cases when
the passwords have been inadvertently entered as usernames at some login
prompts. |
| Alerts: |
|
Comments (1 posted)
java-1.5.0-sun: multiple vulnerabilities
| Package(s): | java-1.5.0-sun |
CVE #(s): | CVE-2007-5232
CVE-2007-5238
CVE-2007-5239
CVE-2007-5240
CVE-2007-5273
CVE-2007-5274
|
| Created: | October 12, 2007 |
Updated: | April 25, 2008 |
| Description: |
Sun Java Runtime Environment (JRE) in JDK and JRE 6 Update 2 and earlier,
JDK and JRE 5.0 Update 12 and earlier, SDK and JRE 1.4.2_15 and earlier,
and SDK and JRE 1.3.1_20 and earlier, when applet caching is enabled,
allows remote attackers to violate the security model for an applet's
outbound connections via a DNS rebinding attack. (CVE-2007-5232)
Java Web Start in Sun JDK and JRE 6 Update 2 and earlier, JDK and JRE 5.0
Update 12 and earlier, and SDK and JRE 1.4.2_15 and earlier does not
properly enforce access restrictions for untrusted applications, which
allows user-assisted remote attackers to obtain sensitive information (the
Java Web Start cache location) via an untrusted application, aka "three
vulnerabilities." (CVE-2007-5238)
Java Web Start in Sun JDK and JRE 6 Update 2 and earlier, JDK and JRE 5.0
Update 12 and earlier, SDK and JRE 1.4.2_15 and earlier, and SDK and JRE
1.3.1_20 and earlier does not properly enforce access restrictions for
untrusted (1) applications and (2) applets, which allows user-assisted
remote attackers to copy or rename arbitrary files when local users perform
drag-and-drop operations from the untrusted application or applet window
onto certain types of desktop applications. (CVE-2007-5239)
Visual truncation vulnerability in the Java Runtime Environment in Sun JDK
and JRE 6 Update 2 and earlier, JDK and JRE 5.0 Update 12 and earlier, SDK
and JRE 1.4.2_15 and earlier, and SDK and JRE 1.3.1_20 and earlier allows
remote attackers to circumvent display of the untrusted-code warning banner
by creating a window larger than the workstation screen. (CVE-2007-5240)
Sun Java Runtime Environment (JRE) in JDK and JRE 6 Update 2 and earlier,
JDK and JRE 5.0 Update 12 and earlier, SDK and JRE 1.4.2_15 and earlier,
and SDK and JRE 1.3.1_20 and earlier, when an HTTP proxy server is used,
allows remote attackers to violate the security model for an applet's
outbound connections via a multi-pin DNS rebinding attack in which the
applet download relies on DNS resolution on the proxy server, but the
applet's socket operations rely on DNS resolution on the local machine, a
different issue than CVE-2007-5274. NOTE: this is similar to
CVE-2007-5232. (CVE-2007-5273)
Sun Java Runtime Environment (JRE) in JDK and JRE 6 Update 2 and earlier,
JDK and JRE 5.0 Update 12 and earlier, SDK and JRE 1.4.2_15 and earlier,
and SDK and JRE 1.3.1_20 and earlier, when Firefox or Opera is used, allows
remote attackers to violate the security model for JavaScript outbound
connections via a multi-pin DNS rebinding attack dependent on the
LiveConnect API, in which JavaScript download relies on DNS resolution by
the browser, but JavaScript socket operations rely on separate DNS
resolution by a Java Virtual Machine (JVM), a different issue than
CVE-2007-5273. NOTE: this is similar to CVE-2007-5232. (CVE-2007-5274) |
| Alerts: |
|
Comments (1 posted)
libvorbis: multiple vulnerabilities
| Package(s): | libvorbis |
CVE #(s): | CVE-2007-4065
CVE-2007-4066
|
| Created: | October 11, 2007 |
Updated: | January 22, 2008 |
| Description: |
libvorbis has a number of vulnerabilities that can be triggered by
opening a specially crafted Ogg file. Vulnerabilities include
crashing and the execution of arbitrary code. |
| Alerts: |
|
Comments (1 posted)
skktools: insecure temporary file creation
| Package(s): | skktools |
CVE #(s): | CVE-2007-3916
|
| Created: | October 15, 2007 |
Updated: | October 17, 2007 |
| Description: |
skkdic-expr.c insecurely writes temporary files to a location in the form
$TMPDIR/skkdic$PID.{pag,dir,db}, where $PID is the process ID. A local
attacker could create symbolic links in the directory where the temporary
files are written, pointing to a valid file somewhere on the filesystem
that is writable by the user running the SKK software. When SKK writes the
temporary file, the target valid file would then be overwritten with the
contents of the SKK temporary file. |
| Alerts: |
|
Comments (none posted)
tar: buffer overflow
| Package(s): | tar |
CVE #(s): | CVE-2007-4476
|
| Created: | October 16, 2007 |
Updated: | October 3, 2008 |
| Description: |
Buffer overflow in the safer_name_suffix function in GNU tar has unspecified attack vectors and impact, resulting in a "crashing stack." |
| Alerts: |
|
Comments (none posted)
tk: denial of service
| Package(s): | tk8.3 tk8.4 |
CVE #(s): | CVE-2007-5137
|
| Created: | October 12, 2007 |
Updated: | February 22, 2008 |
| Description: |
It was discovered that Tk could be made to overrun a buffer when loading
certain images. If a user were tricked into opening a specially crafted GIF
image, remote attackers could cause a denial of service or execute
arbitrary code with user privileges. |
| Alerts: |
|
Comments (none posted)
wesnoth: denial of service
| Package(s): | wesnoth |
CVE #(s): | CVE-2007-3917
|
| Created: | October 12, 2007 |
Updated: | December 3, 2007 |
| Description: |
A malicious user could send a long chat message with multibyte characters,
the server would truncate the message on a fixed length, without paying
attention to the multibyte characters. This led to invalid utf-8 on the
client and an uncaught exception was thrown. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
apache2: information disclosure
| Package(s): | apache |
CVE #(s): | CVE-2007-1862
|
| Created: | June 20, 2007 |
Updated: | February 18, 2008 |
| Description: |
From the Mandriva advisory: "The recall_headers function in mod_mem_cache in Apache 2.2.4 does not
properly copy all levels of header data, which can cause Apache to
return HTTP headers containing previously-used data, which could be
used to obtain potentially sensitive information by unauthorized users." |
| Alerts: |
|
Comments (2 posted)
apache: multiple vulnerabilities
| Package(s): | apache |
CVE #(s): | CVE-2007-3304
CVE-2006-5752
|
| Created: | June 27, 2007 |
Updated: | February 18, 2008 |
| Description: |
The Apache HTTP Server did not verify that a process was an Apache child
process before sending it signals. A local attacker who has the ability to
run scripts on the Apache HTTP Server could manipulate the scoreboard and
cause arbitrary processes to be terminated, which could lead to a denial of
service. (CVE-2007-3304)
A flaw was found in the Apache HTTP Server mod_status module. Sites with
the server-status page publicly accessible and ExtendedStatus enabled were
vulnerable to a cross-site scripting attack. On Red Hat Enterprise Linux
the server-status page is not enabled by default and it is best practice to
not make this publicly available. (CVE-2006-5752) |
| Alerts: |
|
Comments (1 posted)
apache: cross-site scripting
| Package(s): | apache |
CVE #(s): | CVE-2006-3918
|
| Created: | August 9, 2006 |
Updated: | April 4, 2008 |
| Description: |
From the Red Hat advisory: "A bug was found in Apache where an invalid Expect header sent to the server
was returned to the user in an unescaped error message. This could
allow an attacker to perform a cross-site scripting attack if a victim was
tricked into connecting to a site and sending a carefully crafted Expect
header." |
| Alerts: |
|
Comments (none posted)
httpd: denial of service, cross-site scripting
| Package(s): | apache httpd |
CVE #(s): | CVE-2007-3847
CVE-2007-4465
|
| Created: | September 25, 2007 |
Updated: | February 15, 2008 |
| Description: |
A flaw was found in the mod_proxy module. On sites where a reverse proxy is
configured, a remote attacker could send a carefully crafted request that
would cause the Apache child process handling that request to crash. On
sites where a forward proxy is configured, an attacker could cause a
similar crash if a user could be persuaded to visit a malicious site using
the proxy. This could lead to a denial of service if using a threaded
Multi-Processing Module. (CVE-2007-3847)
A flaw was found in the mod_autoindex module. On sites where directory
listings are used, and the AddDefaultCharset directive has been removed
from the configuration, a cross-site-scripting attack may be possible
against browsers which do not correctly derive the response character set
following the rules in RFC 2616. (CVE-2007-4465) |
| Alerts: |
|
Comments (none posted)
bochs: buffer overflow
| Package(s): | bochs |
CVE #(s): | CVE-2007-2893
|
| Created: | July 20, 2007 |
Updated: | November 19, 2007 |
| Description: |
A heap-based buffer overflow in the bx_ne2k_c::rx_frame function in
iodev/ne2k.cc in the emulated NE2000 device in Bochs 2.3 allows local users
of the guest operating system to write to arbitrary memory locations and
gain privileges on the host operating system via vectors that cause TXCNT
register values to exceed the device memory size, aka "RX Frame heap
overflow." |
| Alerts: |
|
Comments (none posted)
cacti: denial of service
| Package(s): | cacti |
CVE #(s): | CVE-2007-3112
CVE-2007-3113
|
| Created: | September 18, 2007 |
Updated: | February 18, 2008 |
| Description: |
A vulnerability in Cacti 0.8.6i and earlier versions allows remote
authenticated users to cause a denial of service (CPU consumption) via
large values of the graph_start, graph_end, graph_height, or graph_width
parameters. |
| Alerts: |
|
Comments (none posted)
centericq: buffer overflows
| Package(s): | centericq |
CVE #(s): | CVE-2007-3713
|
| Created: | July 20, 2007 |
Updated: | December 17, 2007 |
| Description: |
Multiple buffer overflows in Konst CenterICQ 4.9.11 through 4.21 allow
remote attackers to execute arbitrary code via unspecified vectors. NOTE:
the provenance of this information is unknown; the details are obtained
solely from third party information. NOTE: this might overlap
CVE-2007-0160. |
| Alerts: |
|
Comments (none posted)
clamav: denial of service
| Package(s): | clamav |
CVE #(s): | CVE-2007-3725
|
| Created: | July 24, 2007 |
Updated: | February 27, 2008 |
| Description: |
A NULL pointer dereference has been discovered in the RAR VM of Clam
Antivirus (ClamAV) which allows user-assisted remote attackers to
cause a denial of service via a specially crafted RAR archives. |
| Alerts: |
|
Comments (none posted)
clamav: multiple vulnerabilities
| Package(s): | clamav |
CVE #(s): | CVE-2007-4510
CVE-2007-4560
|
| Created: | September 3, 2007 |
Updated: | February 13, 2008 |
| Description: |
Several remote vulnerabilities have been discovered in the Clam anti-virus
toolkit. The Common Vulnerabilities and Exposures project identifies the
following problems:
CVE-2007-4510:
It was discovered that the RTF and RFC2397 parsers can be tricked
into dereferencing a NULL pointer, resulting in denial of service.
CVE-2007-4560:
It was discovered clamav-milter performs insufficient input
sanitizing, resulting in the execution of arbitrary shell commands.
|
| Alerts: |
|
Comments (none posted)
cups: denial of service
| Package(s): | cups |
CVE #(s): | CVE-2007-0720
|
| Created: | March 26, 2007 |
Updated: | February 7, 2008 |
| Description: |
Previous versions of the cups package could be forced to hang via a client
"partially negotiating" an ssl connection. In this state, cups would not
allow other connections to be made, a denial of service. |
| Alerts: |
|
Comments (none posted)
gpdf: integer overflow
| Package(s): | cups poppler xpdf |
CVE #(s): | CVE-2007-3387
|
| Created: | July 31, 2007 |
Updated: | November 28, 2007 |
| Description: |
The gpdf library contains an integer overflow which can be exploited via a malicious PDF file. This code finds its way into multiple packages, including xpdf, kpdf, poppler, cups, and more. |
| Alerts: |
|
Comments (1 posted)
debian-goodies: privilege escalation
| Package(s): | debian-goodies |
CVE #(s): | CVE-2007-3912
|
| Created: | October 5, 2007 |
Updated: | March 24, 2008 |
| Description: |
Thomas de Grenier de Latour discovered that the checkrestart program included
in debian-goodies did not correctly handle shell meta-characters. A local
attacker could exploit this to gain the privileges of the user running
checkrestart. |
| Alerts: |
|
Comments (none posted)
dovecot: privilege escalation
| Package(s): | dovecot |
CVE #(s): | CVE-2007-4211
|
| Created: | August 15, 2007 |
Updated: | May 21, 2008 |
| Description: |
From the rPath advisory: "Previous versions of the dovecot package are vulnerable to a
minor privilege escalation attack in which an authenticated
user may exploit an ACL plugin weakness to save message flags
without having proper permissions." |
| Alerts: |
|
Comments (none posted)
dovecot: directory traversal
| Package(s): | dovecot |
CVE #(s): | CVE-2007-2231
|
| Created: | May 8, 2007 |
Updated: | May 21, 2008 |
| Description: |
Directory traversal vulnerability in index/mbox/mbox-storage.c in Dovecot
before 1.0.rc29, when using the zlib plugin, allows remote attackers to
read arbitrary gzipped (.gz) mailboxes (mbox files) via a .. (dot dot)
sequence in the mailbox name. |
| Alerts: |
|
Comments (none posted)
eggdrop: stack-based buffer overflow
| Package(s): | eggdrop |
CVE #(s): | CVE-2007-2807
|
| Created: | September 7, 2007 |
Updated: | January 7, 2008 |
| Description: |
A stack-based buffer overflow in mod/server.mod/servrmsg.c in Eggdrop
1.6.18, and possibly earlier, allows user-assisted, malicious remote IRC
servers to execute arbitrary code via a long private message. |
| Alerts: |
|
Comments (none posted)
evolution: format string error
| Package(s): | evolution |
CVE #(s): | CVE-2007-1002
|
| Created: | March 27, 2007 |
Updated: | February 27, 2008 |
| Description: |
A format string error in the "write_html()" function in calendar/gui/
e-cal-component-memo-preview.c when displaying a memo's categories can
potentially be exploited to execute arbitrary code via a specially crafted
shared memo containing format specifiers. |
| Alerts: |
|
Comments (1 posted)
evolution-data-server: malicious server arbitrary code execution
| Package(s): | evolution-data-server |
CVE #(s): | CVE-2007-3257
|
| Created: | June 18, 2007 |
Updated: | November 7, 2007 |
| Description: |
From the GNOME
bugzilla: "The "SEQUENCE" value in the GData of the IMAP code
(camel-imap-folder.c) is converted from a string using strtol. This allows
for negative values. The imap_rescan uses this value as an int. It checks
for !seq and seq>summary.length. It doesn't check for seq <
0. Although seq is used as the index of an array." |
| Alerts: |
|
Comments (1 posted)
file: integer overflow
| Package(s): | file |
CVE #(s): | CVE-2007-2799
|
| Created: | June 1, 2007 |
Updated: | October 19, 2007 |
| Description: |
Colin Percival from FreeBSD reported that the previous fix for the
file_printf() buffer overflow introduced a new integer overflow. A remote
attacker could entice a user to run the file program on an overly large
file (more than 1Gb) that would trigger an integer overflow on 32-bit
systems, possibly leading to the execution of arbitrary code with the
rights of the user running file. |
| Alerts: |
|
Comments (3 posted)
firebird: buffer overflow
| Package(s): | firebird |
CVE #(s): | CVE-2007-3181
|
| Created: | July 2, 2007 |
Updated: | March 27, 2008 |
| Description: |
The Firebird DBMS has a buffer overflow vulnerability involving
the processing of connect requests with an overly large p_cnct_count
value. Remote attackers can send a specially crafted
request to the server in order to potentially execute arbitrary code with
the permissions of the Firebird user. |
| Alerts: |
|
Comments (none posted)
firefox: multiple vulnerabilities
| Package(s): | firefox |
CVE #(s): | CVE-2007-3844
CVE-2007-3845
|
| Created: | August 1, 2007 |
Updated: | February 20, 2008 |
| Description: |
A flaw was discovered in handling of "about:blank" windows used by
addons. A malicious web site could exploit this to modify the contents,
or steal confidential data (such as passwords), of other web pages.
(CVE-2007-3844)
Jesper Johansson discovered that spaces and double-quotes were
not correctly handled when launching external programs. In rare
configurations, after tricking a user into opening a malicious web page,
an attacker could execute helpers with arbitrary arguments with the
user's privileges. (CVE-2007-3845) |
| Alerts: |
|
Comments (none posted)
firefox, thunderbird, seamonkey: multiple vulnerabilities