Re: secmodel_securelevel(9) and machdep.svs.enabled
Alexander Nasonov wrote: > Thinking a bit more about this, I don't think my patch will prevent > data leakage from the kernel because /dev/mem and /dev/kmem are > readable at all securelevels. There is an important distrinction, though. Code in sys/dev/mm.c can be changed to scramble sensitive pages (e.g. cgd(4) keys) while meltdown is a wild beast and it's nearly impossible to control. -- Alex
Re: NetBSD 8.0 RC1 issue
On Wed, Apr 25, 2018 at 10:32:34AM -0700, Phil Nelson wrote: > I'm a little late in trying 8.0 ... but I just tried to install 8.0 RC1 on a > Dell Optiplex 745. During boot it blanks the display and nothing can > be seen on the display from that point on. IIRC, I had similar issues with going from 6.x to 7.x; in my /etc/boot.cfg I had to change the entries along the lines of menu=Boot normally:rndseed /var/db/entropy-file;vesa 1024x768x8;boot netbsd menu=Drop to boot prompt:vesa 1024x768x8;prompt Alternately, "vesa on" supposedly works, but I never got that to work consistently.
Re: secmodel_securelevel(9) and machdep.svs.enabled
Maxime Villard wrote: > Yes, it's fine. I've never taken care of securelevel, but your change > can't be incorrect. Perhaps I would use just KAUTH_MACHDEP_SVS instead > of KAUTH_MACHDEP_SVS_DISABLE, in case another operation gets added in > the future, but that doesn't matter. I don't think securelevel should care about details of SVS. If you want to introduce levels of SVS, KAUTH_MACHDEP_SVS_DISABLE can still be used to prevent lowering (instead of disabling SVS completely). Perhaps the name can be changed to KAUTH_MACHDEP_SVS_DEGRADE or something similar but it's not that important. Thinking a bit more about this, I don't think my patch will prevent data leakage from the kernel because /dev/mem and /dev/kmem are readable at all securelevels. It can only prevent leakage in some situations. For example, when root is compromised inside chroot and chroot directory is on a file system mounted with nodev. -- Alex
re: secmodel_securelevel(9) and machdep.svs.enabled
Maxime Villard writes: > Le 25/04/2018 à 19:47, Alexander Nasonov a écrit : > > Alexander Nasonov wrote: > >> Alexander Nasonov wrote: > >>> When securelevel is set, should be lock 1->0 change for > >>> machdep.svs.enabled (and possibly for other sysctls related > >>> to recent security mitigations)? > >> > >> Can I commit the attached patch? (doc update will follow) > > > > If I don't hear any objections, I will commit the patch soon and > > I will request a pullup to netbsd-8. it's the right idea to me. > > Alex > > Yes, it's fine. I've never taken care of securelevel, but your change > can't be incorrect. Perhaps I would use just KAUTH_MACHDEP_SVS instead > of KAUTH_MACHDEP_SVS_DISABLE, in case another operation gets added in > the future, but that doesn't matter. i considered this idea -- plain SVS would have to not include ENABLE, which doesn't seem right. perhaps another generic name that implies !enable would work. .mrg.
Re: secmodel_securelevel(9) and machdep.svs.enabled
Le 25/04/2018 à 19:47, Alexander Nasonov a écrit : Alexander Nasonov wrote: Alexander Nasonov wrote: When securelevel is set, should be lock 1->0 change for machdep.svs.enabled (and possibly for other sysctls related to recent security mitigations)? Can I commit the attached patch? (doc update will follow) If I don't hear any objections, I will commit the patch soon and I will request a pullup to netbsd-8. Alex Yes, it's fine. I've never taken care of securelevel, but your change can't be incorrect. Perhaps I would use just KAUTH_MACHDEP_SVS instead of KAUTH_MACHDEP_SVS_DISABLE, in case another operation gets added in the future, but that doesn't matter. Maxime
NetBSD 8.0 RC1 issue
I'm a little late in trying 8.0 ... but I just tried to install 8.0 RC1 on a Dell Optiplex 745. During boot it blanks the display and nothing can be seen on the display from that point on. The vga/display parts of the dmesg from 6.1.5 says: vga1 at pci0 dev 2 function 0: vendor 0x8086 product 0x2992 (rev. 0x02) vga1: WARNING: ignoring 64-bit BAR @ 0x18 wsdisplay0 at vga1 kbdmux 1: console (80x25, vt100 emulation) wsmux1: connecting to wsdisplay0 i915drm0 at vga1: Intel i965Q i915drm0: AGP at 0xc000 256MB i915drm0: Initialized i915 1.6.0 20080730 vendor 0x8086 product 0x2993 (miscellaneous display, revision 0x02) at pci0 dev 2 function 1 not configured The monitor is 1920x1200 dell. I was expecting it to switch from large characters to small characters at that point like it does on other recent hardware using similar sized monitors. --Phil
