Re: Adding a boot flag for No ASLR

On 23.07.2018 15:09, Joerg Sonnenberger wrote: > On Mon, Jul 23, 2018 at 06:24:09PM +0530, Siddharth Muralee wrote: >>> >>> >>> (1) An implementation detail of userland shouldn't be leaked into the >>> kernel boot (!) process. >>> >> >> Okay. I think this makes sense(I am still pretty new to

Re: Adding a boot flag for No ASLR

On 23.07.2018 14:54, Siddharth Muralee wrote: > > (1) An implementation detail of userland shouldn't be leaked into the > kernel boot (!) process. > > > Okay. I think this makes sense(I am still pretty new to NetBSD) - Can > you suggest some other location/config that can be used. >

Re: Adding a boot flag for No ASLR

On 23.07.2018 14:48, Martin Husemann wrote: > On Mon, Jul 23, 2018 at 06:11:49PM +0530, Siddharth Muralee wrote: >> Hello, >>I have recently been working on adding a new boot flag for disabling >> ASLR during boot. I feel that this is useful since MKSANITZER userland >> (specifically Address

Re: aarch64 gcc kernel compilation

On 17.07.2018 07:23, Ryo Shimizu wrote: > > Can we drop it? The __uint128_t type is not used anywhere else in > aarch64 subdirs. > > fortunately, we don't use member of fpreg, use just only as container. > Is this patch enough? > I was thinking about this one:

Re: aarch64 gcc kernel compilation

On 16.07.2018 11:07, Kamil Rytarowski wrote: > On 16.07.2018 10:50, Kamil Rytarowski wrote: >> On 16.07.2018 00:00, Kamil Rytarowski wrote: >>> On 15.07.2018 20:08, Christos Zoulas wrote: >>>> Hi, >>>> >>>> Gcc is now working on aarch6

Re: aarch64 gcc kernel compilation

On 16.07.2018 10:50, Kamil Rytarowski wrote: > On 16.07.2018 00:00, Kamil Rytarowski wrote: >> On 15.07.2018 20:08, Christos Zoulas wrote: >>> Hi, >>> >>> Gcc is now working on aarch64 but the kernel does not compile because of >>> some idiomatic clan

Re: aarch64 gcc kernel compilation

On 15.07.2018 20:08, Christos Zoulas wrote: > Hi, > > Gcc is now working on aarch64 but the kernel does not compile because of > some idiomatic clang code that is not supported by gcc (at least gcc-6) > > To define constants, it uses: > > static const uintmax_t > FOO = __BIT(9), > BAR = FOO; >

Re: Removing dbregs

On 14.07.2018 17:55, Maxime Villard wrote: > Le 14/07/2018 à 17:40, Kamil Rytarowski a écrit : >> On 14.07.2018 12:52, Maxime Villard wrote: >>> Le 14/07/2018 à 10:29, Martin Husemann a écrit : >>>> On Fri, Jul 13, 2018 at 11:49:33PM +0200, Kamil Rytarowski wrote: &

Re: Removing dbregs

On 14.07.2018 12:52, Maxime Villard wrote: > Le 14/07/2018 à 10:29, Martin Husemann a écrit : >> On Fri, Jul 13, 2018 at 11:49:33PM +0200, Kamil Rytarowski wrote: >>> #ifdefing it out in a non-benchmarking application (I was checking ones >>> that do something with s

Re: Removing dbregs

On 14.07.2018 12:52, Maxime Villard wrote: > Le 14/07/2018 à 10:29, Martin Husemann a écrit : >> On Fri, Jul 13, 2018 at 11:49:33PM +0200, Kamil Rytarowski wrote: >>> #ifdefing it out in a non-benchmarking application (I was checking ones >>> that do something with s

Re: Removing dbregs

On 13.07.2018 23:32, Jason Thorpe wrote: > > >> On Jul 13, 2018, at 2:22 PM, Kamil Rytarowski wrote: >> >> On 13.07.2018 23:10, Jaromír Doleček wrote: >>> 2018-07-13 22:54 GMT+02:00 Kamil Rytarowski : >>>> I disagree with disabling it. The code is

Re: Removing dbregs

On 13.07.2018 23:10, Jaromír Doleček wrote: > 2018-07-13 22:54 GMT+02:00 Kamil Rytarowski : >> I disagree with disabling it. The code is not broken, it's covered by >> tests, it's in use. > > This looks like perfect candidate for optional (default off) feature. > It

Re: Removing dbregs

On 13.07.2018 22:44, Maxime Villard wrote: > Le 13/07/2018 à 21:54, Kamil Rytarowski a écrit : >> On 13.07.2018 21:31, Maxime Villard wrote: >>> I don't like the dbregs code. We unconditionally write into %dr6 and >>> %dr7 in >>> userret, that is, during each i

Re: Removing dbregs

On 13.07.2018 21:31, Maxime Villard wrote: > I don't like the dbregs code. We unconditionally write into %dr6 and > %dr7 in > userret, that is, during each interruptible kernel->user transition. > > Some measurements with PMCs show that the loads of dr6/dr7 are one of the > first sources of

Re: Too many PMC implementations

On 12.07.2018 08:48, Maxime Villard wrote: > Le 11/07/2018 à 19:49, Kamil Rytarowski a écrit : >> I'm not familiar with the internals myself, but from API point of view, >> something usable for porting rr (https://github.com/mozilla/rr) or even >> Linux perf-top is high

Re: Too many PMC implementations

On 11.07.2018 18:22, Maxime Villard wrote: > Right now we have three (or more?) different implementations for > Performance > Monitoring Counters: > >  * PMC: this one is MI. It is used only on one ARM model (xscale I think). >    There used to be an x86 code for it, but it was broken, and I

Re: 8.0 performance issue when running build.sh?

On 11.07.2018 11:47, Takeshi Nakayama wrote: Martin Husemann wrote > >>> Another observation is that grep(1) on one NetBSD server is >>> significantly slower between the switch from -7 to 8RC1. >> >> Please file separate PRs for each (and maybe provide some input files >> to reproduce the

Re: 8.0 performance issue when running build.sh?

On 11.07.2018 09:09, Simon Burge wrote: > Hi folks, > > Martin Husemann wrote: > >> On Tue, Jul 10, 2018 at 12:11:41PM +0200, Kamil Rytarowski wrote: >>> After the switch from NetBSD-HEAD (version from 1 year ago) to 8.0RC2, >>> the ld(1) linker has serious i

Re: 8.0 performance issue when running build.sh?

On 10.07.2018 11:01, Martin Husemann wrote: > On Fri, Jul 06, 2018 at 04:04:50PM +0200, Martin Husemann wrote: >> I have no scientific data yet, but just noticed that build times on the >> auto build cluster did rise very dramatically since it has been updated >> to run NetBSD 8.0 RC2. >> >> Since

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 17:44, Kamil Rytarowski wrote: > I will try to scratch a new header unaligned.h with the set of macros > and submit it to evaluation. I've prepared a scratch of unaligned.h with get_unaligned(): http://netbsd.org/~kamil/kubsan/unaligned.h There are at least two problems to p

Re: CVS commit: src/sys/arch/x86/x86

On 09.07.2018 16:58, Thor Lancelot Simon wrote: > On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote: >> >> The C11 standard could indeed use consistent wording. In one place >> "correctly aligned" in other alignment "restrictions" and >>

Re: CVS commit: src/sys/arch/x86/x86

On 09.07.2018 11:32, Martin Husemann wrote: > On Mon, Jul 09, 2018 at 11:00:15AM +0200, Kamil Rytarowski wrote: >> According to my understanding, alignment requirement for a type/object >> is implementation defined (6.2.8); however during the process of >> converting types, if

Re: CVS commit: src/sys/arch/x86/x86

On 09.07.2018 10:09, Martin Husemann wrote: > On Sun, Jul 08, 2018 at 03:30:36PM +0200, Kamil Rytarowski wrote: >> Misaligned pointer is explicitly documented as undefined behavior in the >> C standard (C11 6.3.2.3 p7). (In C++ it's basically the same.) > > Yes, but the st

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 17:30, Mouse wrote: > Caveat: this is all opinion. I'm not the one doing the work here. > > src/sys/arch/x86/x86: mpbios.c > > Remove unaligned access to mpbios_page[] > > sys/arch/x86/x86/mpbios.c:308:11, load of misaligned address > 0x800031c7a413

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 17:16, Jason Thorpe wrote: > > >> On Jul 8, 2018, at 6:30 AM, Kamil Rytarowski wrote: >> >> In future __NO_STRICT_ALIGNMENT could be defined for aarch64, at least >> for the use of acpica (which still contains a fallback for Itanium >> without

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 15:53, Jaromír Doleček wrote: > Le dim. 8 juil. 2018 à 15:29, Kamil Rytarowski a écrit : >> I've introduced the change to mpbios.c as it was small, selfcontained >> and without the need to decorate the whole function. > > Am I reading the code wrong or you ac

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 11:24, Martin Husemann wrote: > On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: >>> Module Name:src >>> Committed By: kamil >>> Date: Sat Jul 7 23:05:50 UTC 2018 >>> >>> Modified Files: >>> src/sys/arch/x86/x86: mpbios.c >>> >>> Log Message:

Re: ./build.sh -k feature request (was Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled)

On 25.06.2018 22:33, Reinoud Zandijk wrote: > On Mon, Jun 25, 2018 at 10:29:30PM +0200, Kamil Rytarowski wrote: >> I'm usually going the other direction. If I hit a problem and an issue >> is not visible from a multi-job build (multiple processes print onto the >> same scree

Re: ./build.sh -k feature request (was Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled)

On 25.06.2018 20:23, Reinoud Zandijk wrote: > On Sun, Jun 24, 2018 at 10:01:42PM +0200, Reinoud Zandijk wrote: >> On Wed, May 30, 2018 at 07:11:19PM +0800, Harry Pantazis wrote: >>> Continuing.. >>> >>> This first errors are located in >>> src/sys/external/bsd/drm2/dist/drm/i915/intel_ddi.c and

Re: Apply for 'userland PCIe driver'

On 13.06.2018 20:20, Timbo Tim wrote: > Hi. I'd like to  work on userland PCIe driver for my thesis starting > around the beginning of next year if my proposal get accepted (not > related to GSoC). Can I apply on this one? What's your familiarity with PCI specification? Are you familiar with

Re: New getsockopt2() syscall

On 09.06.2018 16:05, Martin Husemann wrote: > On Sat, Jun 09, 2018 at 10:22:06AM +0200, Kamil Rytarowski wrote: >> Can we reuse unused old syscall numbers? > > Reuse in general not (that would break any possible compat for that). > But there are some unused numbers li

Re: New getsockopt2() syscall

On 08.06.2018 23:18, Robert Swindells wrote: > > Are there any objections to the code for a getsockopt2() syscall > in: > > > Can we reuse unused old syscall numbers? signature.asc Description: OpenPGP digital signature

Re: GENERIC Kernel Build errors with -fsanitize=undefined option enabled

On 30.05.2018 12:51, Harry Pantazis wrote: > Greetings, > > I'm working on the task of utilizing Undefined Behavior checks for the > NetBSD/amd64 kernel (KUBSan). I have built the GENERIC kernel with the > -fsanitize=undefined option enabled and I've caught a first series of > errors caused

Re: QEMU/NetBSD status wiki page

On 27.05.2018 20:04, Warner Losh wrote: > > > On Sun, May 27, 2018 at 11:57 AM, Kamil Rytarowski <n...@gmx.com > <mailto:n...@gmx.com>> wrote: > > On 27.05.2018 16:53, Warner Losh wrote: > > > > > > On Sun, May 27, 2018 at 4:05

Re: QEMU/NetBSD status wiki page

On 27.05.2018 16:53, Warner Losh wrote: > > > On Sun, May 27, 2018 at 4:05 AM, Kamil Rytarowski <n...@gmx.com > <mailto:n...@gmx.com>> wrote: > > As requested, I've prepared a QEMU/NetBSD status page: > > http://wiki.netbsd.org/users/kamil/qemu/

QEMU/NetBSD status wiki page

As requested, I've prepared a QEMU/NetBSD status page: http://wiki.netbsd.org/users/kamil/qemu/ I've attempted to be rather conservative with claims that something works, without detailed verification. signature.asc Description: OpenPGP digital signature

Re: e_trapsignal removal

On 27.04.2018 21:11, Christos Zoulas wrote: > In article <b80b33fb-de4f-01dd-1705-716a2c0ec...@gmx.com>, > Kamil Rytarowski <n...@gmx.com> wrote: >> -=-=-=-=-=- >> -=-=-=-=-=- >> >> I propose to remove e_trapsignal from the compat framework >> >&

e_trapsignal removal

I propose to remove e_trapsignal from the compat framework Rationale: - It's currently unused. It was used for Darwin compat. - It's certainly broken and not used in part of the code where it could be used, generating a trap signal. - Maintaining debugging features in the compat framework is

Re: Potential new syscall

On 03.04.2018 16:57, Mouse wrote: >> =46rom the GDB protocol point of view, > ...what does gdb have to do with it? Did I miss something? > We need to track forks and its variations. Just a note that from the existing protocol point of view, we can handle this new syscall. signature.asc

Re: Potential new syscall

On 03.04.2018 01:29, Mouse wrote: > > Thoughts? (Not restricted to just the above details; thoughts on the > general idea would also be interesting to me.) > It might not be a satisfying answer... but go for fork(). I recommend this option - no kernel changes involved... unless someone wants

Debug Register (x86) trap - race

I've been investigating the race in ptrace(2) ATF tests: dbregs_* for x86 (i386 and amd64). Examples: NetBSD/amd64 http://releng.netbsd.org/b5reports/amd64/2018/2018.03.06.11.21.31/test.html#lib_libc_sys_t_ptrace_wait6_dbregs_dr3_trap_variable_readwrite_write_2bytes NetBSD/i386

Re: Port FreeBSD's updated Atheros WiFi Driver

On 19.03.2018 15:20, Aditya Upadhyay wrote: > On Sun, Mar 18, 2018 at 8:36 PM, Kamil Rytarowski <n...@gmx.com> wrote: >> On 18.03.2018 15:11, Aditya Upadhyay wrote: >>> Hi Kamil Rytarowski, >>> >>> Thanks for pointing out the easier one for

Re: Port FreeBSD's updated Atheros WiFi driver

On 19.03.2018 06:26, Harsh Khatore wrote: > Hi team,  > Welcome! > I know it is late to start with, but can you guide me on the above > mentioned project. I want to apply for GSoC with this project.  > > Also, do you have anyone else working on it, if so, please do let me > know, else it will

Re: Port FreeBSD's updated Atheros WiFi Driver

On 18.03.2018 15:11, Aditya Upadhyay wrote: > Hi Kamil Rytarowski, > > Thanks for pointing out the easier one for me. I really appreciate > your response. > > > On Sun, Mar 18, 2018 at 7:06 PM, Kamil Rytarowski <n...@gmx.com> wrote: >> On 18.03.2018 08:55, A

Re: Port FreeBSD's updated Atheros WiFi Driver

On 18.03.2018 08:55, Aditya Upadhyay wrote: > Hi tech-kern, > > > This is Aditya Upadhyay. I was a GSoC student last year at RTEMS > Organization. My Project was POSIX Compliance. This year, I am mentoring > for RTEMS itself. > > I am interested in this project and want to work, not as GSoC

Re: Regarding GSoC

On 15.03.2018 17:53, Siddharth Muralee wrote: > Hey, Welcome! >    I am a second-year undergraduate student at Amrita University, > Amritapuri, India. I would like to take up one of the ideas suggested in > your wiki namely, "Kernel Address SANitizer". I am a security enthusiast > and I am

Re: sysctl_doeproc() race

On 13.03.2018 13:26, Robert Elz wrote: > Sure - I was not suggesting that anything shouild be done to this code to > make it run faster - I had seen that "could just use ..." comment ages ago, > and (as I assume its original author did, even more ages previously) that > it just wasn't worth the

Re: sysctl_doeproc() race

On 13.03.2018 09:17, Robert Elz wrote: > Not a surprise there either - where it might make a difference is when > the number of processes is more in the thousands. I'm not sure how > 20-30 processes counts as a "regular running system" though, my > laptop has > 130 processes at the minute, and

Re: sysctl_doeproc() race

On 11.03.2018 19:20, Kamil Rytarowski wrote: > On 11.03.2018 18:23, Robert Elz wrote: >> Date:Sun, 11 Mar 2018 16:02:57 +0100 >> From:Kamil Rytarowski <n...@gmx.com> >> Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> >

Re: sysctl_doeproc() race

On 11.03.2018 18:23, Robert Elz wrote: > Date:Sun, 11 Mar 2018 16:02:57 +0100 > From: Kamil Rytarowski <n...@gmx.com> > Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> > > | We already use markers so I prefer to stick to this

Re: sysctl_doeproc() race

On 11.03.2018 17:25, Robert Elz wrote: > Date:Sun, 11 Mar 2018 16:02:57 +0100 > From: Kamil Rytarowski <n...@gmx.com> > Message-ID: <10b0efe2-35bb-d1e8-ed28-587f643bd...@gmx.com> > > | POSIX people told me that polling of a proc

Re: sysctl_doeproc() race

On 11.03.2018 13:00, Robert Elz wrote: > Date:Sun, 11 Mar 2018 11:06:33 +0100 > From:Martin Husemann > Message-ID: <20180311100633.ge23...@mail.duskware.de> > > | I don't get this part - how would we end up with the new process using > | the

Re: sysctl_doeproc() race

On 11.03.2018 13:12, Martin Husemann wrote: > On Sun, Mar 11, 2018 at 07:00:46PM +0700, Robert Elz wrote: >> That process can exit, its zombie be cleaned up, and then a new process >> created which happens to have the same pid as the previous one had > > Theoretically, but for all practical cases

Re: sysctl_doeproc() race

On 10.03.2018 23:49, Robert Elz wrote: > Date:Sat, 10 Mar 2018 21:47:31 +0100 > From: Kamil Rytarowski <n...@gmx.com> > Message-ID: <6cbea372-5520-8d76-72ac-68409f5a3...@gmx.com> > > | This does not fix the race, > > Some r

Re: sysctl_doeproc() race

On 10.03.2018 21:47, Kamil Rytarowski wrote: > On 10.03.2018 20:45, Christos Zoulas wrote: >> In article <ef31ecad-c6ba-bc06-aace-2b7a2ff33...@gmail.com>, >> Kamil Rytarowski <krytarow...@gmail.com> wrote: >>> I've been observing a race with the ptrace(2) AT

Re: sysctl_doeproc() race

On 10.03.2018 20:45, Christos Zoulas wrote: > In article <ef31ecad-c6ba-bc06-aace-2b7a2ff33...@gmail.com>, > Kamil Rytarowski <krytarow...@gmail.com> wrote: >> I've been observing a race with the ptrace(2) ATF tests. >> >> There is a function await_zombie() t

sysctl_doeproc() race

I've been observing a race with the ptrace(2) ATF tests. There is a function await_zombie() that checks whether a process (traced by a debugger) died and is now a zombie. The current code might return a single process twice, from the allproc list and later from zombproc. I detect that in both

Re: will-it-scale

On 03.03.2018 03:54, Kamil Rytarowski wrote: > With an inspiration from M.J. Guzik, I've ported will-it-scale to > NetBSD. It's available through pkgsrc-wip as wip/will-it-scale-git. > > I'm pasting here results that might be a starting point and inspiration. > A testing machin

will-it-scale

With an inspiration from M.J. Guzik, I've ported will-it-scale to NetBSD. It's available through pkgsrc-wip as wip/will-it-scale-git. I'm pasting here results that might be a starting point and inspiration. A testing machine with a larger number of cores (16+) would be useful for serious scaling

Re: Bunch of bugs reported by Ilja van Sprundel

On 30.01.2018 13:24, Kamil Rytarowski wrote: > On 30.01.2018 13:20, Martin Husemann wrote: >> On Tue, Jan 30, 2018 at 11:17:01AM +, m...@netbsd.org wrote: >>> So, >>> >>> - Didn't communicate that there's a breaking change in 7.1.1 to people >>>

Re: Bunch of bugs reported by Ilja van Sprundel

On 30.01.2018 13:20, Martin Husemann wrote: > On Tue, Jan 30, 2018 at 11:17:01AM +, m...@netbsd.org wrote: >> So, >> >> - Didn't communicate that there's a breaking change in 7.1.1 to people >> building packages > > This is tech-kern and for those pkgsrc agnostic: what "breaking > change in

Re: Bunch of bugs reported by Ilja van Sprundel

On 29.01.2018 22:27, Joerg Sonnenberger wrote: > On Mon, Jan 29, 2018 at 10:16:05PM +0100, Kamil Rytarowski wrote: >> On 29.01.2018 22:01, Joerg Sonnenberger wrote: >>> On Mon, Jan 29, 2018 at 09:58:16PM +0100, Kamil Rytarowski wrote: >>>> Another point is to set a r

Re: Bunch of bugs reported by Ilja van Sprundel

On 29.01.2018 22:01, Joerg Sonnenberger wrote: > On Mon, Jan 29, 2018 at 09:58:16PM +0100, Kamil Rytarowski wrote: >> Another point is to set a rule that ABI is stable between patch versions >> and binary packages (prebuilt software) still works as-is. I'm observing >>

Re: Bunch of bugs reported by Ilja van Sprundel

On 29.01.2018 20:01, m...@netbsd.org wrote: > I think we should have a discussion to change the way netbsd releases > and security advisories are done. they seem to be suitable for a large > company, and netbsd is doesn't keep up with it. > Personally, I would find it reasonable to abandon minor

Re: amd64: svs

On 07.01.2018 18:13, m...@netbsd.org wrote: > It will be good to document somewhere why SVS exists. it's obvious now, > but it might not be in a decade. > > Thanks for working on this! > I expect that we are now required to pullup it to stable branches. Thanks for the fixes! signature.asc

Re: meltdown

On 04.01.2018 21:49, m...@netbsd.org wrote: > Also, I understand that to exploit this, one has to attempt to access > kernel memory a lot, and SEGV at least once per bit. > > I wonder if we can count the number of SEGVs and if we get a few, turn > on the workaround? that would at least spare us

Re: Proposal to obsolete SYS_pipe

On 25.12.2017 17:18, Valery Ushakov wrote: > On Mon, Dec 25, 2017 at 16:37:43 +0100, Kamil Rytarowski wrote: > >> On 24.12.2017 22:25, Kamil Rytarowski wrote: >> >>> http://netbsd.org/~kamil/patch-00039-obsolete-SYS_pipe.txt >> >> I've extrac

Re: Proposal to obsolete SYS_pipe

On 25.12.2017 17:43, Christos Zoulas wrote: > On Dec 25, 4:42pm, n...@gmx.com (Kamil Rytarowski) wrote: > -- Subject: Re: Proposal to obsolete SYS_pipe > > | I've extracted two changes from the original mail: > | > | https://mail-index.netbsd.org/tech-kern/2017/12/25/msg02

Re: Proposal to obsolete SYS_pipe

On 25.12.2017 16:37, Kamil Rytarowski wrote: > On 24.12.2017 22:25, Kamil Rytarowski wrote: >> I propose to deprecate SYS_pipe. >> >> It is a special syscall that returns two integers from one function >> call. Fanciness is not compatible with regular C syntax and it

Re: Proposal to obsolete SYS_pipe

On 24.12.2017 22:25, Kamil Rytarowski wrote: > I propose to deprecate SYS_pipe. > > It is a special syscall that returns two integers from one function > call. Fanciness is not compatible with regular C syntax and it demands > per-cpu assembly wrappers and rump-kernel workarounds.

Re: Proposal to obsolete SYS_pipe

On 25.12.2017 03:42, John Nemeth wrote: > On Dec 24, 9:37pm, Mouse wrote: > } > } > http://netbsd.org/~kamil/patch-00039-obsolete-SYS_pipe.txt > } > } I see no pipe2(2), nor change from pipe(2) to pipe(3) (with an xref to > } pipe2(2)), both of which, it seems to me, should be part of this. > >

Proposal to obsolete SYS_pipe

I propose to deprecate SYS_pipe. It is a special syscall that returns two integers from one function call. Fanciness is not compatible with regular C syntax and it demands per-cpu assembly wrappers and rump-kernel workarounds. It's not easily usable with syscall(2). OpenBSD and FreeBSD already

Re: Removing an entry from struct emul

On 21.12.2017 10:43, Martin Husemann wrote: > On Thu, Dec 21, 2017 at 07:16:09AM +, co...@sdf.org wrote: >> Hi, >> >> COMPAT_IRIX needed e_fault, an alternative implementation of uvm_fault. >> But it's been removed. can I remove e_fault from the struct, or would >> this break compat too hard?

Re: [Call for Testing] Syzkaller (kernel fuzzing)

Please don't burden upstream for every single issue (for now assume literal meaning: "for any issue"). This worked for a while, as Dmitry had spare time for syzkaller for !Linux, but this time is over. You have asked others for tests, so take the responsibility now to answer feedback reports. I'm

Re: Removal of 'wd* at umass?' driver?

On 08.10.2017 21:12, Jaromír Doleček wrote: > Opinions? Can we just disable the driver now and reevaluate after 9.0? signature.asc Description: OpenPGP digital signature

Re: amd64: kernel aslr support

On 05.10.2017 12:56, Maxime Villard wrote: > > The advantage of having a separate prekern is that you can update the > kernel > without touching the prekern, or the other way around. Is live-kernel update more viable with this approach? signature.asc Description: OpenPGP digital signature

Re: amd64: kernel aslr support

On 04.10.2017 21:00, Maxime Villard wrote: > Here is a Kernel ASLR implementation for NetBSD-amd64. It is light, > functional, > user-friendly, and does not break any feature of the system. > Instructions on > how to install and use it can be found here [1]. I'm looking forward to see it aboard

Re: how to tell if a process is 64-bit

On 10.09.2017 16:31, Thor Lancelot Simon wrote: > On Fri, Sep 08, 2017 at 07:38:24AM -0400, Mouse wrote: >>> In a cross-platform process utility tool the question came up how to >>> decide if a process is 64-bit. >> >> First, I have to ask: what does it mean to say that a particular >> process is

Re: fork1 use-after-free of the child process

On 08.09.2017 04:32, Mateusz Guzik wrote: > The fork1 routine can wait for the child to exit (if vforked) and/or > return the pointer to the child. > > Neither case guarantees the safety of said operation. The key is that > the parent can be ignoring SIGCHLD, which results in autoreaping the >

Re: /proc/#/ctl removal

On 27.08.2017 16:07, Johnny Billquist wrote: > On 2017-08-27 14:09, D'Arcy Cain wrote: >> On 08/27/2017 03:59 AM, Christos Zoulas wrote: >>> LGTM, perhaps leave a comment /* old P_FSTRACE0x0001 */ >>> instead of completely removing the constants for now as a reminder. >> >> Isn't that sort

Re: /proc/#/ctl removal

On 27.08.2017 09:59, Christos Zoulas wrote: > On Aug 26, 4:04pm, n...@gmx.com (Kamil Rytarowski) wrote: > -- Subject: Re: /proc/#/ctl removal > > | I will do it. > | > | Draft patch: http://netbsd.org/~kamil/patch-00036-procfs_ctl.txt > | > | I plan to commit it on Mo

Re: /proc/#/ctl removal

On 21.08.2017 12:13, Christos Zoulas wrote: > In article <da98e240-5dfb-4c49-ebb0-55c43d7b5...@gmx.com>, > Kamil Rytarowski <n...@gmx.com> wrote: >> -=-=-=-=-=- >> -=-=-=-=-=- >> >> I plan to remove the filesystem process tracing capability through >&

Re: amd64: smap support

On 23.08.2017 16:24, Maxime Villard wrote: > Here is a patch that implements SMAP on amd64. SMAP is basically a feature > that prevents the kernel from reading a userland page, and it's a great > exploit mitigation feature. > > To function, it relies on two bits: CR4_SMAP in %cr4 and PSL_AC in

/proc/#/ctl removal

I plan to remove the filesystem process tracing capability through /proc/#/ctl. This is a legacy interface from 4.4BSD, and it was introduced to overcome shortcomings of ptrace(2) at that time, which are no longer relevant (performance). Today /proc/#/ctl offers a narrow subset of ptrace(2)

Re: Proposal: Disable autoload of compat_xyz modules

On 02.08.2017 20:02, Taylor R Campbell wrote: >> Date: Wed, 2 Aug 2017 16:11:16 + >> From: m...@netbsd.org >> >> I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source >> browser that works as is, without even realizing it relies on >> COMPAT_LINUX to work. > > % cd

Re: Proposal: Disable autoload of compat_xyz modules

On 01.08.2017 00:48, Taylor R Campbell wrote: >> Date: Tue, 1 Aug 2017 00:45:24 +0200 >> From: Kamil Rytarowski <n...@gmx.com> >> >> I use both linux and linux32 ones. > > Can you argue that these and the others you listed should be > automatically enabled

Re: Proposal: Disable autoload of compat_xyz modules

On 31.07.2017 23:39, Taylor R Campbell wrote: > Many of our binary compatibility modules are notoriously ridden with > bugs. We currently have no way to automatically test them. Some of > them are maintained; some of them are not. The value of having NetBSD > automatically try to execute a SCO

Re: kmem API to allocate arrays

On 30.07.2017 16:51, Taylor R Campbell wrote: >> Date: Sun, 30 Jul 2017 16:24:07 +0200 >> From: Kamil Rytarowski <n...@gmx.com> >> >> I would allow size to be 0, like with the original reallocarr(3). It >> might be less pretty, but more compatible with the o

Re: kmem API to allocate arrays

On 30.07.2017 15:45, Taylor R Campbell wrote: >> Date: Sun, 30 Jul 2017 10:22:11 +0200 >> From: Kamil Rytarowski <n...@gmx.com> >> >> I think we should go for kmem_reallocarr(). It has been designed for >> overflows like realocarray(3) with an option to be capa

Re: rwlock

On 28.06.2017 19:05, co...@sdf.org wrote: > Hi, > does rwlock RW_WRITER prevent new readers? > > thanks > I recommend Solaris Internals on this topic. I'm not sure off-hand the mechanism in NetBSD but it should be close to it. signature.asc Description: OpenPGP digital signature

Re: Questions of lock usage in NetBSD kernel code

On 25.06.2017 20:34, Taylor R Campbell wrote: > Sleeping with a spin lock held is absolutely prohibited and does not > work. > An example of this abuse is described here: https://mail-index.netbsd.org/current-users/2014/07/19/msg025295.html Jia-Ju, can you detect bugs like this one?

Re: kernel aslr: someone interested?

On 17.06.2017 12:25, Maxime Villard wrote: > Le 23/03/2017 à 18:30, Maxime Villard a écrit : >> I have some plans to implement kernel aslr on amd64. Actually, a few >> months >> ago I wrote set of patches for the bootloader and the kernel, and also a >> complete kernel relocator. As far as I can

Re: panic(9) with insufficient RAM or disk space

On 09.06.2017 13:08, Kamil Rytarowski wrote: > On 09.06.2017 13:07, Martin Husemann wrote: >> One of the panics sounds like PR 52110. >> >> Martin >> > > This looks similar, I have another kernel core dump with exactly the > same backtrace. I observed it f

panic(9) with insufficient RAM od disk space

I observe panics on busy machines with shortage of RAM or/and disk-space. Disk space (?) panic: uid 1000, pid 1975, command irc-20151120, on /: file system full panic: kernel diagnostic assertiWonA "(so2->so_oRpNtiIoNGns: PSLO _NAOCTC ELPTOCWOERNEND) =O=N 0T R|A|P sEoX2I-T >6s o0_ loWAcRkN

Re: Replacement for cpu_exit(9) and cpu_swapout(9)

On 30.05.2017 09:20, Abhinav Upadhyay wrote: > On Tue, May 30, 2017 at 12:32 PM, Martin Husemann wrote: >> On Tue, May 30, 2017 at 12:23:36PM +0530, Abhinav Upadhyay wrote: >>> I have tried to look through the CVS logs and searched on nxr.n.o but >>> can't find if there was

Re: Adding ruminit(4)

On 24.05.2017 04:10, Pierre Pronchery wrote: > Hi tech-kernel@, > > as some of you may have noticed, I just added a USB ID to the rum(4) > driver [1]. It is for a device called "Windy 31" from Synet Electronics, > product name MW-P54SS [2] (yes it's old). > > As it happens (and as

Re: Introducing localcount(9)

On 12.05.2017 00:09, Paul Goyette wrote: > On Thu, 11 May 2017, Kamil Rytarowski wrote: > >> On 11.05.2017 15:17, Taylor R Campbell wrote: >>>> Date: Thu, 11 May 2017 20:35:19 +0800 (+08) >>>> From: Paul Goyette <p...@whooppee.com> >>&

Re: Introducing localcount(9)

On 11.05.2017 15:17, Taylor R Campbell wrote: >> Date: Thu, 11 May 2017 20:35:19 +0800 (+08) >> From: Paul Goyette >> >> On Thu, 11 May 2017, Kengo NAKAHARA wrote: >> >>>(1) Why splsoftserial() is required instead of kpreempt_disable()? >>>localcount_drain() uses

Re: New diagnostic routine - mutex_ownable()

On 01.05.2017 00:12, co...@sdf.org wrote: > On Sun, Apr 30, 2017 at 08:49:04AM +0800, Paul Goyette wrote: >> While working on getting the localcount(9) stuff whipped into shape, I ran >> across a situation where it is desirable to ensure that the current >> process/lwp does not already own a

Re: Keep local symbols of rump libraries

On 10.04.2017 12:22, Ryota Ozaki wrote: > Hi, > > I'm using ATF tests running rump kernels (rump_server) > for development and debugging. When a rump kernel gets > panic, it dumps a core file from which we can obtain > a backtrace by using gdb. > > Unfortunately local symbols (i.e., static

<    1   2   3   4   >