Re: Help with a bug in mmap

> Date: Wed, 31 Oct 2018 22:01:14 +0530 > From: Siddharth Muralee > > Hello All, > I have recently been working on porting the kcov(4) feature to NetBSD. > The feature comes as a /dev module. I have been stuck for a while with the > mmap() function of the device. I have been trying to populat

Re: Help with a bug in mmap

> Date: Wed, 31 Oct 2018 23:16:49 +0100 > From: Kamil Rytarowski > > On 31.10.2018 18:05, Taylor R Campbell wrote: > > For the moment, as a provisional workaround to make progress, you can > > probably get by with `pa << PGSHIFT', where pa is the physical (byt

Re: pci_intr_alloc() vs pci_intr_establish() - retry type?

> Date: Tue, 27 Nov 2018 21:14:04 + > From: Robert Swindells > > It looks to me that drivers try MSI and/or MSIX first based on the > device type not on whether the host controller can handle it. Can we make the same API work for MSI, MSI-X, and INTx interrupts, so that we don't have to reme

HEADS UP: drmkms update incoming

I'm going to start an automated process to update our DRM/KMS graphics drivers. I've been working on this in Git, and I have a script to apply the changes to CVS as long as they apply cleanly. IF ANYTHING GOES WRONG AND THIS NEEDS TO BE INTERRUPTED: log into www.n.o and run touch ~riastradh/publ

Re: HEADS UP: drmkms update incoming

The drmkms update commit bomb is finished. I've compile-tested amd64, i386, macppc, sparc64, and evbarm/TEGRA, and they all build. I'll be around this evening US/Eastern to clean up fallout, of which I'm sure there will be some, but I need to get to $DAYJOB for a while now!

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> Date: Sat, 15 Dec 2018 10:30:13 +0100 > From: theo4...@borm.org > > Might I suggest that the obvious solution to this, and probably a host > of other issues, is to make time_t an always negative number > (negint/neglong?) and redefine the epoch as 03:14:09 UTC on Tuesday, 19 > January 2038, l

Re: RFC: vioif(4) multiqueue support

> Date: Wed, 26 Dec 2018 10:03:15 +0900 > From: Shoichi Yamaguchi > > > I implemented a patch that make vioif(4) support multi-queue. And I have put > > the patch on ftp.n.o. I used vioif(4) multiqueue on qemu-kvm on Linux kernel > > 4.19.5. And It seems to be working fine. > > > > https://ftp.ne

Re: Removing PF

Core decided a while ago that npf is the way forward and pf and ipf will be deprecated and removed at some point. It is not worth the effort to try to update pf or ipf. We are not removing pf or ipf immediately but they will certainly be deprecated in netbsd-9 so they can be gone in netbsd-10. W

Re: /dev/random is hot garbage

> Date: Sun, 21 Jul 2019 17:28:17 +0200 > From: Martin Husemann > > Replacing the /dev/random device node by a symlink to /dev/urandom sounds > fine. For binaries it is easy to just use the sysctl instead to get high > quality randomness. Are there any shell script like applications that > seriou

Re: /dev/random is hot garbage

> Date: Sun, 21 Jul 2019 11:55:23 -0400 > From: Greg Troxel > > I don't think we should change /dev/random. For a very long time, the > notion is that the bits from /dev/random really are ok for keys, and > there has been a notion that such bits are precious and you should be > prepared to wait

Re: /dev/random is hot garbage

> Date: Sun, 21 Jul 2019 20:52:52 +0200 > From: Manuel Bouyer > > /dev/randon actually works as documented and if rust wants /dev/urandom > behavior it should use /dev/urandom. Also I'd like to get explained why > a compiler needs that much random bits. The difference is that /dev/random may blo

Re: workqueue_destroy() can cause hanging up in the some cases

> Date: Fri, 6 Sep 2019 12:17:32 +0900 > From: Kengo NAKAHARA > > I found workqueue_destroy() for WQ_PERCPU workqueue can cause hanging up > while preempt disabled. The caller of workqueue_destroy() requires > for q_worker kthread to call kthread_exit(). In the implementation, > the caller do cv_

Re: fexecve

> Date: Sun, 8 Sep 2019 14:03:03 -0400 > From: Thor Lancelot Simon > > On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote: > > > > Here's a simple fexecve(2) implementation. Comments? > > I think this is dangerous in systems which use chroot into filesystems > mounted noexec (or no

Re: more fexecve questions

> Date: Tue, 10 Sep 2019 10:52:47 -0400 > From: chris...@zoulas.com (Christos Zoulas) > > 1. Looks like FreeBSD (and my initial posting) leaves the file descriptor >of the executable open in the process's image. The Linux man page says >to set close-on-exec if you don't want it to be passe

Re: more fexecve questions

> Date: Tue, 10 Sep 2019 16:03:23 - (UTC) > From: chris...@astron.com (Christos Zoulas) > > In article <20190910150418.becab60...@jupiter.mumble.net>, > Taylor R Campbell wrote: > >Can we just cache these when the file descriptor is opened with > >O_EXEC? &g

Re: __{read,write}_once

> Date: Wed, 6 Nov 2019 12:31:37 +0100 > From: Maxime Villard > > There are cases in the kernel where we read/write global memory locklessly, > and accept the races either because it is part of the design (eg low-level > scheduling) or we simply don't care (eg global stats). > > In these cases,

FYI: mb(9) API is finally going away

FYI: The mb(9) API -- consisting of the mb_read, mb_write, and mb_memory memory barriers -- was incomplete for users (failed to cover important use cases) and incompletely defined (not defined on some platforms like x86). It was intended to be removed over a decade ago in favour of the Solaris-sty

Re: __{read,write}_once

> Date: Sun, 24 Nov 2019 19:25:52 + > From: Taylor R Campbell > > This thread is not converging on consensus, so we're discussing the > semantics and naming of these operations as core and will come back > with a decision by the end of the week. We (core) careful

Re: FYI: mb(9) API is finally going away

The mb(9) API is now gone, except within sys/arch/mips where it is used inside __cpu_simple_lock -- there were too many ifdefs across components for me to disentangle, and the logic seems to be completely bonkers, e.g. on Octeon __cpu_simple_unlock issues a memory barrier _after_ the store to relea

Re: Why NetBSD x86's bus_space_barrier does not use [sml]fence?

> Date: Sat, 30 Nov 2019 19:47:17 +0900 > From: Shoichi Yamaguchi > > > Are you using BUS_SPACE_MAP_PREFETCHABLE? > > No, the driver does not use it. And it doesn't use mtrrs or BUS_SPACE_MAP_CACHEABLE either, right? Just to be sure, can you run to

Re: Why NetBSD x86's bus_space_barrier does not use [sml]fence?

> Date: Fri, 29 Nov 2019 14:49:33 + > From: Andrew Doran > > It no, the CALL instruction that calls bus_space_barrier() produces a write > to the stack when storing the return address. On x86, stores are totally > ordered, and loads are never reordered around stores. No further barrier > is

Re: Why NetBSD x86's bus_space_barrier does not use [sml]fence?

> Date: Mon, 2 Dec 2019 15:54:34 +0900 > From: Masanobu SAITOH > > On 2019/12/02 15:48, s ymgch wrote: > >> I had a misunderstanding. The driver uses BUS_SPACE_MAP_PREFETCHABLE > >> specified in PCI configuration space. > > This is well known pitfall: > > http://mail-index.netbsd.org/tech

New cpu_count races; seqlocks?

It is great to get rid of global contention over a bunch of counters that don't need to be read exactly. However, the new cpu_count logic is racy -- particularly on 32-bit platforms, where it's not simply a matter of reading stale values but a matter of reading total garbage: /* sys/cpu_data.h */

[PATCH] Address USB abort races

tex_exit(bus lock) -> -> wake and acquire lock -> xfer->ux_status = CANCELLED -> usb_transfer_complete(xfer) >From d1ffd7e3b7b26ba65542c5ab4289d5260daf6b25 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Fri, 10 Aug 2018 05:51:54 + Subject: [PATCH 1/7] Teach

Re: [PATCH] Kernel entropy rework

I guess I should have included a single unified diff rather than just a git format-patch set. From a CVS tree, the attached entropy-unified.patch can be applied with cd /path/to/src && patch -p1 < /path/to/entropy-unified.patch (And from a git tree, you can apply the patch set in the original em

Re: [PATCH] Address USB abort races

> Date: Mon, 23 Dec 2019 14:17:18 + > From: Nick Hudson > > - Any reason that dwc2 and ahci didn't get the conversion? At least dwc2 >should be done - I'm not sure ahci ever worked, but I've tried to keep >it up-to-date in the past. slhci probably needs some love too. I forgot to ch

Re: [PATCH] Kernel entropy rework

> Date: Sun, 22 Dec 2019 01:27:58 + > From: > > > On Dec 21, 2019, at 5:08 PM, Taylor R Campbell wrote: > > - For (e.g.) keyboard interrupt and network packet timings, this > >is zero, because an adversary can cause events to happen with >

Re: [PATCH v4 2/4] Fix alignment when reading core notes

> Date: Tue, 24 Dec 2019 07:52:14 +0100 > From: Micha� Górny > > On Mon, 2019-12-23 at 16:17 +, Christos Zoulas wrote: > > In article <20191222164104.165346-2-mgo...@gentoo.org>, > > Micha� Górny wrote: > > > Both desc and note header needs to be aligned. Therefore, we need > > > to real

Re: [PATCH] Kernel entropy rework

> Date: Thu, 26 Dec 2019 20:16:20 + > From: m...@netbsd.org > > On Sat, Dec 21, 2019 at 10:08:20PM +0000, Taylor R Campbell wrote: > > - Replace SHA-1/LFSR entropy pool by Keccak sponge. > > The peanut gallery would like to inquire if you have a secret BLAKE2 >

Re: Rump dependencies (5.2)?

> Date: Sun, 12 Jan 2020 21:56:30 -0500 (EST) > From: Mouse > > But now, when I try to build the world, rump_nfs fails to link, citing > as undefined two routines I added to uipc_usrreq.c which are referred > to from uipc_syscalls.c. > > This leads me to ask - and I realize it's possible nobody

Proposal: Remove filemon(4); switch make meta to ktrace

el. Do you use filemon(4)? Objections? Thoughts? >From 656117e6a394087bbf134a8a1c09b0ff9248f4cc Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Mon, 23 Dec 2019 05:41:16 + Subject: [PATCH 1/2] Reimplement make(1) meta mode without filemon(4). --- usr.bin/make/Makefile | 7 +- usr

Re: Proposal: Remove filemon(4); switch make meta to ktrace

> Date: Mon, 13 Jan 2020 06:09:20 -0500 (EST) > From: Mouse > > > - What instead? The attached patch (patch set make-meta-v2.patch; > > combined diff make-meta-v2.diff) replaces make's use of > > /dev/filemon by ktrace, in meta mode. > > How does this interact with someone ktracing a make r

Re: libc.so's vmobjlock / v_interlock

> Date: Sun, 19 Jan 2020 21:50:24 + > From: Andrew Doran > > The biggest single remaining concurency problem is the mutex on libc.so's > uvm_object / vnode. It pops up in a number of places, but most clearly seen > above the "uvm_fault_internal" box. > > I think making the vmobjlock / v_int

Re: percpu_foreach() does not execute remotely

> Date: Mon, 27 Jan 2020 18:36:17 -0800 > From: Jason Thorpe > > So, percpu_foreach() is pretty handy for enumerating data that's > managed on a per-cpu basis. But there's a problem ... it does not > actually execute the callback on the remote CPU, instead getting a > pointer to the remote data

Re: percpu_foreach() does not execute remotely

> Date: Tue, 28 Jan 2020 08:52:35 -0800 > From: Jason Thorpe > > 1- This seems to be a general issue with percpu_foreach(). I mean, > one of the main purposes of per-cpu storage is that other CPUs don't > touch it, and percpu_foreach() completely violates the POLA in this > regard. I see percpu

Re: percpu_foreach() does not execute remotely

> Date: Tue, 28 Jan 2020 09:08:22 -0800 > From: Jason Thorpe > > >> 2- If I were to use xc_broadcast(), then in the case of network > >> protocol / interface stats, I would need to use either atomic > >> operations or add some other synchronization into the shared > >> "exported copy" of the data

Re: percpu_foreach() does not execute remotely

> Date: Tue, 28 Jan 2020 18:54:59 -0800 > From: Jason Thorpe > > Something like this. I haven't tested this yet, but I will shortly. > Only high-pri xcalls are supported in this -- to make low-pri xcalls > work, you'd need to change how percpu_cpu_swap() interlocks with > percpu_foreach(). High

Re: percpu_foreach() does not execute remotely

> Date: Tue, 28 Jan 2020 20:00:00 -0800 > From: Jason Thorpe > > Hm, actually, I think you are right, but because of a property of > xcalls themselves... > > -- percpu_cpu_swap() is a low-pri xcall, and thus won't run > concurrently with a low-pri percpu_foreach_xcall(), so no need to > grab per

Re: percpu_foreach() does not execute remotely

> Date: Tue, 28 Jan 2020 20:49:50 -0800 > From: Jason Thorpe > > What happens if: > > oink = percpu_getref(...); > ... > mutex_enter(...); // blocks for a long time for whatever reason. > // while we're blocked, someone else does a percpu_alloc() that results >

Re: percpu_foreach() does not execute remotely

[Cc'ing the wizards at IIJ because a diagnostic measure we're discussing may require adapting the network stack.] > Date: Wed, 29 Jan 2020 05:43:39 -0800 > From: Jason Thorpe > > > On Jan 28, 2020, at 9:46 PM, Taylor R Campbell > > wrote: > > > > No

[PATCH] percpu_create -- associate ctors and dtors

We have a number of abuses of percpu_foreach in tree: percpu_foreach forbids sleeping on allocation, but a number of subsystems use it to allocate memory to which pointers are stored in percpu objects because the percpu objects themselves may move around in memory. Each ad hoc abuse of percpu_fore

Re: [PATCH] percpu_create -- associate ctors and dtors

> Date: Thu, 30 Jan 2020 02:46:42 + > From: Taylor R Campbell > > The attached patch set [...] Some day, perhaps I will not be bad at attachments. That day, however, has yet to come. >From 32542bb28f86862f91fcf874f2b7494d4df00c62 Mon Sep 17 00:00:00 2001 From: Taylor R Camp

Re: fault(4)

> Date: Sat, 8 Feb 2020 06:19:43 -0800 (PST) > From: Paul Goyette > > If this is a device on which you can use ioctl() to configure, why is > it not stored under sys/dev and why is it not included in kernel config > with pseudo-device directive (and corresponding files.kern changes)? There's no

Re: closing pad(4) before audio(4) causes panic

> Date: Sun, 02 Feb 2020 14:25:12 +0900 > From: Tetsuya Isaki > > According to audio.c comment, vdevgone() calls close(). But it is > not called actually. vdevgone calls VOP_REVOKE on the vnode, which _used_ to call audio_close, but it does essentially nothing for cloning file descriptors as we

Re: config_mounroot - spinout while attaching nouveaufb0 on amd64 with LOCKDEBUG

> Date: Mon, 17 Feb 2020 00:29:03 +0100 > From: Jaromír Doleček > > while debugging the MSI attachment for nouveaufb0, I've got several > times spinout panic like one below. It doesn't happen on every boot, > but on almost every one. > > I confirmed via ddb that this happens due to config_mountr

Re: NULL pointer arithmetic issues

> Date: Sat, 22 Feb 2020 17:25:42 +0100 > From: Kamil Rytarowski > > When running the ATF tests under MKLIBCSANITIZER [1], there are many > NULL pointer arithmetic issues . > > http://netbsd.org/~kamil/mksanitizer-reports/ubsan-2020-02-22-null-pointer.txt > > These issues are in macros like: >

Re: NULL pointer arithmetic issues

> Date: Sun, 23 Feb 2020 22:51:08 +0100 > From: Kamil Rytarowski > > On 23.02.2020 20:08, Taylor R Campbell wrote: > Date: Sun, 23 Feb 2020 22:51:08 +0100 > From: Kamil Rytarowski > > On 23.02.2020 20:08, Taylor R Campbell wrote: > >> Date: Sat, 22 Feb 202

Re: NULL pointer arithmetic issues

> Date: Mon, 24 Feb 2020 11:42:01 +0100 > From: Kamil Rytarowski > > Forbidding NULL pointer arithmetic is not just for C purists trolls. It > is now in C++ mainstream and already in C2x draft. > > The newer C standard will most likely (already accepted by the > committee) adopt nullptr on par w

Re: NULL pointer arithmetic issues

Thanks for doing the research. > Date: Sun, 8 Mar 2020 15:30:02 +0100 > From: Kamil Rytarowski > > NULL+0 was added to UBSan proactively as it is as of today not > miscompiled, but it is planned to so in not so distant time. It is a > chicken-egg problem. If you say it is planned, can you pleas

Re: NULL pointer arithmetic issues

> Date: Sun, 8 Mar 2020 20:52:29 +0300 > From: Roman Lebedev > > so we are allowed to lower that in clang front-end as: > > int > statu(char *a) > { > __builtin_assume(a != NULL); > a += getuid() - geteuid(); > __builtin_assume(a != NULL); Allowed, yes. What I'm wondering is whether this

Re: Please review: lookup changes

> Date: Thu, 5 Mar 2020 22:48:25 + > From: Andrew Doran > > I'd like to merge the changes on the ad-namecache branch, and would > appreciate any code review. The motivation for these changes is, as > you might guess, performance. I put an overview below. I won't be > merging this for a cou

Re: Please review: lookup changes

> Date: Mon, 9 Mar 2020 19:59:03 + > From: Andrew Doran > > As far as I recall layer vnodes persist unless recycled like any other > vnode, so there should be nothing special happening there around contention > due to lifecycle. I think you could cache or transpose the cached names > above,

Re: Avoid UB in pslist.h (NULL + 0)

> Date: Sun, 22 Mar 2020 00:03:57 +0100 > From: Kamil Rytarowski > > I propose to change the fun(pointer + 0) logic with fun(pointer, 0). I don't think this is a good approach -- it requires modifying code further and further away from the relevant part. But let's step back a moment. So far,

Re: Avoid UB in pslist.h (NULL + 0)

> Date: Sun, 22 Mar 2020 03:30:56 +0100 > From: Kamil Rytarowski > > On 22.03.2020 01:50, Taylor R Campbell wrote: > > So far, after several weeks of discussion, nobody has presented a case > > that there is a credible thread of a compiler actually misbehaving in >

Re: Reduce contention on fstrans_lock

> Date: Sat, 4 Apr 2020 14:37:44 -0700 > From: Jason Thorpe > > +static int > +fstrans_lwp_ctor(void *arg, void *obj, int flags) > +{ > + struct fstrans_lwp_info *fli = obj; > + > + memset(fli, 0, sizeof(*fli)); > + membar_sync(); > + mutex_enter(&fstrans_lock); > + LIST_INSER

getrandom and getentropy

ual, 2017-09-15. http://man7.org/linux/man-pages/man3/getentropy.3.html [7] `getentropy -- get entropy', FreeBSD 12.1-RELEASE Manual Pages, BSD Library Functions Manual, 2018-02-24. https://www.freebsd.org/cgi/man.cgi?query=getentropy&sektion=3&apropos=0&manpat

Re: Initial entropy with no HWRNG

[trimming cc list to tech-crypto] > Date: Tue, 12 May 2020 11:45:58 -0400 > From: Thor Lancelot Simon > > 1) It's hard to understand how many bits of entropy to assign to a >sample from one of these sources. [...] > >The delta estimator _was_ good for these things, particularly for >

Re: sys/idtype.h unused enumeration values

> Date: Mon, 18 May 2020 21:11:36 +0200 > From: Kamil Rytarowski > > On 18.05.2020 20:24, Robert Elz wrote: > > Date:Mon, 18 May 2020 19:45:55 +0200 > > From:Kamil Rytarowski > > Message-ID: > > > > | I have got a local use-case for another P_type (premature to d

Re: sys/idtype.h unused enumeration values

> Date: Mon, 18 May 2020 21:40:16 +0200 > From: Kamil Rytarowski > > If I delete P_TASKID ... P_P_CPUID ones, P_SETID will be reordered (but > we can force the number anyway). If I delete P_CID there is an inelegant > hole. Naturally P_SETID -> P_CID can fill the gap. > > This is in theory ABI c

Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

> Date: Mon, 18 May 2020 17:51:51 -0400 > From: Thor Lancelot Simon > > On Mon, May 18, 2020 at 09:08:14PM +0100, Alexander Nasonov wrote: > > matthew green wrote: > > > what's the use-case for disabling encrypted swap later? > > > > It might be too slow on some machines. > > > > > i'd argue we

Re: TSC improvement

It's great to see improvements to our calibration of the TSC (and I tend to agree that cpu_counter should be serializing, so that, e.g., cpu_counter(); ...; cpu_counter() reliably measures time taken in the ellipsis). At the same time, I wonder whether we should _also_: 1. Modify the tsc timecoun

Re: TSC improvement

> Date: Wed, 10 Jun 2020 23:11:32 + > From: Andrew Doran > > On Tue, Jun 09, 2020 at 05:16:27PM +0000, Taylor R Campbell wrote: > > > At the same time, I wonder whether we should _also_: > > > > 1. Modify the tsc timecounter so that it uses a global atomic

Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Thu, 18 Jun 2020 07:19:43 +0200 > From: Martin Husemann > > One minor nit: with the performance impact that high, and there being > setups where runtime side channel attacks are totally not an issue, > maybe we should leave the old code in place for now, #ifdef'd as > default-off options

Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Thu, 18 Jun 2020 07:06:16 -0400 > From: Greg Troxel > > For me, the main use of cgd is to encrypt backup drives. [...] > > I don't really see the new cipher as a reasonable option for removable > disks that need to be accessed by older systems. I can see it for > encrypted local disk. B

Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Thu, 18 Jun 2020 09:37:36 -0700 > From: Brian Buhrow > > hello. I have what may be a silly question. Does this change mean > that I386 users won't have AES capabilities in the kernel at all going > forward? (I gather that's true for architectures like Sparc, but I'm > assuming th

Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Thu, 18 Jun 2020 13:18:13 + > From: > > > On Jun 17, 2020, at 7:36 PM, Taylor R Campbell wrote: > > Performance impact: The cost is that constant-time AES software is > > much slower -- cgd AES-CBC encryption throughput is reduced to > > a

Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Thu, 18 Jun 2020 17:17:56 + > From: Taylor R Campbell > > > Date: Thu, 18 Jun 2020 09:37:36 -0700 > > From: Brian Buhrow > > > > hello. I have what may be a silly question. Does this change mean > > that I386 users won't have

Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Thu, 18 Jun 2020 11:37:36 -0700 > From: Brian Buhrow > > Does xen advertise and allow the use of these instructions on PV and PVH > domu's? Generally I would expect yes. You can test on a particular system with `cpuctl identify'. For example: # cpuctl identify 0 | grep -w AES cpu0: fe

Straw proposal: MI kthread vector/fp unit API

Here's a straw proposal for an MI API to allow a kthread to use any vector or floating-point unit on the CPU -- call it the `FPU' for brevity. The MI concept of `the FPU' encompasses _all_ vector or floating-point units that userland threads would have access to, so we don't have to complicate it

Re: Straw proposal: MI kthread vector/fp unit API

> Date: Sat, 20 Jun 2020 18:52:03 -0700 > From: Erik Fair > > Back in the day, these additional (potentially optional) computation > units (e.g., FPU, GPU, vector engine(s)) were generically referred > to as "co-processors" as a class. Only units that are normally accessible through ordinary CPU

Re: Straw proposal: MI kthread vector/fp unit API

> Date: Mon, 22 Jun 2020 18:45:47 + (UTC) > From: Eduardo Horvath > > I think this is sort of a half-measure since it restricts > coprocessor usage to a few threads. If you want to say, implement > the kenrel memcopy using vector registers (the way sparc64 does) > this doesn't help and may e

Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Thu, 18 Jun 2020 20:21:36 -0400 > From: Greg Troxel > > Taylor R Campbell writes: > > > Can you be more specific about the systems you're concerned about? > > What I meant is: consider an external USB disk of say 4T, which has a > cgd partitio

Lazy FPU switching [was Re: Straw proposal: MI kthread vector/fp unit API]

[subject line changed because this has gone afield from the proposed kthread flag] > Date: Wed, 24 Jun 2020 06:36:17 +0200 > From: Martin Husemann > > On Tue, Jun 23, 2020 at 11:14:30PM +0200, Jaromír Dole?ek wrote: > > No lazy FPU save logic please. It was eradicated from x86 for a reason: > >

Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Mon, 22 Jun 2020 23:43:20 + > From: Taylor R Campbell > > There is some more room for improvement -- SSSE3 provides PSHUFB which > can sequentially speed up parts of AES, and is supported by a good > number of amd64 CPUs starting around 14 years ago that lack AES

Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Wed, 17 Jun 2020 23:36:11 + > From: Taylor R Campbell > > [bcc tech-crypto, tech-security; followups to tech-kern] > > It's been well-known since 2005[1] that naive AES software, like we > use today in the NetBSD kernel, is vulnerable to cache-timin

Re: AES leaks, cgd ciphers, and vector units in the kernel

> Date: Tue, 30 Jun 2020 00:43:15 + > From: Taylor R Campbell > > - bitsliced AES four blocks at a time with SSE2 on all x86 Correction: all amd64, but not all x86 -- there are i386 CPUs without SSE2, of course, but they are mostly >=20 years old at this point.

Re: Waiting for a bit in a register to be cleared: which strategy?

> Date: Fri, 3 Jul 2020 15:52:31 +0200 > From: Rocky Hotas > > This works only because REG_A has all 0s except the LSB: when the LSB > becomes 0, too, the while exits. But I am actually interested only in > the LSB and would like to disregard the other 7 bits in the register. > What could it be t

Re: Proposal to enable WAPBL by default for 10.0

> Date: Thu, 23 Jul 2020 07:45:08 +0200 > From: Michał_Górny > > On Thu, 2020-07-23 at 05:17 +, David Holland wrote: > > The problem is that because it still doesn't do anything about > > journaling or preserving file contents, but runs a lot faster, it > > loses more data when interrupted. >

Re: Proposal to enable WAPBL by default for 10.0

> Date: Thu, 23 Jul 2020 08:43:04 -0400 > From: Greg Troxel > > Taylor R Campbell writes: > > [lots of good points, no disagreement] > > If /etc/master.passwd is ending up with junk, that's a clue that code > that updates it isn't doing the write seconda

Re: /dev/crypto missing

> Date: Tue, 28 Jul 2020 01:10:34 + (UTC) > From: John Klos > > I erroneously thought that if pseudo-device crypto wasn't in the kernel, > crypto would be done in userland. That's not the case: What makes you think crypto isn't being done in userland? The problem looks to me like the serve

Re: futexes

> Date: Sat, 15 Aug 2020 19:59:24 +0100 > From: Robert Swindells > > Is anyone working on the proposed solution to kern/55230 ? thorpej was working on it and has a patch -- I thought it got committed, but I guess not? There might have been some hard-to-fix bug remainining in it but I forget the

Re: "wireguard" implementation improperly merged and needs revert

[followups to tech-net to reduce cross-posting noise] Hi, Jason! Sorry about not reaching out. The history is that the code has been kicking around the NetBSD world since Ozaki-san first wrote it in 2018, without getting merged into src. It felt a shame to let it wallow in that state indefinite

[PATCH] Make workqueue(9) use threadpool(9)

there is a shortage of threads dynamically assigned to do work under load, the threadpool(9) logic will block until they can be created. Thoughts? # HG changeset patch # User Taylor R Campbell # Date 1599431734 0 # Sun Sep 06 22:35:34 2020 + # Branch trunk # Node ID 83b001debedf1ab0bf9

Re: Logging a kernel message when blocking on entropy

> Date: Tue, 22 Sep 2020 13:07:04 +0300 > From: Andreas Gustafsson > > The following patch will cause a kernel message to be logged when a > process blocks on /dev/random or some other randomness API. It may > help some users befuddled by pkgsrc builds blocking on /dev/random, > and I'm finding

Re: Question about atomic FIFO/LIFO queues

> Date: Fri, 25 Sep 2020 17:58:41 -0400 > From: Ruslan Nikolaev > > I came across this page > https://wiki.netbsd.org/projects/project/atomic_fifo_lifo_queues/ > > Recently, we have designed a high-performant (and what is also very > important -- truly lock-free -- not just "lockless") and mem

Re: /dev/random issue

> Date: Thu, 1 Oct 2020 18:30:29 +0200 > From: Manuel Bouyer > > that doens't explain why the other sources of entropy, which were working > bedore, are not working any more. They are working exactly as well as they did before. What is different is that NetBSD is no longer lying to you about ho

Re: NVMM missing opcode REPE CMPS implementation, version 2

> Date: Sun, 1 Nov 2020 10:16:17 +0100 > From: Maxime Villard > > Note that the main NVMM tree is not NetBSD anymore. Is there now an upstream tree that we should be following? If yes, where?

Re: Question about atomic FIFO/LIFO queues

> Date: Thu, 5 Nov 2020 23:39:22 -0500 > From: Ruslan Nikolaev > > Would you like us to explore if pcq can be replaced with our new DISC'19 > algorithm potentially? How critical for the overall networking > performance is this code? I don't know offhand how much of a bottleneck the pcq(9) code

Re: Kernel panic when using Security Key with Firefox

> Date: Sun, 22 Nov 2020 20:42:58 +0100 > From: Benny Siegert > > On my Pinebook Pro (9.0 userland with current kernel), when logging in > to github.com in Firefox, as soon as I click the "use security key" > button with the key inserted, I get a kernel panic. See the photo at > https://photos.ap

Waiting for Randot (or: nia and maya were right and I was wrong)

[bcc tech-kern, tech-security, tech-crypto; followups to tech-userlevel to keep discussion in one place] Many of you have no doubt noticed that a lot more things hang waiting for entropy than used to on machines without hardware random number generators (even as we've added a bunch of new drivers

Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)

> Date: Tue, 30 Mar 2021 23:53:43 +0200 > From: Manuel Bouyer > > On Tue, Mar 30, 2021 at 02:40:18PM -0700, Greg A. Woods wrote: > > [...] > > > > Perhaps the answer is that nothing seems to be contributing anything to > > the entropy pool. No matter what device I exercise, none of the numbers

Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)

> Date: Tue, 30 Mar 2021 16:23:43 -0700 > From: "Greg A. Woods" > > At Tue, 30 Mar 2021 23:53:43 +0200, Manuel Bouyer > wrote: > > On Tue, Mar 30, 2021 at 02:40:18PM -0700, Greg A. Woods wrote: > > > Perhaps the answer is that nothing seems to be contributing anything to > > > the entropy pool.

Re: regarding the changes to kernel entropy gathering

> Date: Sat, 03 Apr 2021 12:24:29 -0700 > From: "Greg A. Woods" > > Updating a system, even on -current, shouldn't create a long-lived > situation where the system documentation and the behaviour and actions > of system commands is completely out of sync with the behaviour of the > kernel, and in

Re: regarding the changes to kernel entropy gathering

> Date: Sun, 4 Apr 2021 10:40:22 -0400 (EDT) > From: Mouse > > > 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

Re: regarding the changes to kernel entropy gathering

> Date: Sun, 04 Apr 2021 23:47:10 +0700 > From: Robert Elz > > Date:Sun, 4 Apr 2021 15:28:13 + > From: Taylor R Campbell > Message-ID: <20210404152814.3c56360...@jupiter.mumble.net> > > | you can let NetBSD take care of it aut

Re: regarding the changes to kernel entropy gathering

> Date: Sun, 4 Apr 2021 11:14:31 -0700 > From: John Nemeth > > I understand the need for good random sources, and won't argue > it. 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/RDSE

Re: regarding the changes to kernel entropy gathering

> Date: Sun, 04 Apr 2021 12:58:09 -0700 > From: "Greg A. Woods" > References: > <20210404094958.692f360...@jupiter.mumble.net> > > At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell > wrote: > Subject: Re: regarding the changes to kernel entropy

Re: regarding the changes to kernel entropy gathering

> Date: Sun, 4 Apr 2021 21:24:56 + (UTC) > From: RVP > > I think running the /dev/random bit-stream through some statistical > tests, (both on RDRAND/RDSEED-based and estimator-based as in your > patch) would be useful here. No, because the output of /dev/random and /dev/urandom is the outpu

Re: regarding the changes to kernel entropy gathering

> Date: Mon, 5 Apr 2021 01:16:56 + (UTC) > From: RVP > > Then, the issue here is one of predictability. NetBSD doesn't want, > for extremely valid reason, to incorporate any perturbation sources > which have been pooh-poohed in the technical literature. Why do you say that? We do incorporat

Re: regarding the changes to kernel entropy gathering

> Date: Mon, 05 Apr 2021 10:58:58 +0700 > From: Robert Elz > > I understand that some people desire highly secure systems (I'm not > convinced that anyone running NetBSD can really justify that desire, > but that's beside the point) and that's fine - make the system be able > to be as secure as p

<    1   2   3   4   5   6   7   8   >