Re: nvidia.ko with Grsecurity & PaX kernel

Hello!


Thank you Alex and Hinnerk for your answers.

I understand and fully agree that CONFIG_PAX_MPROTECT is very important
for security. However, I had to "-m" mark *a lot* of applications:

Xorg, i3, i3bar, i3-nagbar and even "simple" GTK applications like
claws-mail that has nothing with GLX (or maybe GTK has).

I'm aware of the latest-stable ebuild issue with the pax-const.patch,
but do you think it would make a difference from MPROTECT marking
point of view? Is 319.49 behaving "more nicely" then 325.15?

Thank you,
Balint

On Thu, 12 Sep 2013 00:24:59 +0300
Alex Efros <[email protected]> wrote:

> Hi!
> 
> On Wed, Sep 11, 2013 at 11:44:07PM +0300, Balint Szente wrote:
> > So I disabled CONFIG_PAX_MPROTECT for the moment.
> 
> It's much better to `paxctl-ng -m /usr/bin/Xorg` instead. And
> probably few other applications (mplayer, glxgears, etc.).
> 
> 
> Also, you can install latest stable nvidia-drivers by simple removing
> this line from ebuild (bug already reported):
> 
>     epatch "${FILESDIR}"/nvidia-drivers-pax-const.patch
> 
> 
> Main issue with nvidia-drivers on hardened is what sometimes some race
> condition happens and system just freezes. This may happens when
> starting mplayer with hardware acceleration:
>     mplayer -vf-clr -vo vdpau -vc ffh264vdpau,ffmpeg12vdpau, …
> or just in the middle of viewing video using flash in browser.
> 
> Not sure about flash, but when this happens with mplayer I've tried to
> analyse what's going on: system is working, but incredible slow, it
> took about 10 minutes to switch to another virtual desktop, run top,
> found mplayer process using 100% CPU, try to kill it (don't remember
> is it was successful or not), but it won't fix anything - system
> still was too slow. In all cases I've to press RESET because trying
> to do normal shutdown procedure may took hours.
>