Re: regarding the changes to kernel entropy gathering
> All that changed is that we don't pretend it provides entropy. Instead, you pretend it provides none. Neither pretense is accurate (where the "pretend it provides entropy" refers to providing any non-configurable fixed amount). The real problem here, as I see it, is that NetBSD qua NetBSD cannot tell where between those two extremes any particular case falls. Compounding this is that most sysadmins are not competent to accurately describe where a given install falls, even were NetBSD to provide a means to do so. (Though I suspect that most who understand the issues could provide a usefully high lower bound on the entry provided. For example, I'd be satisfied with one millibit per event - network packet or disk transfer - and in my environment I am confident that is an understimate.) > As I mentioned elsewhere, a lot of the classic entropy sources are > surprisingly bad nowadays when someone can observe the kernel, > especially in a virtualized environment. Yes...but, as gwoods indirectly but correctly pointed out, that may not matter: other VMs under the same hypervisor can be anywhere from "known to be actively hostile" to "fully trusted", depending on the site. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: regarding the changes to kernel entropy gathering
>> Nope, not entirely. But they have to be seeded once. If they have >> storage which survives reboots, and entropy is saved and restored on >> reboot, they will be ~fine. > BTW, to me reusing the same entropy on every reboot seems less > secure. Hence the "saved and" part of the above. (I still think it's misguided, but I don't expect NetBSD to agree. It's been a long time since NetBSD and I saw eye to eye on...well, on many points.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: regarding the changes to kernel entropy gathering
> I am still of the fairly firm beleif that the mistrust in the > hardware vendors' ability to make a reasonable and robust > implementation is without foundation. I don't doubt the ability. I don't doubt that they _can_. I question whether they _do_. (And, indeed, there has been at least one incident that demonstrates that on occasion they don't.) If I am ever in a situation where I need randomness good enough that I care about things like the accuracy of entropy estimates, I expect the applicable threat model will consider CPU manufacturers untrusted. Thus, I would want the system to consider RDRAND and its ilk same as any potential other source of entropy: trusted to generate real unpredictability only when specifically configured that way. (The question of what the default should be is a separate one.) Of course, in a situation like that, I would also want to do all the relevant processing on CPUs (and, where applicable, other hardware) old enough to predate the reasons for caring about that level of unpredictability, because it makes them significantly less likely to have been trojaned. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: regarding the changes to kernel entropy gathering
> No amount of uptime and activity was increasing the entropy in my > system before I patched it. As I understand it, entropy was being contributed. What wasn't happening was the random driver code recognizing and acknowledging that entropy, because it had no way to tell how much of it there really was. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: regarding the changes to kernel entropy gathering
> My question is, how can we tell what random sources a system actually > has, i.e. is there some flag that cpuctl identify shows when a system > has RDRAND/RDSEED? What about architectures that have nothing like RDRAND/RDSEED? Are they, effectively, totally unsupported now? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: regarding the changes to kernel entropy gathering
> What NetBSD-current is telling you on your Xen system, on a CPU > predating RDRAND/RDSEED, is the unfortunate truth that there is no > reliable source of entropy available in your system -- Not quite. That there is nothing which NetBSD, independent of the sysadmin, is confident is a reliable source of entropy. It's entirely possible one or more of those sources actually does supply usable entropy, but NetBSD doesn't realize that (and, as I understand it, provides no way for the sysadmin to fix that, short of hacking on the source). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: odd ATF failure for sh: ulimit_redirection_interaction failed
> But it still doesn't really make sense from what I see in the source. > The attempted FD is #18, but the error just says "1", not "18": Does > _ever_ work for multi-digit N? I thought it didn't. Maybe that was just least-common-denominator sh, or maybe the test is broken? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: recent sysinst UX changes
>> Lack of good randomness does not quite equal insecure install. Warn >> about it, sure, but I think *requiring* randomness is a bad idea. >> For example, I've been working with recent NetBSD at work, for >> something for which the presence or absence of good random-seed data >> makes absolutely no difference to security. > Unfortunately it leads to surprise failures if programs ever use > /dev/random. This does not happen for the product in question. There isn't even any entry "random" in /dev in the shipped filesystem - there are only 50 entries in its /dev. I recognize that we won't be using sysinst for the shipped filesystem image anyway. I'm just trying to point out that typical installs needing $THING is not a good reason to insist on everyone having $THING. (For whose value of "typical installs", anyway?) I'm building kernels with neither INET nor INET6 - it doesn't quite work out of the box for 9.1, but it's close enough that only a few files need fixing. Last time I tried it, sysinst let me install a system with no IP address configuration. IMO this should be the same: done by default, automatically if it's easy, but should be skippable if the user says to despite the warnings. In any case, even if the installed system needs a random seed file, that is not the same thing as sysinst needing to install it. > So far we've seen: > - Firefox refusing to start IMO, bug in Firefox. Hanging during startup when trying to do something like fetch a user's configured initial page which is stuck behind HTTPS, that's fine, even expected. Refusing to start? No. > - Python having problems Depending on what the "problems" are, I could call this anything from "expected" to "bug in python". In any case, even if NetBSD were to ship with firefox and python, nothing says the user has to use either one; I still don't see these as justifying sysinst insisting on installing a random seed file. > And some more things that have been patched not to use /dev/random. Sure. And if you don't set the timezone, you'll be stuck in UTC. And if you don't set up a mailer, mail won't work. If you don't set any DNS servers, things depending on name resolution won't work. I don't see this as fundamentally any different. Warning, fine. Enforcing, not - IMO! - fine. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: recent sysinst UX changes
> So: happy to make it more userfriendly, simpler, rephrase messages, > whatever needed - but we should not end up with insecure installs. Lack of good randomness does not quite equal insecure install. Warn about it, sure, but I think *requiring* randomness is a bad idea. For example, I've been working with recent NetBSD at work, for something for which the presence or absence of good random-seed data makes absolutely no difference to security. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: "wireguard" implementation improperly merged and needs revert
>> We still need to protect the unique identity and reputation of >> WireGuard (our "brand"). If someone feels this way about it, in my opinion it should be summarily yanked out and never, ever, EVER let back in - at least if there is any legal force behind that attitude. NetBSD's users already have enough of legal morass to navigate; making it worse only, well, makes it worse. Maybe unbranding is enough. Personally, I'm not confident that it is, and it's NetBSD's users' necks - in many jursidctions - on the legal line, not the Foundation's or the Project's. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: NetBSD-7.0 boots OK and NetBSD-8.0 hangs/crashes during boot on a MacBook7,1
> I agree with Mouse, except that I also think it would be very helpful > and useful to have a serial console on USB only devices. Oh, sure, it'd be helpful/useful. Lots of difficult things would be. > I wonder if we could make the console a virtual device which is > attached dynamically to a USB serial port if and when available. I have no doubt that could be done. I'm not sure how useful it would be. It seems to me that the set of times when it's most important to have a serial console overlaps heavily with the set of times when the USB stack is least likely to work. So I guess my reaction is "probably better than nothing - but not by all that much". Reworking the USB stack so serial ports can run polled would probably help, but my own experience echos Mike Pumford's. I've even had times when I've had boot troubles and a *PS/2* keyboard didn't work - and at least half the times when I've used a USB keyboard as console keyboard (which != a USB serial port as serial console) it's worked because the BIOS and hardware have collaborated to give the illusion of a PS/2 keyboard. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: NetBSD-7.0 boots OK and NetBSD-8.0 hangs/crashes during boot on a MacBook7,1
> That said, what would it take to wire the NetBSD console to a USB > serial adapter? "Too much". USB is horrible from this persective; you need quite a lot of infrastructure to do, well, pretty much anything over USB. Take a look at the code sometime. In the particular case of the console, you'd also have to figure out what to do with the console if the hardware goes away. It's one of the reasons I dislike USB, and closely related to most of the others. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: odd missing symbols like rumpns_lockdebug_* in an i386 build
> $ nm usr/lib/librump.so | fgrep rumpns_lockdebug_ >U rumpns_lockdebug_alloc > [...] > $ cd /usr/src > $ find . -type f -print0 | xargs -0 fgrep rumpns_lockebug_ > $ > So, now what? Where else should I look to debug this mess? Well, based on later mesages, it sounds as though you've found it. But, against possible future need, I'd suggest something like this, in your build's objdir: find . -name \*.o -print0 | xargs -0 nm -o | fgrep rumpns_lockdebug_ Then look at the build log to find out what that .o was built from and track it back from there. You may need to also search for other suffixes, like .pico or .po or whatnot; I am not familiar enough with the -9 build procedures to know what all the suffixes in question are. In case of desperation you could even do something more elaborate. Here's what comes to mind - it probably has bugs as written and is likely to be slow, but could probably be turned into a workable solution: find . -type f -print0 | xargs -0 file | sed -n -e '/relocatable/s/: .*//p' | tr \\n \\0 | xargs -0 nm -o | fgrep rumpns_lockdebug_ The tr can be replaced with flags to the following xargs if you have an xargs with an the ability to fix the whitespace-and-quoting misfeatures; I don't know whether 9's xargs(1) does. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: File sharing over virtio-9p
> [W]hich of the following is more readable to the user: > $ ls foo > ls: foo: No such file or directory > or > $ ls foo > ls: stat(foo): No such file or directory It depends entirely on the user. As I recently wrote on a non-NetBSD mailing list, there is no such thing as a good or bad user interface; there is only a good or bad user interfaces for a particular user (or class of sufficiently-similar users). I've lost track of the number of times I've had to resort to a sledgehammer such as ktrace to find out what's really going wrong because an error message doesn't report enough information. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: ./build.sh -k feature request (was Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled)
> The full release build is a number of substeps. It makes sense to > use -k for the main build of the system, after the tools build, to > get the "find all problems" property you want. But it's not clear to > me that it makes sense to build the main system if the tool build > fails. In make(1) terminology, this means that the entire main system build should depend on the tools build. If make(1) is not used for that ordering, whatever tool is used should implement -k semantics itself as aoppropriate, seems to me. > And it's not clear that sets should be produced. Similarly, sets should depend on the main build. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: ./build.sh -k feature request (was Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled)
>> Attached patch will do, objections against me comitting it? It >> allows all that is buildable to be build and the failing files to be >> compiled later when patched with the -u option. > I don't really like this. I would not be surprised if this broke > things in interesting ways for full world builds if you run into a > problem, cvs up and try an update build again. I submit that, if that is the case, the build is already broken and you just haven't yet tripped over a case that makes it unmistakeable. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: kqueue: SIGIO?
> On the other hand, if kernel changes would be needed (for example to > make SIGIO work with kqueue() on NetBSD) then we really should > evaluate whether or not there is a better change that could be made > to handle the situation, rather than just blindly making NetBSD the > same as linux. What that might be though I have no idea. The first thing that comes to mind is a syscall that tells the kernel to deliver signals, or at least certain signals, by changing a memory location rather than arranging to execute code. (I have trouble imagining an architecture on which checking a volatile int variable is more expensive than a syscall into the kernel.) It is true, though, that that's more-than-zero cost in the loop. But it might be close enough to zero to be acceptable. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: kqueue: SIGIO?
>> Mouse's idea of having the kernel write a flag word instead of
>> interrupting the process seems like a very nice fit if so.
> The issue with it is how one would ever safely clear the variable
> again, [...]
This is not difficult: you do it by not clearing the variable.
For the sake of argument and brevity, let us suppose a suitable type
for the variable in question is unsigned int. Then the kernel, instead
of _setting_ the variable, can _increment_ the variable, and userland
can do something like
volatile unsigned int sigflag;
unsigned int chksigflag;
unsigned int lastsigflag;
sigflag = 0;
lastsigflag = 0;
handle_via_flag_variable(SIGIO,); // flag to sigaction()?
while (1) { // main loop
...
chksigflag = sigflag;
if (chksigflag != lastsigflag) {
lastsigflag = chksigflag;
...handle the signal...
}
...
}
Obviously, there is still a potential issue; if the kernel delivers
exactly k*2^32 (for integer k, assuming 32-bit unsigned ints) signals,
between userland checks, userland will miss them. I don't consider
this a big enough risk to worry about; if it really bothers you, make
it long long int instead - there is some risk of value tearing in the
read on many architectures, but, since the kernel's increment is atomic
with respect to userland, the worst it will do is delay noticing the
signal by one trip around the loop.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
