mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-28 01:15:15 +07:00
a7ddcea58a
This is a respin with a wider audience (all that get_maintainer returned) and I know this spams a *lot* of people. Not sure what would be the correct way, so my apologies for ruining your inbox. The 00-INDEX files are supposed to give a summary of all files present in a directory, but these files are horribly out of date and their usefulness is brought into question. Often a simple "ls" would reveal the same information as the filenames are generally quite descriptive as a short introduction to what the file covers (it should not surprise anyone what Documentation/sched/sched-design-CFS.txt covers) A few years back it was mentioned that these files were no longer really needed, and they have since then grown further out of date, so perhaps it is time to just throw them out. A short status yields the following _outdated_ 00-INDEX files, first counter is files listed in 00-INDEX but missing in the directory, last is files present but not listed in 00-INDEX. List of outdated 00-INDEX: Documentation: (4/10) Documentation/sysctl: (0/1) Documentation/timers: (1/0) Documentation/blockdev: (3/1) Documentation/w1/slaves: (0/1) Documentation/locking: (0/1) Documentation/devicetree: (0/5) Documentation/power: (1/1) Documentation/powerpc: (0/5) Documentation/arm: (1/0) Documentation/x86: (0/9) Documentation/x86/x86_64: (1/1) Documentation/scsi: (4/4) Documentation/filesystems: (2/9) Documentation/filesystems/nfs: (0/2) Documentation/cgroup-v1: (0/2) Documentation/kbuild: (0/4) Documentation/spi: (1/0) Documentation/virtual/kvm: (1/0) Documentation/scheduler: (0/2) Documentation/fb: (0/1) Documentation/block: (0/1) Documentation/networking: (6/37) Documentation/vm: (1/3) Then there are 364 subdirectories in Documentation/ with several files that are missing 00-INDEX alltogether (and another 120 with a single file and no 00-INDEX). I don't really have an opinion to whether or not we /should/ have 00-INDEX, but the above 00-INDEX should either be removed or be kept up to date. If we should keep the files, I can try to keep them updated, but I rather not if we just want to delete them anyway. As a starting point, remove all index-files and references to 00-INDEX and see where the discussion is going. Signed-off-by: Henrik Austad <henrik@austad.us> Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Just-do-it-by: Steven Rostedt <rostedt@goodmis.org> Reviewed-by: Jens Axboe <axboe@kernel.dk> Acked-by: Paul Moore <paul@paul-moore.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: [Almost everybody else] Signed-off-by: Jonathan Corbet <corbet@lwn.net>
50 lines
2.2 KiB
Plaintext
50 lines
2.2 KiB
Plaintext
NetLabel CIPSO/IPv4 Protocol Engine
|
|
==============================================================================
|
|
Paul Moore, paul.moore@hp.com
|
|
|
|
May 17, 2006
|
|
|
|
* Overview
|
|
|
|
The NetLabel CIPSO/IPv4 protocol engine is based on the IETF Commercial
|
|
IP Security Option (CIPSO) draft from July 16, 1992. A copy of this
|
|
draft can be found in this directory
|
|
(draft-ietf-cipso-ipsecurity-01.txt). While the IETF draft never made
|
|
it to an RFC standard it has become a de-facto standard for labeled
|
|
networking and is used in many trusted operating systems.
|
|
|
|
* Outbound Packet Processing
|
|
|
|
The CIPSO/IPv4 protocol engine applies the CIPSO IP option to packets by
|
|
adding the CIPSO label to the socket. This causes all packets leaving the
|
|
system through the socket to have the CIPSO IP option applied. The socket's
|
|
CIPSO label can be changed at any point in time, however, it is recommended
|
|
that it is set upon the socket's creation. The LSM can set the socket's CIPSO
|
|
label by using the NetLabel security module API; if the NetLabel "domain" is
|
|
configured to use CIPSO for packet labeling then a CIPSO IP option will be
|
|
generated and attached to the socket.
|
|
|
|
* Inbound Packet Processing
|
|
|
|
The CIPSO/IPv4 protocol engine validates every CIPSO IP option it finds at the
|
|
IP layer without any special handling required by the LSM. However, in order
|
|
to decode and translate the CIPSO label on the packet the LSM must use the
|
|
NetLabel security module API to extract the security attributes of the packet.
|
|
This is typically done at the socket layer using the 'socket_sock_rcv_skb()'
|
|
LSM hook.
|
|
|
|
* Label Translation
|
|
|
|
The CIPSO/IPv4 protocol engine contains a mechanism to translate CIPSO security
|
|
attributes such as sensitivity level and category to values which are
|
|
appropriate for the host. These mappings are defined as part of a CIPSO
|
|
Domain Of Interpretation (DOI) definition and are configured through the
|
|
NetLabel user space communication layer. Each DOI definition can have a
|
|
different security attribute mapping table.
|
|
|
|
* Label Translation Cache
|
|
|
|
The NetLabel system provides a framework for caching security attribute
|
|
mappings from the network labels to the corresponding LSM identifiers. The
|
|
CIPSO/IPv4 protocol engine supports this caching mechanism.
|