Re: wscons/wsmux question

[Paul Goyette]

On Sun, 18 Jun 2017, Thor Lancelot Simon wrote:


On Sun, Jun 18, 2017 at 12:14:41PM +0800, Paul Goyette wrote:


Would anyone object if I were to remove all of the "#if NWSMUX > 0"
conditionals, and simply require the wsmux code to be included (via
files.wscons) whenever any child dev (wsdisplay, wskbd, wsmouse, or wsbell)
is configured?


How much (more) bloat?


I expect zero increase in "bloat", unless someone can identify a useful 
situation where child devices can exist without being connected to a 
mux.


The wsmux.c (and wsbellmux.c) code sizes for amd64:

wsbellmux.o   wsmux.o
.text 8eddf
.data  0 50
.rodata*  14255
   
  a2   1084
   = 162.= 4228.

grand total = 4390.

So, less than 4.5KB


Note that this would NOT be an increase over current sizes.  As far as I 
can tell, all kernel configs that include any of the "child" devices 
already include the wsmux pseudo-device explicitly.




+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++

Re: wscons/wsmux question

[Thor Lancelot Simon]

On Sun, Jun 18, 2017 at 12:14:41PM +0800, Paul Goyette wrote:
> 
> Would anyone object if I were to remove all of the "#if NWSMUX > 0"
> conditionals, and simply require the wsmux code to be included (via
> files.wscons) whenever any child dev (wsdisplay, wskbd, wsmouse, or wsbell)
> is configured?

How much (more) bloat?

Thor

Re: wscons/wsmux question

[Paul Goyette]

On Thu, 15 Jun 2017, Paul Goyette wrote:


While recently working with Nat to get the wsbell(4) device working,
I've noticed that both wsdisplay(4) and wsmouse(4) (as well as the new
wsbell(4)) have lots of code conditionally compiled based on "NWSMUX

0" (which is defined in wsmux.h resulting from the needs-flag in

wscons/files.wscons).

Does it really make sense to have a kernel with either wsdisplay(4) or
wsmouse(4) but _without_ any wsmux(4) devices?  It would really make
things a lot cleaner if we were able to remove some of this conditional
compilation.


I'm a bit surprised that there hasn't yet been any response on this 
subject.  :)  Usually when I propose something, it prompts some fairly 
lively discussion.



Would anyone object if I were to remove all of the "#if NWSMUX > 0" 
conditionals, and simply require the wsmux code to be included (via 
files.wscons) whenever any child dev (wsdisplay, wskbd, wsmouse, or 
wsbell) is configured?




+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++

re: ARM pmap

[matthew green]

Michael writes:
> Hello,
> 
> On Fri, 16 Jun 2017 14:30:18 +1000
> matthew green  wrote:
> 
> > > Or just tar xpzf ... - ours at least unlinks files before writing them,
> > > install(1) instead of cp(1) for single files.  
> > 
> > FWIW, it's temp file + rename, not unlink.
> 
> Hmm, the man page says:
>  --unlink  Ignored, only accepted for compatibility with other tar
>implementations.  tar always unlinks files before creating
>them.
> 
> ... which would make no sense if it was about creating new files.

this is actually false :-)  see eg pax/file_subs.c:

234 /*
235  * Finally, now the temp file is fully instantiated rename it to
236  * the desired file name.
237  */
238 if (rename(tmp_name, arcn->name) < 0) {
239 syswarn(0, errno, "Cannot rename %s to %s",
240 tmp_name, arcn->name);
241 (void)unlink(tmp_name);
242 }

the idea being that you (a) get a new inode and don't overwrite
running text and (b) atomically switch to the new file so there
is no period that lookup will return ENOENT.

wanna fix the man for us? :)


.mrg.

kpreempt_disable and lwp migration

[coypu]

Hello tech-kern,

It seems that kpreempt_disable() does not prevent a lwp from
migrating. The assumption that it does is in some places in
NetBSD.

This came up as I am using a non-MPSAFE filesystem (LFS), and had
panics in x86 pmap's pmap_extract, which states it makes this assumption
in a comment:

kpreempt_disable();
ci = l->l_cpu;
if (__predict_true(!ci->ci_want_pmapload && ci->ci_pmap == pmap) ||
pmap == pmap_kernel()) {
/*
 * no need to lock, because it's pmap_kernel() or our
 * own pmap and is active.  if a user pmap, the caller
 * will hold the vm_map write/read locked and so prevent
 * entries from disappearing while we are here.  ptps
 * can disappear via pmap_remove() and pmap_protect(),
 * but they are called with the vm_map write locked.

My personal opinion is that allowing lwp migration with preemption
explicitly disabled is a headache for reasoning about races and
that we should consider disallowing this.

Most notably, using curcpu() is a headache.

I'm not sure how this affects other archs which don't allow kernel
preemption.

I think the following diff will do it, thoughts?

Thanks.

Index: kern_cpu.c
===
RCS file: /cvsroot/src/sys/kern/kern_cpu.c,v
retrieving revision 1.71
diff -u -r1.71 kern_cpu.c
--- kern_cpu.c  29 Aug 2015 12:24:00 -  1.71
+++ kern_cpu.c  17 Jun 2017 18:15:18 -
@@ -374,7 +374,8 @@
struct cpu_info *mci;
 
lwp_lock(l);
-   if (l->l_cpu != ci || (l->l_pflag & (LP_BOUND | LP_INTR))) {
+   if (l->l_cpu != ci || (l->l_pflag & (LP_BOUND | LP_INTR)) ||
+   l->l_nopreempt) {
lwp_unlock(l);
continue;
}

Re: ARM pmap

[Michael]

Hello,

On Fri, 16 Jun 2017 14:30:18 +1000
matthew green  wrote:

> > Or just tar xpzf ... - ours at least unlinks files before writing them,
> > install(1) instead of cp(1) for single files.  
> 
> FWIW, it's temp file + rename, not unlink.

Hmm, the man page says:
 --unlink  Ignored, only accepted for compatibility with other tar
   implementations.  tar always unlinks files before creating
   them.

... which would make no sense if it was about creating new files.

have fun
Michael

Re: kernel aslr: someone interested?

[Kamil Rytarowski]

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 test, everything works
>> correctly
>> and reliably; the whole implementation can relocate and jump into a
>> PIE binary
>> in kernel mode with a proper page tree.
>>
>> But the thing is, I don't quite see how to have the kernel itself
>> compiled as
>> PIE. My attempts so far have been unfruitful, so I thought I could ask
>> here.
>> Ideally, we would have a kernel that has the same binary layout as our
>> kernel
>> modules.
>>
>> Is there someone interested in working on that? This is a toolchain
>> work, but
>> I don't know that stuff.
> 
> This still stands; beyond aslr, there are several new features that we
> could implement - such a live kernel patching -, and they imply being able
> to build a PIE kernel in the first place.
> 
> Perhaps add the "Toolchain: Build kernel as PIE" idea in the projects list?

I noted that Kernel ASLR is treated as industry standard now. Fuchsia
(Magenta) implemented it from get go and enabled when possible.

I have dreams to get sanitizers (asan, msan, ubsan, ...) into the kernel
at some point. It should reduce significantly the time required to shake
out bugs from the kernel. However first I need to get these debugging
facilities to the usable point in userland.



signature.asc
Description: OpenPGP digital signature

Re: kernel aslr: someone interested?

[Maxime Villard]

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 test, everything works correctly
and reliably; the whole implementation can relocate and jump into a PIE binary
in kernel mode with a proper page tree.

But the thing is, I don't quite see how to have the kernel itself compiled as
PIE. My attempts so far have been unfruitful, so I thought I could ask here.
Ideally, we would have a kernel that has the same binary layout as our kernel
modules.

Is there someone interested in working on that? This is a toolchain work, but
I don't know that stuff.


This still stands; beyond aslr, there are several new features that we
could implement - such a live kernel patching -, and they imply being able
to build a PIE kernel in the first place.

Perhaps add the "Toolchain: Build kernel as PIE" idea in the projects list?