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
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
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
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
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
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
