Re: kernel module loading vs securelevel
On Sun, 17 Oct 2010 20:11:06 -0400, Thor Lancelot Simon t...@panix.com wrote: On Sun, Oct 17, 2010 at 04:04:59PM -0400, Matthew Mondor wrote: On Sat, 16 Oct 2010 13:58:19 -0400 Thor Lancelot Simon t...@panix.com wrote: 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. You seem to now agree with me that this could be a solution. It indeed requires more work, but it also has advantages: not having to Let me know when you've got the code ready for review. *lurker mode off* IIRC, part of agc work with netpgp is to integrate signature verification within kernel. *lurker mode on* -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: How to make module autoloading play nice with securelevel
On Sun, 17 Oct 2010 21:34:09 -0400, Michael Richardson m...@sandelman.ottawa.on.ca wrote: Let me ask two highlevel questions: 1) what class of systems care to enable securelevel, yet still need to load some random set of modules after boot? Are they x86 desktops or multi-gigabit servers in the cloud? (virtual or not) Or are they embedded ARM/MIPS devices living inside light bulbs? Certain kernel modules can be loaded long after boot, after securelevel has been raised (like on demand loading). POSIX AIO, accf_data/http, solaris/dtrace (hmm, works with securelevel?), etc. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: kernel module loading vs securelevel
On Oct 18, 2010, at 8:51 03AM, Jean-Yves Migeon wrote: On Sun, 17 Oct 2010 20:11:06 -0400, Thor Lancelot Simon t...@panix.com wrote: On Sun, Oct 17, 2010 at 04:04:59PM -0400, Matthew Mondor wrote: On Sat, 16 Oct 2010 13:58:19 -0400 Thor Lancelot Simon t...@panix.com wrote: 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. You seem to now agree with me that this could be a solution. It indeed requires more work, but it also has advantages: not having to Let me know when you've got the code ready for review. *lurker mode off* IIRC, part of agc work with netpgp is to integrate signature verification within kernel. *lurker mode on* Signatures provide *authentication*; what is needed here is *authorization*. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: kernel module loading vs securelevel
On Mon, 18 Oct 2010 14:51:03 +0200 Jean-Yves Migeon jeanyves.mig...@free.fr wrote: *lurker mode off* IIRC, part of agc work with netpgp is to integrate signature verification within kernel. *lurker mode on* Thanks, that's nice to know, I didn't look at netpgp yet but might eventually check if its RSA implementation (if any) can eventually be worked into common/lib/libc/rsa, which would be a major step forward to allow the kernel to verify signatures. I started writing a task list to have an idea of what needs to be done, and it's not trivial (http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/netbsd/signed_modules.txt?rev=1.5;content-type=text%2Fplain). I might give an implementation a try during my next vacations, but no timeline or guarantee (disclaimer!). Motivation is also a factor as my current (very simple) solution to the various MODULAR issues I've faced (mostly maintenance related) has been so far to use monolithic kernels. -- Matt
Re: kernel module loading vs securelevel
On Mon, 18 Oct 2010 09:31:32 -0400 Steven Bellovin s...@cs.columbia.edu wrote: Signatures provide *authentication*; what is needed here is *authorization*. While I agree, there also are situations were both can be welcome... Another solution someone proposed which I like is hashing the modules to then at load time rehash and match a module against the hash set, which would be a simpler, shorter-term solution. I think that embedding the hashes set in the kernel image would be safer than using a file, however. Unfortunately, this makes developing, installing or upgrading a module less friendly as the kernel image has to be refreshed and the system rebooted. -- Matt
Re: kernel module loading vs securelevel
On Mon, 18 Oct 2010 09:31:32 -0400, Steven Bellovin s...@cs.columbia.edu wrote: *lurker mode off* IIRC, part of agc work with netpgp is to integrate signature verification within kernel. *lurker mode on* Signatures provide *authentication*; what is needed here is *authorization*. And integrity (: -- Jean-Yves Migeon jeanyves.mig...@free.fr
cxgb(4) man page missing, otherwise undocumented
Casting about for current-production 10Gb adapters I could use with NetBSD, I stumbled across the cxgb driver. These devices are not in any of the (admittedly somewhat poorly organized) hardware compatibility lists I can find on www.netbsd.org, nor is there a manual page! Does this driver work? With which devices, and can they still be purchased? -- Thor Lancelot Simont...@rek.tjls.com All of my opinions are consistent, but I cannot present them all at once.-Jean-Jacques Rousseau, On The Social Contract
Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project results)
On Tue, Oct 12, 2010 at 3:47 AM, Alan Barrett a...@cequrux.com wrote: [cross-posting removed] On Tue, 05 Oct 2010, Lourival Vieira Neto wrote: We've created the support for scripting the NetBSD kernel with Lua, Instead of using long long as the C data type for Lua variables, I suggest using int64_t (which is the same size on all existing and future platforms), or intmax_t (which is the largest available type on any particular platform). long long has neither of these attributes. --apb (Alan Barrett) Hi Alan, You're right! I'll change it. -- Lourival Vieira Neto
Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project results)
On Mon, Oct 11, 2010 at 11:50 PM, Matthew Mondor mm_li...@pulsar-zone.net wrote: On Sun, 10 Oct 2010 19:45:41 -0600 Samuel Greear l...@evilcode.net wrote: I didn't like the fact that the only option for loading a script into the kernel was to load the script source. I would make loading pre-compiled scripts the preferential method. In fact, I would probably tear eval out of the kernel lua implementation and only support loading of precompiled byte-code into the kernel. If the tokenizer is considered heavy, or a potential source of exploit, or if scripts are expected to frequently be loaded and a peformance bottleneck exists, I also think that loading pre-tokenized bytecode would be a good idea. No, it is not heavy (see [1]). However, there are several things to consider: some systems (i.e. Java) do important sanity checks at tokenization time. Is this important for Lua? Yes, it does important verification in the lexer/parser. Secondly, is the Lua bytecode using a stable, well defined instruction set which is unlikely to change? Otherwise as it improves and gets updated any pre-tokenized scripts might need to be regenerated. Of course, that's probably not an issue if everything is part of the base system and always get rebuilt together. Yes, Lua bytecode is stable and uses a well-defined instruction set, but Lua doesn't perform bytecode verification (see [2]). Thanks, -- Matt [1] http://marc.info/?l=lua-lm=128676702329567w=2 [2] http://marc.info/?l=lua-lm=128676669829325w=2 Cheers, -- Lourival Vieira Neto
