[PATCH] Documentation/process: Clarify disclosure rules
The role of the contact list provided by the disclosing party and how it affects the disclosure process and the ability to include experts into the development process is not really well explained. Neither is it entirely clear when the disclosing party will be informed about the fact that a developer who is not covered by an employer NDA needs to be brought in and disclosed. Explain the role of the contact list and the information policy along with an eventual conflict resolution better. Reported-by: Dave Hansen Signed-off-by: Thomas Gleixner --- Documentation/process/embargoed-hardware-issues.rst | 40 1 file changed, 33 insertions(+), 7 deletions(-) --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -143,6 +143,20 @@ via their employer, they cannot enter in in their role as Linux kernel developers. They will, however, agree to adhere to this documented process and the Memorandum of Understanding. +The disclosing party should provide a list of contacts for all other +entities who have already been, or should be, informed about the issue. +This serves several purposes: + + - The list of disclosed entities allows communication accross the + industry, e.g. other OS vendors, HW vendors, etc. + + - The disclosed entities can be contacted to name experts who should + participate in the mitigation development. + + - If an expert which is required to handle an issue is employed by an + listed entity or member of an listed entity, then the response teams can + request the disclosure of that expert from that entity. This ensures + that the expert is also part of the entity's response team. Disclosure "" @@ -158,10 +172,7 @@ Mitigation development "" The initial response team sets up an encrypted mailing-list or repurposes -an existing one if appropriate. The disclosing party should provide a list -of contacts for all other parties who have already been, or should be, -informed about the issue. The response team contacts these parties so they -can name experts who should be subscribed to the mailing-list. +an existing one if appropriate. Using a mailing-list is close to the normal Linux development process and has been successfully used in developing mitigations for various hardware @@ -175,9 +186,24 @@ development branch against the mainline stable kernel versions as necessary. The initial response team will identify further experts from the Linux -kernel developer community as needed and inform the disclosing party about -their participation. Bringing in experts can happen at any time of the -development process and often needs to be handled in a timely manner. +kernel developer community as needed. Bringing in experts can happen at any +time of the development process and needs to be handled in a timely manner. + +If an expert is employed by or member of an entity on the disclosure list +provided by the disclosing party, then participation will be requested from +the relevant entity. + +If not, then the disclosing party will be informed about the experts +participation. The experts are covered by the Memorandum of Understanding +and the disclosing party is requested to acknowledge the participation. In +case that the disclosing party has a compelling reason to object, then this +objection has to be raised within five work days and resolved with the +incident team immediately. If the disclosing party does not react within +five work days this is taken as silent acknowledgement. + +After acknowledgement or resolution of an objection the expert is disclosed +by the incident team and brought into the development process. + Coordinated release """
Re: [PATCH v2] docs: Use make invocation's -j argument for parallelism
On Tue, 24 Sep 2019, Kees Cook wrote: > On Tue, Sep 24, 2019 at 10:12:22AM +0300, Jani Nikula wrote: >> On Mon, 23 Sep 2019, Kees Cook wrote: >> > On Sun, Sep 22, 2019 at 02:03:31PM -0600, Jonathan Corbet wrote: >> >> On Thu, 19 Sep 2019 14:44:37 -0700 >> >> Kees Cook wrote: >> >> >> >> > While sphinx 1.7 and later supports "-jauto" for parallelism, this >> >> > effectively ignores the "-j" flag used in the "make" invocation, which >> >> > may cause confusion for build systems. Instead, extract the available >> >> >> >> What sort of confusion might we expect? Or, to channel akpm, "what are >> >> the >> >> user-visible effects of this bug"? >> > >> > When I run "make htmldocs -j16" with a pre-1.7 sphinx, it is not >> > parallelized. When I run "make htmldocs -j8" with 1.7+ sphinx, it uses >> > all my CPUs instead of 8. :) >> >> To be honest, part of the solution should be to require Sphinx 1.8 or >> later. Even Debian stable has it. If your distro doesn't have it >> (really?), using the latest Sphinx in a virtual environment should be a >> matter of: >> >> $ python3 -m venv .venv >> $ . .venv/bin/activate >> (.venv) $ pip install sphinx sphinx_rtd_theme >> (.venv) $ make htmldocs > > I don't mind having sphinx 1.8 (I did, in fact, already update it), but > that still doesn't solve the whole problem: my -j argument is being > ignored... I meant, *part* of the solution should be to not have to deal with ancient Sphinx. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[PATCH 1/2] docs: security: fix section hyperlink
From: Brendan Jackman The reStructuredText syntax is wrong here; not sure how it was intended but we can just use the section header as an implicit hyperlink target, with a single "outward" underscore. Signed-off-by: Brendan Jackman Cc: Jonathan Corbet --- Documentation/security/lsm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/security/lsm.rst b/Documentation/security/lsm.rst index ad4dfd020e0d..aadf47c808c0 100644 --- a/Documentation/security/lsm.rst +++ b/Documentation/security/lsm.rst @@ -56,7 +56,7 @@ the infrastructure to support security modules. The LSM kernel patch also moves most of the capabilities logic into an optional security module, with the system defaulting to the traditional superuser logic. This capabilities module is discussed further in -`LSM Capabilities Module <#cap>`__. +`LSM Capabilities Module`_. The LSM kernel patch adds security fields to kernel data structures and inserts calls to hook functions at critical points in the kernel code to -- 2.22.1
[PATCH 2/2] docs: security: update base LSM documentation file
From: Brendan Jackman
I was bringing myself up to speed on LSMs and discovered that this
base doc file is out of date. Unless I'm mistaken the "stacking"
functionality is still in significant flux (and also I am of course a
newbie here) so I haven't really _added_ any info, mainly this patch
removes misleading bits and fixes rotten references.
- Since commit b1d9e6b0646d ("LSM: Switch to lists of hooks") as
part of the work helpfully summarised in [1], the LSM hooks are
stored in a table of hlists, the security_ops structure is
gone. The stacking of security modules no longer seems to be
deferred to the module.
- security_hooks_heads, née security_ops, doesn't have the
sub-structures described here. The "future" flattening described
here appears to have happened a long time ago (In my hasty git
archaeology session I didn't find the old code at all).
- There used to be a dummy LSM implementing "traditional superuser
logic", with the "capability" LSM as an optional layer, but since
commit 5915eb53861c ("security: remove dummy module") that is no
longer the case.
[1] https://lwn.net/Articles/635771/
Cc: Casey Schaufler
Cc: Kees Cook
Cc: Jonathan Corbet
Signed-off-by: Brendan Jackman
---
Documentation/security/lsm.rst | 94 +++---
1 file changed, 31 insertions(+), 63 deletions(-)
diff --git a/Documentation/security/lsm.rst b/Documentation/security/lsm.rst
index aadf47c808c0..5048143d3656 100644
--- a/Documentation/security/lsm.rst
+++ b/Documentation/security/lsm.rst
@@ -53,10 +53,8 @@ on supporting access control modules, although future
development is
likely to address other security needs such as auditing. By itself, the
framework does not provide any additional security; it merely provides
the infrastructure to support security modules. The LSM kernel patch
-also moves most of the capabilities logic into an optional security
-module, with the system defaulting to the traditional superuser logic.
-This capabilities module is discussed further in
-`LSM Capabilities Module`_.
+also moves most of the capabilities logic into a security
+module, discussed further in `LSM Capabilities Module`_.
The LSM kernel patch adds security fields to kernel data structures and
inserts calls to hook functions at critical points in the kernel code to
@@ -84,19 +82,13 @@ were moved to header files (``include/linux/msg.h`` and
``include/linux/shm.h`` as appropriate) to allow the security modules to
use these definitions.
-Each LSM hook is a function pointer in a global table, security_ops.
-This table is a :c:type:`struct security_operations
-` structure as defined by
-``include/linux/security.h``. Detailed documentation for each hook is
-included in this header file. At present, this structure consists of a
-collection of substructures that group related hooks based on the kernel
-object (e.g. task, inode, file, sk_buff, etc) as well as some top-level
-hook function pointers for system operations. This structure is likely
-to be flattened in the future for performance. The placement of the hook
-calls in the kernel code is described by the "called:" lines in the
-per-hook documentation in the header file. The hook calls can also be
-easily found in the kernel code by looking for the string
-"security_ops->".
+Each LSM hook is a function pointer within a ``hlist`` in a global
+table, ``security_hook_heads``. This table is a :c:type:`struct
+security_hook_heads ` structure as defined by
+``include/linux/lsm_hooks.h``. Detailed documentation for each hook
+is included in this header file. The placement of the hook calls in
+the kernel code is described by the "called:" lines in the per-hook
+documentation in the header file.
Linus mentioned per-process security hooks in his original remarks as a
possible alternative to global security hooks. However, if LSM were to
@@ -107,64 +99,40 @@ controlling the operation. This would require a general
mechanism for
composing hooks in the base framework. Additionally, LSM would still
need global hooks for operations that have no process context (e.g.
network input operations). Consequently, LSM provides global security
-hooks, but a security module is free to implement per-process hooks
-(where that makes sense) by storing a security_ops table in each
-process' security field and then invoking these per-process hooks from
-the global hooks. The problem of composition is thus deferred to the
-module.
-
-The global security_ops table is initialized to a set of hook functions
-provided by a dummy security module that provides traditional superuser
-logic. A :c:func:`register_security()` function (in
-``security/security.c``) is provided to allow a security module to set
-security_ops to refer to its own hook functions, and an
-:c:func:`unregister_security()` function is provided to revert
-security_ops to the dummy module hooks. This mechanism is used to set
-the primary security module, which is respo
[PATCH] docs: hwmon: Include 'inspur-ipsps1.rst' into docs
When generating documentation output Sphinx outputs a warning for not including the page 'inspur-ipsps1.rst' in 'index.rst'. Assuming this documentation is useful it should be included in the index. Signed-off-by: Adam Zerella --- Documentation/hwmon/index.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 8147c3f218bf..230ad59b462b 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -7,6 +7,7 @@ Linux Hardware Monitoring hwmon-kernel-api pmbus-core + inspur-ipsps1 submitting-patches sysfs-interface userspace-tools -- 2.21.0
[PATCH] docs: kmemleak: DEBUG_KMEMLEAK_EARLY_LOG_SIZE changed names
Commit c5665868183f ("mm: kmemleak: use the memory pool for early
allocations") renamed CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE to
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE. Update the documentation reference
to reflect that.
Signed-off-by: Jeremy Cline
---
Documentation/dev-tools/kmemleak.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/kmemleak.rst
b/Documentation/dev-tools/kmemleak.rst
index 3621cd5e1eef..3a289e8a1d12 100644
--- a/Documentation/dev-tools/kmemleak.rst
+++ b/Documentation/dev-tools/kmemleak.rst
@@ -69,7 +69,7 @@ the kernel command line.
Memory may be allocated or freed before kmemleak is initialised and
these actions are stored in an early log buffer. The size of this buffer
-is configured via the CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE option.
+is configured via the CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE option.
If CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF are enabled, the kmemleak is
disabled by default. Passing ``kmemleak=on`` on the kernel command
--
2.21.0
Re: [PATCH] docs: kmemleak: DEBUG_KMEMLEAK_EARLY_LOG_SIZE changed names
On Wed, Sep 25, 2019 at 02:31:14PM +, Jeremy Cline wrote:
> Commit c5665868183f ("mm: kmemleak: use the memory pool for early
> allocations") renamed CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE to
> CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE. Update the documentation reference
> to reflect that.
>
> Signed-off-by: Jeremy Cline
I forgot about this. Thanks.
Acked-by: Catalin Marinas
Re: [PATCH v3] printf: add support for printing symbolic error codes
First, I am sorry that I replay so late. I was traveling the previous
two weeks and was not able to follow the discussion about this patch.
I am fine with adding this feature. But I would like to do it
a cleaner way, see below.
On Tue 2019-09-17 08:59:59, Rasmus Villemoes wrote:
> With my embedded hat on, I've made it possible to remove this.
>
> I've tested that the #ifdeffery in errcode.c is sufficient to make
> this compile on arm, arm64, mips, powerpc, s390, x86 - I'm sure the
> 0day bot will tell me which ones I've missed.
Please, remove the above two paragraphs in the final patch. They make
sense for review but not for git history.
> Andrew: please consider picking this up, even if we're already in the
> merge window. Quite a few people have said they'd like to see
> something like this, it's a debug improvement in its own right (the
> "ERR_PTR accidentally passed to printf" case), the printf tests pass,
> and it's much easier to start adding (and testing) users around the
> tree once this is in master.
This change would deserve to spend some time in linux-next. Anyway,
it is already too late for 5.4.
> diff --git a/include/linux/errcode.h b/include/linux/errcode.h
> new file mode 100644
> index ..c6a4c1b04f9c
> --- /dev/null
> +++ b/include/linux/errcode.h
The word "code" is quite ambiguous. I am not sure if it is the name or
the number. I think that it is actually both (the relation between
the two.
Both "man 3 errno" and
https://www.gnu.org/software/libc/manual/html_node/Checking-for-Errors.html#Checking-for-Errors
talks about numbers and symbolic names.
Please use errname or so instead of errcode everywhere.
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 5960e2980a8a..dc1b20872774 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -164,6 +164,14 @@ config DYNAMIC_DEBUG
> See Documentation/admin-guide/dynamic-debug-howto.rst for additional
> information.
>
> +config SYMBOLIC_ERRCODE
What is the exact reason to make this configurable, please?
Nobody was really against this feature. The only question
was if it was worth the code complexity and maintenance.
If we are going to have the code then we should use it.
Then there was a concerns that it might be too big for embedded
people. But did it come from people working on embedded kernel
or was it just theoretical?
I would personally enable it when CONFIG_PRINTK is enabled.
We could always introduce a new config option later when
anyone really wants to disable it.
> --- /dev/null
> +++ b/lib/errcode.c
> @@ -0,0 +1,212 @@
> +#define E(err) [err + BUILD_BUG_ON_ZERO(err <= 0 || err > 300)] = #err
> +static const char *codes_0[] = {
> + E(E2BIG),
I really like the way how the array is initialized.
> diff --git a/lib/test_printf.c b/lib/test_printf.c
> index 944eb50f3862..0401a2341245 100644
> --- a/lib/test_printf.c
> +++ b/lib/test_printf.c
> +static void __init
> +errptr(void)
> +{
> + test("-1234", "%p", ERR_PTR(-1234));
> + test(S " " S "ff00", "%px %px", ERR_PTR(-1),
> ERR_PTR(-256));
> +#ifdef CONFIG_SYMBOLIC_ERRCODE
> + test("EIO EINVAL ENOSPC", "%p %p %p", ERR_PTR(-EIO), ERR_PTR(-EINVAL),
> ERR_PTR(-ENOSPC));
> + test("EAGAIN EAGAIN", "%p %p", ERR_PTR(-EAGAIN), ERR_PTR(-EWOULDBLOCK));
I like that you check more values. But please split it to check
only one value per line to make it better readable.
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index b0967cf17137..299fce317eb3 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -2111,6 +2112,31 @@ static noinline_for_stack
> char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> struct printf_spec spec)
> {
> + /*
> + * If it's an ERR_PTR, try to print its symbolic
> + * representation, except for %px, where the user explicitly
> + * wanted the pointer formatted as a hex value.
> + */
> + if (IS_ERR(ptr) && *fmt != 'x') {
We had similar code before the commit 3e5903eb9cff70730171 ("vsprintf:
Prevent crash when dereferencing invalid pointers"). Note that the
original code kept the original value also for *fmt == 'K'.
Anyway, the above commit tried to unify the handling of special
values:
+ use the same strings for special values
+ check for special values only when pointer is dereferenced
This patch makes it inconsistent again. I mean that the code will:
+ check for (null) and (efault) only when the pointer is
dereferenced
+ check for err codes in more situations but not in all
and not in %s
+ use another style to print the error (uppercase without
brackets)
I would like to keep it consistent. My proposal is:
1. Print the plain error code name only when
a new %pe modifier is used. This will be useful
in the error messages, e.g.
void *p = ERR_PTR(-ENOMEM);
if (IS_ERR(foo)) {
pr_err("Sorry, can't do that: %pe\n", foo);
return PTR_E
Re: [PATCH] Documentation/process: Clarify disclosure rules
On 9/25/19 1:29 AM, Thomas Gleixner wrote: > The role of the contact list provided by the disclosing party and how it > affects the disclosure process and the ability to include experts into > the development process is not really well explained. > > Neither is it entirely clear when the disclosing party will be informed > about the fact that a developer who is not covered by an employer NDA needs > to be brought in and disclosed. > > Explain the role of the contact list and the information policy along with > an eventual conflict resolution better. This addresses the concerns I had about individuals who the community needs to participate but which might be encumbered by an agreement between their employer and the disclosing party. To be explicit, this ack does not represent any official Intel position and has not been reviewed by anyone at Intel other than me. Acked-by: Dave Hansen
[PATCH] docs: fix memory.low description in cgroup-v2.rst
The current cgroup-v2.rst file contains an incorrect description of when
memory is reclaimed from a cgroup that is using the 'memory.low'
mechanism. This fix simply corrects the text to reflect the actual
implementation.
Fixes: 7854207fe954 ("mm/docs: describe memory.low refinements")
Signed-off-by: Jon Haslam
---
Documentation/admin-guide/cgroup-v2.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index 0fa8c0e615c2..26d1cde6b34a 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1117,8 +1117,8 @@ PAGE_SIZE multiple when read back.
Best-effort memory protection. If the memory usage of a
cgroup is within its effective low boundary, the cgroup's
- memory won't be reclaimed unless memory can be reclaimed
- from unprotected cgroups.
+ memory won't be reclaimed unless there is no reclaimable
+ memory available in unprotected cgroups.
Effective low boundary is limited by memory.low values of
all ancestor cgroups. If there is memory.low overcommitment
@@ -1914,7 +1914,7 @@ Cpuset Interface Files
It accepts only the following input values when written to.
-"root" - a paritition root
+"root" - a partition root
"member" - a non-root member of a partition
When set to be a partition root, the current cgroup is the
--
2.17.1
Re: [PATCH] docs: fix memory.low description in cgroup-v2.rst
On Wed, Sep 25, 2019 at 12:56:04PM -0700, Jon Haslam wrote:
> The current cgroup-v2.rst file contains an incorrect description of when
> memory is reclaimed from a cgroup that is using the 'memory.low'
> mechanism. This fix simply corrects the text to reflect the actual
> implementation.
>
> Fixes: 7854207fe954 ("mm/docs: describe memory.low refinements")
> Signed-off-by: Jon Haslam
Acked-by: Roman Gushchin
Thanks, Jon!
> ---
> Documentation/admin-guide/cgroup-v2.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst
> b/Documentation/admin-guide/cgroup-v2.rst
> index 0fa8c0e615c2..26d1cde6b34a 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -1117,8 +1117,8 @@ PAGE_SIZE multiple when read back.
>
> Best-effort memory protection. If the memory usage of a
> cgroup is within its effective low boundary, the cgroup's
> - memory won't be reclaimed unless memory can be reclaimed
> - from unprotected cgroups.
> + memory won't be reclaimed unless there is no reclaimable
> + memory available in unprotected cgroups.
>
> Effective low boundary is limited by memory.low values of
> all ancestor cgroups. If there is memory.low overcommitment
> @@ -1914,7 +1914,7 @@ Cpuset Interface Files
>
> It accepts only the following input values when written to.
>
> -"root" - a paritition root
> +"root" - a partition root
> "member" - a non-root member of a partition
>
> When set to be a partition root, the current cgroup is the
> --
> 2.17.1
>
Re: [PATCH 2/2] docs: security: update base LSM documentation file
On Wed, Sep 25, 2019 at 05:17:45PM +0700, bhenryj0...@gmail.com wrote:
> From: Brendan Jackman
>
> I was bringing myself up to speed on LSMs and discovered that this
> base doc file is out of date. Unless I'm mistaken the "stacking"
> functionality is still in significant flux (and also I am of course a
> newbie here) so I haven't really _added_ any info, mainly this patch
> removes misleading bits and fixes rotten references.
>
> - Since commit b1d9e6b0646d ("LSM: Switch to lists of hooks") as
>part of the work helpfully summarised in [1], the LSM hooks are
>stored in a table of hlists, the security_ops structure is
>gone. The stacking of security modules no longer seems to be
>deferred to the module.
>
> - security_hooks_heads, née security_ops, doesn't have the
>sub-structures described here. The "future" flattening described
>here appears to have happened a long time ago (In my hasty git
>archaeology session I didn't find the old code at all).
>
> - There used to be a dummy LSM implementing "traditional superuser
>logic", with the "capability" LSM as an optional layer, but since
>commit 5915eb53861c ("security: remove dummy module") that is no
>longer the case.
Oh very nice; yes, thank you. This is all very out of date. Notes
below...
>
> [1] https://lwn.net/Articles/635771/
>
> Cc: Casey Schaufler
> Cc: Kees Cook
> Cc: Jonathan Corbet
> Signed-off-by: Brendan Jackman
> ---
> Documentation/security/lsm.rst | 94 +++---
> 1 file changed, 31 insertions(+), 63 deletions(-)
>
> diff --git a/Documentation/security/lsm.rst b/Documentation/security/lsm.rst
> index aadf47c808c0..5048143d3656 100644
> --- a/Documentation/security/lsm.rst
> +++ b/Documentation/security/lsm.rst
> @@ -53,10 +53,8 @@ on supporting access control modules, although future
> development is
> likely to address other security needs such as auditing. By itself, the
> framework does not provide any additional security; it merely provides
> the infrastructure to support security modules. The LSM kernel patch
> -also moves most of the capabilities logic into an optional security
> -module, with the system defaulting to the traditional superuser logic.
> -This capabilities module is discussed further in
> -`LSM Capabilities Module`_.
> +also moves most of the capabilities logic into a security
> +module, discussed further in `LSM Capabilities Module`_.
>
> The LSM kernel patch adds security fields to kernel data structures and
> inserts calls to hook functions at critical points in the kernel code to
> @@ -84,19 +82,13 @@ were moved to header files (``include/linux/msg.h`` and
> ``include/linux/shm.h`` as appropriate) to allow the security modules to
> use these definitions.
>
> -Each LSM hook is a function pointer in a global table, security_ops.
> -This table is a :c:type:`struct security_operations
> -` structure as defined by
> -``include/linux/security.h``. Detailed documentation for each hook is
> -included in this header file. At present, this structure consists of a
> -collection of substructures that group related hooks based on the kernel
> -object (e.g. task, inode, file, sk_buff, etc) as well as some top-level
> -hook function pointers for system operations. This structure is likely
> -to be flattened in the future for performance. The placement of the hook
> -calls in the kernel code is described by the "called:" lines in the
> -per-hook documentation in the header file. The hook calls can also be
> -easily found in the kernel code by looking for the string
> -"security_ops->".
> +Each LSM hook is a function pointer within a ``hlist`` in a global
> +table, ``security_hook_heads``. This table is a :c:type:`struct
> +security_hook_heads ` structure as defined by
> +``include/linux/lsm_hooks.h``. Detailed documentation for each hook
> +is included in this header file. The placement of the hook calls in
> +the kernel code is described by the "called:" lines in the per-hook
> +documentation in the header file.
>
> Linus mentioned per-process security hooks in his original remarks as a
> possible alternative to global security hooks. However, if LSM were to
> @@ -107,64 +99,40 @@ controlling the operation. This would require a general
> mechanism for
> composing hooks in the base framework. Additionally, LSM would still
> need global hooks for operations that have no process context (e.g.
> network input operations). Consequently, LSM provides global security
> -hooks, but a security module is free to implement per-process hooks
> -(where that makes sense) by storing a security_ops table in each
> -process' security field and then invoking these per-process hooks from
> -the global hooks. The problem of composition is thus deferred to the
> -module.
> -
> -The global security_ops table is initialized to a set of hook functions
> -provided by a dummy security module that provides traditional superuser
> -logic. A :c:func:`register
[RFC PATCH] x86/doc/boot_protocol: Correct the description of "reloc"
The fields marked with (reloc) actually are not dedicated for writing,
but communicating info for relocatable kernel with boot loaders. For
example:
Field name: pref_address
Type: read (reloc)
Offset/size:0x258/8
Protocol: 2.10+
Field name: code32_start
Type: modify (optional, reloc)
Offset/size:0x214/4
Protocol: 2.00+
Signed-off-by: Cao jin
---
Unless I have incorrect non-native understanding for "fill in", I think
this is inaccurate.
Documentation/x86/boot.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index 08a2f100c0e6..a611bf04492d 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -243,7 +243,7 @@ bootloader ("modify").
All general purpose boot loaders should write the fields marked
(obligatory). Boot loaders who want to load the kernel at a
-nonstandard address should fill in the fields marked (reloc); other
+nonstandard address should consult with the fields marked (reloc); other
boot loaders can ignore those fields.
The byte order of all fields is littleendian (this is x86, after all.)
--
2.21.0
Re: [RFC PATCH] x86/doc/boot_protocol: Correct the description of "reloc"
* Cao jin wrote:
> The fields marked with (reloc) actually are not dedicated for writing,
> but communicating info for relocatable kernel with boot loaders. For
> example:
>
>
> Field name: pref_address
> Type: read (reloc)
> Offset/size:0x258/8
> Protocol: 2.10+
>
>
>
> Field name: code32_start
> Type: modify (optional, reloc)
> Offset/size:0x214/4
> Protocol: 2.00+
>
>
> Signed-off-by: Cao jin
> ---
> Unless I have incorrect non-native understanding for "fill in", I think
> this is inaccurate.
>
> Documentation/x86/boot.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> index 08a2f100c0e6..a611bf04492d 100644
> --- a/Documentation/x86/boot.rst
> +++ b/Documentation/x86/boot.rst
> @@ -243,7 +243,7 @@ bootloader ("modify").
>
> All general purpose boot loaders should write the fields marked
> (obligatory). Boot loaders who want to load the kernel at a
> -nonstandard address should fill in the fields marked (reloc); other
> +nonstandard address should consult with the fields marked (reloc); other
> boot loaders can ignore those fields.
>
> The byte order of all fields is littleendian (this is x86, after all.)
Well, this documentation is written from the point of view of a
*bootloader*, not the kernel. So the 'fill in' says that the bootloader
should write those fields - which is correct, right?
Thanks,
Ingo
Re: [RFC PATCH] x86/doc/boot_protocol: Correct the description of "reloc"
On September 25, 2019 11:01:39 PM PDT, Ingo Molnar wrote:
>* Cao jin wrote:
>
>> The fields marked with (reloc) actually are not dedicated for
>writing,
>> but communicating info for relocatable kernel with boot loaders. For
>> example:
>>
>>
>> Field name: pref_address
>> Type: read (reloc)
>> Offset/size:0x258/8
>> Protocol: 2.10+
>>
>>
>>
>> Field name: code32_start
>> Type: modify (optional, reloc)
>> Offset/size:0x214/4
>> Protocol: 2.00+
>>
>>
>> Signed-off-by: Cao jin
>> ---
>> Unless I have incorrect non-native understanding for "fill in", I
>think
>> this is inaccurate.
>>
>> Documentation/x86/boot.rst | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
>> index 08a2f100c0e6..a611bf04492d 100644
>> --- a/Documentation/x86/boot.rst
>> +++ b/Documentation/x86/boot.rst
>> @@ -243,7 +243,7 @@ bootloader ("modify").
>>
>> All general purpose boot loaders should write the fields marked
>> (obligatory). Boot loaders who want to load the kernel at a
>> -nonstandard address should fill in the fields marked (reloc); other
>> +nonstandard address should consult with the fields marked (reloc);
>other
>> boot loaders can ignore those fields.
>>
>> The byte order of all fields is littleendian (this is x86, after
>all.)
>
>Well, this documentation is written from the point of view of a
>*bootloader*, not the kernel. So the 'fill in' says that the bootloader
>
>should write those fields - which is correct, right?
>
>Thanks,
>
> Ingo
This is correct.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
