Re: acpivga(4) v. MI display controls
On Fri, Oct 15, 2010 at 07:53:53PM -0500, David Young wrote: OK, what this code is doing is essentially attach a device to the acpi tree that really refers to a PCI device. Can we please get this to attach as child of vga0 by checking for a device matching the PCI address of vga0, that also provides _DOD and _DOS. This would prevent accessing vga0 on resume before it has been reset. Joerg calls attention in that last sentence to the possibility of defects in suspend/resume that arise when a device is represented twice in the device tree. Sounds familiar. :-) The above scheme is easily achieved if we start dropping #ifdefs to the device tree. (Hopefully everyone can agree that this is out of the question.) As I wrote, if we start to implement hacks specific to one acpi(4) driver, we end up with a big mess. It is much better to have the whole acpi(4) uniformly at 'acpinodebus' even with the risks involved, so that once we have a solution, everything can be transformed in a single sweep. You do realize that our suspend/resume paths are full of defects due reasons I outlined? For instance, because drivers do not inform the firmware upon suspend(), we have several cases where devices resume in a power off state (cf. PR #37891). Complaining about a single driver prevents one from seeing the forest. ISTM that more than one developer can, and has, described in a broad outline how it should be done. For example, I can outline how device_register() can be used to put ACPI information into MI device properties for device-attachment hooks to read back out. I'm happy to give more detailed suggestions, too. I think everyone groks this. Opening up an editor and doing the work is another thing. I emphasize that this is not entirely about autoconfiguration. I'm not sure I understand what you mean by the 'natural' device tree. I think you may have drawn a line between virtual and real device hierarchies and assigned ACPI to a different category than I would. Again, I'm not sure I've taken your meaning right. By natural I refer to the discussion on this list about (semi-random) thoughts on device tree structure (and the several inconsistencies in it). See appendix. It's just occurred to me that it may help to form a group to discuss how BIOS information should be encoded and conveyed from MD code to MI drivers in NetBSD. By setting standards, we may help developers on every port leverage others' knowledge and work. What do you think? Sounds good, albeit talk tends to be cheap. I take the above quote to clear some misunderstandings: (b) This is not about passing something from MD to MI -- it goes to the other direction also. (a) This is not only about passing information, but applies to controls (callbacks, etc.) also. (b) This is not only about autoconfiguration, but (a) and (b) are present dynamically at runtime. When a driver writes to a register, it may need to inform the firmware. When the firmware writes to a register, it may need to inform the driver. - Jukka. Appendix: the natural device tree on a ThinkPad. \ [06] [ ] CPU0 [12] [ ] CPU1 [12] [ ] _SB [06] [ ] LNKA [06] [ ] LNKB [06] [ ] LNKC [06] [ ] LNKD [06] [ ] LNKE [06] [ ] LNKF [06] [ ] LNKG [06] [ ] LNKH [06] [ ] MEM [06] [ ] LID [06] [ W] acpilid0 SLPB [06] [ W] acpibut0 PCI0 [06] [ ] (PCI) @ 0x00:0x00:0x00:0x00 [R] [B] - 0x00 pchb0 LPC [06] [ ] (PCI) @ 0x00:0x00:0x1F:0x00 ichlpcib0 SIO [06] [ ] PIC [06] [ ] TIMR [06] [ ] attimer1 HPET [06] [ ] hpet0 DMAC [06] [ ] SPKR [06] [ ] pcppi1 FPU [06] [ ] npx1 RTC [06] [ ] KBD [06] [ ] pckbc1 MOU [06] [ ] pckbc2 DURT [06] [ W] DLPT [06] [ ] DECP [06] [ ] FIR [06] [ ] TPM [06] [ ] EC[06] [ ] acpiec0 PUBS [11] [ ] BAT0 [06] [ ] acpibat0 BAT1 [06] [ ] BAT2 [06] [ ] AC[06] [ ] acpiacad0 HKEY [06] [ ] thinkpad0 VID [06] [ ] (PCI) @ 0x00:0x00:0x02:0x00 vga1 LCD0 [06] [ ] CRT0 [06] [ ] AGP [06] [ ] (PCI) @ 0x00:0x00:0x01:0x00 VID [06] [ ] LCD0 [06] [ ] CRT0 [06] [ ] EXP0 [06] [ W] (PCI) @ 0x00:0x00:0x1C:0x00 [B] - 0x01 ppb0 EXP1 [06] [ W] (PCI) @ 0x00:0x00:0x1C:0x01 [B] - 0x02 ppb1 EXP2 [06] [ W] (PCI) @
Re: acpivga(4) v. MI display controls
On Fri, Oct 15, 2010 at 08:29:57AM -0400, der Mouse wrote: ACPI may be the source of the information, but that doesn't mean it has to be how the autoconf tree is constructed. Compare and contrast with how NetBSD/sparc uses the OF (or is it OBP? I'm not sure) device tree to drive autoconf, but doesn't have a device node corresponding to OF that everything attaches under; it just uses the OF tree as the source of the data about what exists where. (Well, much of it; autoconf doesn't totally mirror OF, eg, in SCSI device attachment.) I do not know OF well, but my impression is that it is much, much less invasive than what we have nowadays on x86 where close interaction between the firmware and drivers are expected. Several people seem to be under the false impression that this is something only related to device attachment and autoconfiguration. It is not. I tried to outline this in another mail, but frankly I think whether 'X attachs to Y or Z' is just a little, largely irrelevant, detail in the face of much bigger problems. In a nutshell: ACPI BIOS may access hardware directly, with or without the consent from the system. In an entirely x86 based codebase this is hardly a problem, but in NetBSD this comes down to the question on how to maintain the clean MD/MI separation in the future. - Jukka.
Re: kernel module loading vs securelevel
On Sat, 16 Oct 2010, Izumi Tsutsui wrote:
autoload/autounload does NOT perform any authorization checks - please
look at the code! No checking of securelevel occurs, as far as I can
see. For autoload, the module name must not contain a '/', so if the
module is being loaded from the file system it must be loaded from the
blessed /stand/${ARCH}/${VERSION}/modules directory. Including the
INSECURE option will have no effect on autoloading of modules.
Hmm.
I built MODULAR kernels on news68k and sun3 (which didn't have INSECURE)
but I couldn't use TMPFS or execute a.out binaries on multiuser
though they worked after shutdown(8) or on single user.
The code doesn't work as intended and just we should fix it?
Hmmm. Maybe I am reading the code wrong. But the intent of the code
seems to be quite clear. The manual load explicitly calls kauth_...()
while the auto-load path does not make any such call.
Perhaps there is an additional authorization call in kobj_load_vfs()
(which does the actual loading). A quick grep of subr_kobj*.c for
kauth_ does not reveal anything obvious.
Could you rerun your testing after setting sysctl kern.module.verbose?
This should provide extra kernel debug printf() messages...
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: kernel module loading vs securelevel
Hmmm. OK, I will build an i386 kernel _without_ INSECURE and see if I can reproduce the problem. On Sat, 16 Oct 2010, Izumi Tsutsui wrote: Could you rerun your testing after setting sysctl kern.module.verbose? This should provide extra kernel debug printf() messages... There are some info during boot (before securelevel is set to 1): --- : Mounting all filesystems... DEBUG: module: plist load returned error 2 for `/stand/sun3/5.99.39/modules/mfs/mfs.kmod' DEBUG: module: plist load returned error 2 for `/stand/sun3/5.99.39/modules/kernfs/kernfs.kmod' DEBUG: module: plist load returned error 2 for `/stand/sun3/5.99.39/modules/procfs/procfs.kmod' DEBUG: module: plist load returned error 2 for `/stand/sun3/5.99.39/modules/ptyfs/ptyfs.kmod' DEBUG: module: cannot unload module `mfs' error=16 DEBUG: module: cannot unload module `kernfs' error=16 DEBUG: module: cannot unload module `procfs' error=16 Clearing temporary files. DEBUG: module: cannot unload module `ptyfs' error=16 Starting amd. Creating a.out runtime link editor directory cache. Checking quotas: done. Setting securelevel: kern.securelevel: 0 - 1 : --- All file systems (mfs, kernfs, procfs, and ptyfs) are mounted properly, though. On multi user, there is no particular info: --- # mount -t tmpfs tmpfs /mnt mount_tmpfs: tmpfs on /mnt: Operation not supported by device # shutdown now Shutdown NOW! : Enter pathname of shell or RETURN for /bin/sh: Terminal type is kterm. We recommend creating a non-root account and using su(1) for root access. # mount -t tmpfs tmpfs /mnt DEBUG: module: plist load returned error 2 for `/stand/sun3/5.99.39/modules/tmpfs/tmpfs.kmod' chariot# df /mnt Filesystem 1K-blocks Used Avail %Cap Mounted on tmpfs 49480 8 49472 0% /mnt # DEBUG: module: cannot unload module `tmpfs' error=16 --- Izumi Tsutsui !DSPAM:4cb9a96b2437545078506! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: acpivga(4) v. MI display controls
On Sat, 16 Oct 2010, Jukka Ruohonen wrote: On Sat, Oct 16, 2010 at 12:24:12PM +0200, Martin Husemann wrote: The main difference that I understood seems to be what you call virtual and natural device trees: in OF world we guide the whole autoconfig tree along the OF device tree, with differences close to the leafs (i.e. the scsibus der Mouse mentioned). At every point during autoconfig we can make sure to have enough OF information already available during the device_register() call. The only problem we ran into so far, IIRC, is the id of FC disks for boot device detection, but we worked around that pretty easily. This seems to be what is needed on x86 as well. The only way to eliminate such things as PCI_BUS_FIXUP etc. and several existing bus_space(9) conflicts is probably to parse the firmware tree as the first thing, and then utilize this information at each attachment step. This is exactly what I meant by noting that we tend to think this backwards; perhaps ACPI should drive the autoconfiguration, not vice versa. It is problematic to think that we can continue as business as usual, and then ACPI drivers go and seek their real counterparts that have been attached without using ACPI in the first place. I agree with this, even for OF machines. I've always considered the existing scheme using device_register() as an ugly hack, and I hate to contemplate the incredibly ugly hoops we had to jump through to make the PCI framework function with OF, especially on machines where config space accesses to non-existant devices can hang the processor. What I'd like to see is a device tree generated from the firmware information if available driving the autoconfig process. Any MD operations should be done through MI code manipulating properties on the device node, which are then trapped by MD code interact with firmware. Eduardo
Re: kernel module loading vs securelevel
On Jan 31, 5:14pm, Paul Goyette wrote:
} On Sat, 16 Oct 2010, Izumi Tsutsui wrote:
}
} Hmm, what do you think about this feature?
} Only available in INSECURE environment?
}
} We trust modules at the time when they're installed into the trusted
} place, same as kernel itself. I think prohibiting module load at
} run-time is rather pointless.
}
} Well I think the point is whether we should require INSECURE or not
} to use module autoload/autounload after multiuser.
}
} If we should I'll enable options INSECURE by default on ports
} that require options MODULAR (to save kernel file size).
}
} autoload/autounload does NOT perform any authorization checks - please
} look at the code! No checking of securelevel occurs, as far as I can
I just did and autoload most certainly does do authorization
checks.
} see. For autoload, the module name must not contain a '/', so if the
} module is being loaded from the file system it must be loaded from the
} blessed /stand/${ARCH}/${VERSION}/modules directory. Including the
} INSECURE option will have no effect on autoloading of modules.
}
} Manual loading and unloading of modules does involve calls to
} kauth_authorize_system() which will check securelevel.
sys/kern/kern_module.c:module_autoload() makes almost the exact
same call to kauth_authorize_system as does module_load(). The
difference is that the second last parm is (void *)(uintptr_t)1. What
difference this makes is going to be buried in the bowels of kauth, and
I'm not going to dig through that at this moment.
}-- End of excerpt from Paul Goyette
Re: kernel module loading vs securelevel
On Sat, 16 Oct 2010, John Nemeth wrote:
sys/kern/kern_module.c:module_autoload() makes almost the exact
same call to kauth_authorize_system as does module_load(). The
difference is that the second last parm is (void *)(uintptr_t)1. What
difference this makes is going to be buried in the bowels of kauth, and
I'm not going to dig through that at this moment.
Hmmm, missed that one. You're right.
The arg is, I think, the one that gets passsed to the kauth listener as
arg2, which should cause us to return KAUTH_RESULT_ALLOW for autoload:
static int
module_listener_cb(kauth_cred_t cred, kauth_action_t action, void *cookie,
void *arg0, void *arg1, void *arg2, void *arg3)
{
int result;
result = KAUTH_RESULT_DEFER;
if (action != KAUTH_SYSTEM_MODULE)
return result;
if ((uintptr_t)arg2 != 0) /* autoload */
result = KAUTH_RESULT_ALLOW;
return result;
}
}-- End of excerpt from Paul Goyette
!DSPAM:4cb9cb6e2431088414278!
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: kernel module loading vs securelevel
On Sun, 17 Oct 2010, Masao Uebayashi wrote:
On Sat, Oct 16, 2010 at 08:57:04AM -0700, John Nemeth wrote:
On Jan 31, 5:14pm, Paul Goyette wrote:
} On Sat, 16 Oct 2010, Izumi Tsutsui wrote:
}
} Hmm, what do you think about this feature?
} Only available in INSECURE environment?
}
} We trust modules at the time when they're installed into the trusted
} place, same as kernel itself. I think prohibiting module load at
} run-time is rather pointless.
}
} Well I think the point is whether we should require INSECURE or not
} to use module autoload/autounload after multiuser.
}
} If we should I'll enable options INSECURE by default on ports
} that require options MODULAR (to save kernel file size).
}
} autoload/autounload does NOT perform any authorization checks - please
} look at the code! No checking of securelevel occurs, as far as I can
I just did and autoload most certainly does do authorization
checks.
} see. For autoload, the module name must not contain a '/', so if the
} module is being loaded from the file system it must be loaded from the
} blessed /stand/${ARCH}/${VERSION}/modules directory. Including the
} INSECURE option will have no effect on autoloading of modules.
}
} Manual loading and unloading of modules does involve calls to
} kauth_authorize_system() which will check securelevel.
sys/kern/kern_module.c:module_autoload() makes almost the exact
same call to kauth_authorize_system as does module_load(). The
difference is that the second last parm is (void *)(uintptr_t)1. What
difference this makes is going to be buried in the bowels of kauth, and
I'm not going to dig through that at this moment.
I read it as:
a) module_listener_cb() checks the 2nd arg, if autoload, judge the auth
as allow
b) secmodel_securelevel_system_cb() denies the auth if (securelevel
0) regardless of autoload
Kauth disallows the auth, because 0 listner(s) denied.
Ah, I see. That definitely explains it.
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: kernel module loading vs securelevel
On Sat, Oct 16, 2010 at 08:40:21PM +0900, Masao Uebayashi wrote: We trust modules at the time when they're installed into the trusted place, same as kernel itself. I think prohibiting module load at run-time is rather pointless. The trusted place? What's that? Except in the single special case of autoload, the trusted place could be anywhere on the filesystem, or on any remote filesystem for that matter. If you want to enforce the rule any trusted module can be loaded but only trusted modules can be loaded, while preserving the securelevel framework, the obvious options are: 1) Load module hashes into the kernel at compile or boot time, like veriexec does, 2) Finish the asymmetric operation support in cryptodev and actually require modules to be signed. This is basically a superset of #1 above that could get about as complicated as one wanted it to (ugh) but might be worthwhile if kept simple. Thor
Re: kernel module loading vs securelevel
On Sat, Oct 16, 2010 at 08:53:52PM +0900, Izumi Tsutsui wrote: Hmm, what do you think about this feature? Only available in INSECURE environment? We trust modules at the time when they're installed into the trusted place, same as kernel itself. I think prohibiting module load at run-time is rather pointless. Well I think the point is whether we should require INSECURE or not to use module autoload/autounload after multiuser. If we should I'll enable options INSECURE by default on ports that require options MODULAR (to save kernel file size). Do not do that. You will introduce a significant security regression just for your own convenience. Thor
Re: kernel module loading vs securelevel
On Sun, Oct 17, 2010 at 03:03:58AM +0900, Izumi Tsutsui wrote: If we should I'll enable options INSECURE by default on ports that require options MODULAR (to save kernel file size). Do not do that. You will introduce a significant security regression just for your own convenience. Heh, then why have we had it on i386 for years? So what you're trying to suggest is that if one port, for historical reasons, ships with an insecure setting in the default kernel, that's an explanation of why *every* port should? I think there's something wrong with your logic. Thor
Re: kernel module loading vs securelevel
If we should I'll enable options INSECURE by default on ports that require options MODULAR (to save kernel file size). Do not do that. You will introduce a significant security regression just for your own convenience. Heh, then why have we had it on i386 for years? So what you're trying to suggest is that if one port, for historical reasons, ships with an insecure setting in the default kernel, that's an explanation of why *every* port should? Who said *every* port? If we should I'll enable options INSECURE by default on ports that require options MODULAR (to save kernel file size). I'm just asking if options INSECURE is mandaory to use autoloading, not module/autoloading is secure/silly/boo or not. --- Izumi Tsutsui
Re: kernel module loading vs securelevel
On Sun, Oct 17, 2010 at 03:38:42AM +0900, Izumi Tsutsui wrote: Heh, then why have we had it on i386 for years? Because of the X server. You are just saying: We introduced a significant security regression just for our own convenience. Perhaps... I see no proper reason to avoid INSECURE for MODULAR if it's okay for X. ...and I'm not convinced of this, primarily because (from a practical point of view) X is unavoidable and unfixable, whereas modules are neither. This gets back to the underlying question of what purpose modules are supposed to serve, and as I know everyone knows what I think and is sick and tired of hearing about it, I'll pipe down. -- David A. Holland dholl...@netbsd.org
re: kernel module loading vs securelevel
...and I'm not convinced of this, primarily because (from a practical point of view) X is unavoidable and unfixable, whereas modules are neither. actually, with DRM (and KMS) i believe we will be able to run the X server as non-root. .mrg.
Re: kernel module loading vs securelevel
I'm just asking if options INSECURE is mandaory to use autoloading, not module/autoloading is secure/silly/boo or not. No. As far as I can tell, there's a bug in the relevant kauth listener, at least in terms of the original intent of the author of the autoloading code; the system scope kauth listener should return DEFER, not DENY. Okay, fair enough. Thanks. However, I think it's a troublesome question whether this is really the right policy to apply. : Well, it's another discussion how modules can be secure, which is out of my scope. --- Izumi Tsutsui
Re: kernel module loading vs securelevel
On Sat, Oct 16, 2010 at 12:03:52PM -0700, Paul Goyette wrote:
autoload/autounload does NOT perform any authorization checks -
please look at the code! No checking of securelevel occurs, as far
as I can see. For autoload, the module name must not contain a
'/', so if the module is being loaded from the file system it must
be loaded from the blessed /stand/${ARCH}/${VERSION}/modules
directory. Including the INSECURE option will have no effect on
autoloading of modules.
If this is true it makes securelevel useless; all you need to do is
put a hostile module in the right place and cause it to be autoloaded.
(Remember the point of securelevel is that even root can't lower it.)
John Nemeth has already pointed out that my reading of the code was
flawed. Module autoloading _does_ call kauth for authorization.
The kauth listener provided by the module subsystem returns ALLOW
for all autoload calls, but this gets overridden by another kauth
listener, so autoload still gets denied.
Good that it's not true then :-)
It should be sufficient, I think, to check at boot time that any
module that can be autoloaded is marked immutable.
And also make the blessed directory itself immutable? :)
As I recall the semantics of immutable are such that this isn't
necessary to protect modules that are present at boot time (that is,
they can't be unlinked/renamed/etc.), and if there are autoloadable
modules whose names aren't present at boot time, they'll fail the
check.
--
David A. Holland
dholl...@netbsd.org
Re: kernel module loading vs securelevel
On Sun, Oct 17, 2010 at 06:13:11AM +1100, matthew green wrote: ...and I'm not convinced of this, primarily because (from a practical point of view) X is unavoidable and unfixable, whereas modules are neither. actually, with DRM (and KMS) i believe we will be able to run the X server as non-root. Yes, after what, some fifteen years? :-/ -- David A. Holland dholl...@netbsd.org
Re: kernel module loading vs securelevel
On Sat, 16 Oct 2010, David Holland wrote: And also make the blessed directory itself immutable? :) As I recall the semantics of immutable are such that this isn't necessary to protect modules that are present at boot time (that is, they can't be unlinked/renamed/etc.), and if there are autoloadable modules whose names aren't present at boot time, they'll fail the check. I've already misread the code here once, but... As far as I can tell, each time a module_autoload call is made, if the module is neither built-in nor passed in by the boot loader, the code will attempt to load it via a call to kobj_load_vfs() which has path as an argument. It doesn't appear to me that there is any pre-approved list of acceptable objects that can be loaded from the file system. BTW, does the immutable flag prevent one from using an immutable directory as the mount-point for some other file system? Hmmm... - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
How to make module autoloading play nice with securelevel
On Sat, Oct 16, 2010 at 01:17:47PM -0700, Paul Goyette wrote: On Sat, 16 Oct 2010, David Holland wrote: And also make the blessed directory itself immutable? :) As I recall the semantics of immutable are such that this isn't necessary to protect modules that are present at boot time (that is, they can't be unlinked/renamed/etc.), and if there are autoloadable modules whose names aren't present at boot time, they'll fail the check. I've already misread the code here once, but... As far as I can tell, each time a module_autoload call is made, if the module is neither built-in nor passed in by the boot loader, the code will attempt to load it via a call to kobj_load_vfs() which has path as an argument. It doesn't appear to me that there is any pre-approved list of acceptable objects that can be loaded from the file system. Right, it's looked up by path. And this is a problem: you need to make sure all directories from which modules can be loaded are immutable at boot time, which is harder than you'd think because it's not just one directory! If it were a flat directory of files, it'd be a lot easier. And then there's the mount-on-top issue. Jared had a very elegant suggestion for this: record which device the module autoload root directory is mounted on at boot time. At autoload time, check that the module you're about to load does in fact come from that same device. I wish I could think of some similarly elegant solution to the have to mark everything from the module root down to the modules themselves immutable -- and check it before enabling autoloading, at boot time issue. But I can't see a way that doesn't require building the whole hierarchy of autoload-eligible files at boot time. Can you? BTW, does the immutable flag prevent one from using an immutable directory as the mount-point for some other file system? Hmmm... I think it's an interesting question whether it should. I'd tend towards yes, it should but the answer right now is no, it does not. This is all useful and important functionality. We should get it all working together and try to keep it that way. I cannot lose the feeling that there's a non-Baroque solution lurking out there that we just haven't quite landed on yet. Thor
Re: kernel module loading vs securelevel
Hi Thor. On Sat, Oct 16, 2010 at 03:08:45PM -0400, Thor Lancelot Simon wrote: On Sun, Oct 17, 2010 at 03:51:52AM +0900, Izumi Tsutsui wrote: I'm just asking if options INSECURE is mandaory to use autoloading, not module/autoloading is secure/silly/boo or not. No. As far as I can tell, there's a bug in the relevant kauth listener, at least in terms of the original intent of the author of the autoloading code; the system scope kauth listener should return DEFER, not DENY. However, I think it's a troublesome question whether this is really the right policy to apply. Unless the directory from which modules are loaded is required to be immutable (flags schg) at boot time, this really does introduce a major security regression: now it is possible to override the whole security policy by placing a new kernel module in the existing directory, when the system is running at securelevel 0. I may be missing your point but there are other ways of sabotaging the securelvel mechanism without kernel modules available. It doesn't seem like a new problem to me. A more obvious way to be mischievous for sure but not new. I really only see two ways to keep the convenient behavior you and I both seem to want (autoload of modules when filesystems, syscalls, etc. are used) and the safe behavior I and others building (for example) embedded systems with tight security policies want: either we need to rely on the existing securelevel machinery and require that the directory from which autoload occurs is immutable at kernel boot time (elsewise disabling autoload), or we need to use something like veriexec, when we're still at securelevel 0, to ensure that the modules placed there don't change in any way. Someone is going to ask me why do you want modules at all on a system with a tight security policy? The answer, unfortunately, is licensing, and in particular CDDL code. You can load it into your kernel without pulling the entire kernel sources under CDDL but you cannot link it into your kernel at compile time. :-/
Re: kernel module loading vs securelevel
On Sat, Oct 16, 2010 at 08:28:42PM +, Andrew Doran wrote: I may be missing your point but there are other ways of sabotaging the securelvel mechanism without kernel modules available. It doesn't seem like a new problem to me. A more obvious way to be mischievous for sure but not new. Generally speaking, the other ways require a reboot. So this is worse in what seems to me a relevant way. I'm starting to think the simplest thing -- though it is not so simple! -- that lets people building systems where securelevel actually is used to protect a TCB continue to do so, yet use kernel modules, is to record which modules may be autoloaded at boot time, whether by content hash or dev/ino (with the immutable requirement to ensure reuse does not screw us up). The latter seems like it _should_ be simpler but I bet in practice the former really is. Thor
Re: kernel module loading vs securelevel
On Mar 8, 9:44am, Thor Lancelot Simon wrote: } On Sun, Oct 17, 2010 at 03:51:52AM +0900, Izumi Tsutsui wrote: } } I'm just asking if options INSECURE is mandaory to use autoloading, } not module/autoloading is secure/silly/boo or not. } } No. As far as I can tell, there's a bug in the relevant kauth listener, } at least in terms of the original intent of the author of the autoloading } code; the system scope kauth listener should return DEFER, not DENY. module_listener_cb() was added to kern_module.c in revision 1.51 by elad. The kauth_authorize_system() calls were added to kern_module.c by ad, but the respective commit log messages doesn't say anything about them, so the original intent of the author of the autoloading code (ad) is unclear. } However, I think it's a troublesome question whether this is really } the right policy to apply. Unless the directory from which modules are } loaded is required to be immutable (flags schg) at boot time, this really } does introduce a major security regression: now it is possible to override } the whole security policy by placing a new kernel module in the existing } directory, when the system is running at securelevel 0. } } I really only see two ways to keep the convenient behavior you and I both } seem to want (autoload of modules when filesystems, syscalls, etc. are } used) and the safe behavior I and others building (for example) embedded } systems with tight security policies want: either we need to rely on } the existing securelevel machinery and require that the directory from } which autoload occurs is immutable at kernel boot time (elsewise disabling } autoload), or we need to use something like veriexec, when we're still at } securelevel 0, to ensure that the modules placed there don't change in } any way. I would have to agree. Having modules loaded at securelevel 0 when you can't be absolutely sure of what's in them, completely defeats the purpose of running at securelevel 0. }-- End of excerpt from Thor Lancelot Simon
Re: kernel module loading vs securelevel
On Feb 1, 1:25am, Paul Goyette wrote: } On Sat, 16 Oct 2010, David Holland wrote: } } And also make the blessed directory itself immutable? :) } } As I recall the semantics of immutable are such that this isn't } necessary to protect modules that are present at boot time (that is, } they can't be unlinked/renamed/etc.), and if there are autoloadable } modules whose names aren't present at boot time, they'll fail the } check. } } I've already misread the code here once, but... } } As far as I can tell, each time a module_autoload call is made, if the } module is neither built-in nor passed in by the boot loader, the code } will attempt to load it via a call to kobj_load_vfs() which has path as } an argument. It doesn't appear to me that there is any pre-approved } list of acceptable objects that can be loaded from the file system. No, there isn't. If the module is in the appropriate directory, it can be loaded. }-- End of excerpt from Paul Goyette
Re: kernel module loading vs securelevel
} I'm just asking if options INSECURE is mandaory to use autoloading, } not module/autoloading is secure/silly/boo or not. } } No. As far as I can tell, there's a bug in the relevant kauth listener, } at least in terms of the original intent of the author of the autoloading } code; the system scope kauth listener should return DEFER, not DENY. module_listener_cb() was added to kern_module.c in revision 1.51 by elad. The kauth_authorize_system() calls were added to kern_module.c by ad, but the respective commit log messages doesn't say anything about them, so the original intent of the author of the autoloading code (ad) is unclear. The following patch makes autoload works even on securelevel 0, but I'm not sure if it's correct and acceptable. If not, options INSECURE is the only way to enable it.. Index: secmodel/securelevel/secmodel_securelevel.c === RCS file: /cvsroot/src/sys/secmodel/securelevel/secmodel_securelevel.c,v retrieving revision 1.20 diff -u -p -r1.20 secmodel_securelevel.c --- secmodel/securelevel/secmodel_securelevel.c 7 Oct 2009 01:06:57 - 1.20 +++ secmodel/securelevel/secmodel_securelevel.c 16 Oct 2010 22:15:11 - @@ -254,7 +254,7 @@ secmodel_securelevel_system_cb(kauth_cre break; case KAUTH_SYSTEM_MODULE: - if (securelevel 0) + if ((uintptr_t)arg2 == 0 securelevel 0) result = KAUTH_RESULT_DENY; break; --- Izumi Tsutsui
Re: acpivga(4) v. MI display controls
On Sat, Oct 16, 2010 at 03:22:52PM +0300, Jukka Ruohonen wrote: On Sat, Oct 16, 2010 at 12:24:12PM +0200, Martin Husemann wrote: The main difference that I understood seems to be what you call virtual and natural device trees: in OF world we guide the whole autoconfig tree along the OF device tree, with differences close to the leafs (i.e. the scsibus der Mouse mentioned). At every point during autoconfig we can make sure to have enough OF information already available during the device_register() call. The only problem we ran into so far, IIRC, is the id of FC disks for boot device detection, but we worked around that pretty easily. This seems to be what is needed on x86 as well. The only way to eliminate such things as PCI_BUS_FIXUP etc. and several existing bus_space(9) conflicts is probably to parse the firmware tree as the first thing, and then utilize this information at each attachment step. This is exactly what I meant by noting that we tend to think this backwards; perhaps ACPI should drive the autoconfiguration, not vice versa. It is problematic to think that we can continue as business as usual, and then ACPI drivers go and seek their real counterparts that have been attached without using ACPI in the first place. It sounds like your idea of ACPI's role in autoconfiguration is not too different from Martin's and mine, but you may be using different language to describe it. I think that ACPI should definitely guide autoconfiguration, if ACPI is available. Another thing is the actual device tree. For instance, currently, even with the fine work done with pmf(9), in some corner cases we may power off a device before its children are turned off because the device tree is partially arbitrary. What devices do you have in mind? Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: kernel module loading vs securelevel
On Sun, 17 Oct 2010, Izumi Tsutsui wrote: } I'm just asking if options INSECURE is mandaory to use autoloading, } not module/autoloading is secure/silly/boo or not. } } No. As far as I can tell, there's a bug in the relevant kauth listener, } at least in terms of the original intent of the author of the autoloading } code; the system scope kauth listener should return DEFER, not DENY. module_listener_cb() was added to kern_module.c in revision 1.51 by elad. The kauth_authorize_system() calls were added to kern_module.c by ad, but the respective commit log messages doesn't say anything about them, so the original intent of the author of the autoloading code (ad) is unclear. The following patch makes autoload works even on securelevel 0, but I'm not sure if it's correct and acceptable. If not, options INSECURE is the only way to enable it.. Based on the discussion regarding the numerous ways in which this could be abused, I would personally vote for requiring INSECURE. At least that way, things are pretty clear. If the proposed patch were used, then you would have only options MODULAR in the kernel config file, which is not at all clear about the security of the resulting kernel. Index: secmodel/securelevel/secmodel_securelevel.c === RCS file: /cvsroot/src/sys/secmodel/securelevel/secmodel_securelevel.c,v retrieving revision 1.20 diff -u -p -r1.20 secmodel_securelevel.c --- secmodel/securelevel/secmodel_securelevel.c 7 Oct 2009 01:06:57 - 1.20 +++ secmodel/securelevel/secmodel_securelevel.c 16 Oct 2010 22:15:11 - @@ -254,7 +254,7 @@ secmodel_securelevel_system_cb(kauth_cre break; case KAUTH_SYSTEM_MODULE: - if (securelevel 0) + if ((uintptr_t)arg2 == 0 securelevel 0) result = KAUTH_RESULT_DENY; break; --- Izumi Tsutsui !DSPAM:4cba24f22438312397761! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
