[EMAIL PROTECTED] wrote:
On Mon, 28 Feb 2005 15:41:57 +1100, O Plameras
<[EMAIL PROTECTED]> wrote:
1. In CONFIG_????=y I am telling the kernel load the modules at
boot time; in CONFIG_MODULES=n I am telling the kernel
Are you sure about that?
I was always (and I've been compiling Linux kernels for over ten years
now) under the impression that when a device driver or whatever is
compiled into the kernel then its code is put right inside the single kernel
code file and no "module support" is required for that. I don't see the
sense of distinguishing "boot time" from "run time" - from the kernel's
1. 'boot time' is an instant of time when the Core kernel binaries are loaded into
memory for execution. Any binary or program code has to be loaded into memory
before it will execute and I call this instant of time as execution time or load time.
For the Core kernel I referred to it as 'boot time' or 'start time' because before it
nothing was running.
2. 'run time' is any instant of time when the kernel is running and this is after
'boot time'. I use 'run time' to describe a situation where a Core kernel is
running and whilst it's running I add an extension or module to that running
Core kernel.
It is important for me to differentiate between the two, in the context of what
I was describing, namely: that device drivers, file systems drivers, system calls,
and all those modules that sits just above on the next layer of the Core kernel
may be loaded in two (2) ways, at 'boot time' or at 'run time' depending on
how the kernel was configured during compilation time.
I think the differences of interpretation here were in the way I and you conceptualize
the kernel codes.
I conceptualize the kernel codes (Core and Modules) as Logical entities. These
Logical entities may be arranged in differentiate physical ways, namely:
1. One physical file, i.e., CONFIG_????=y plus CONFIG_MODULES=n.
2. Many related physical files, i.e., CONFIG_????=m(=y) plus CONFIG_MODULES=y
For me, irregardless of the physical arrangement, I conceptualize the Core kernel as
separate entity from the modules (device drivers, file system drivers, system calls, etc).
With item 1. above everything is loaded when the Core kernel is loaded at 'boot time'
obviously because everything is in one file. After 'boot time' no additional kernel
modules maybe loaded.
With item 2. above the Core kernel is loaded first and others may be loaded at 'run time'
as needed.
There are possibilities that 'clever' people may succeed in loading hostile codes in this
situation.
In the context at the beginning of this discussion is the issue of security. I was trying
to say I re-compile the kernel I used when it is critical to security. I went on to say
the object of re-compiling is to prevent anyone 'rootkit'ing by LKM. And I went on to
say I can prevent someone 'rootkit'ing by LKM by removing modules
(not configuring modules) in the kernel.
But it does not bother me to see that discussions arise about trivial items on symantecs
which are not helpful as far as I am concerned. I'm more interested to learn what others
are doing in terms of security, etc., the things that matters most rather than trivialities.
.................snipped....................................
I can't find the exact "menuconfig" help text right now, but to quote README.Menuconfig:
-Some kernel features may be built directly into the kernel. -Some may be made into loadable runtime modules. Some features -may be completely removed altogether. There are also certain
See that first line? "directly into the kernel".
Where did you get the "boot time only loading modules" from?
to NOT ALLOW the loading of modules at run time. In the
What is the definition of "run time" vs. "boot time"? Can you show a sample output or code or some reference for that? It's the first time I heard about such distinction.
I have defined this at the beginning. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
