modprobe: ERROR: could not insert 'i915': No such device.

[jlambrecht]

Please have a look, i'm attempting to compile grsec to work for a desktop system.

Despite having disabled CONFIG_GRKERNSEC_MEM ( restrict /dev/kmem, /dev/mem .... ) the i915 module is still not loading.

modprobe i915
insmod /lib/modules/3.2.64-grsec/kernel/drivers/gpu/drm/i915/i915.ko
modprobe: ERROR: could not insert 'i915': No such device

I'm a bit clueless on how to diagnose this. RBAC is disabled.

sysctl -a | grep pax
kernel.pax.softmode = 1

sysctl -a | grep grsec
kernel.grsecurity.linking_restrictions = 1
kernel.grsecurity.deter_bruteforce = 1
kernel.grsecurity.fifo_restrictions = 1
kernel.grsecurity.ptrace_readexec = 1
kernel.grsecurity.consistent_setxid = 1
kernel.grsecurity.ip_blackhole = 1
kernel.grsecurity.lastack_retries = 4
kernel.grsecurity.rwxmap_logging = 1
kernel.grsecurity.signal_logging = 1
kernel.grsecurity.forkfail_logging = 1
kernel.grsecurity.timechange_logging = 1
kernel.grsecurity.chroot_deny_shmat = 1
kernel.grsecurity.chroot_deny_unix = 1
kernel.grsecurity.chroot_deny_mount = 1
kernel.grsecurity.chroot_deny_fchdir = 1
kernel.grsecurity.chroot_deny_chroot = 1
kernel.grsecurity.chroot_deny_pivot = 1
kernel.grsecurity.chroot_enforce_chdir = 1
kernel.grsecurity.chroot_deny_chmod = 1
kernel.grsecurity.chroot_deny_mknod = 1
kernel.grsecurity.chroot_restrict_nice = 1
kernel.grsecurity.chroot_caps = 1
kernel.grsecurity.chroot_deny_sysctl = 1
kernel.grsecurity.tpe = 1
kernel.grsecurity.tpe_gid = 21005
kernel.grsecurity.tpe_invert = 1
kernel.grsecurity.tpe_restrict_all = 1
kernel.grsecurity.socket_all = 1
kernel.grsecurity.socket_all_gid = 21004
kernel.grsecurity.socket_client = 1
kernel.grsecurity.socket_client_gid = 21003
kernel.grsecurity.socket_server = 1
kernel.grsecurity.socket_server_gid = 21002
kernel.grsecurity.audit_mount = 1
kernel.grsecurity.dmesg = 1
kernel.grsecurity.chroot_findtask = 1
kernel.grsecurity.resource_logging = 1
kernel.grsecurity.harden_ptrace = 1
kernel.grsecurity.harden_ipc = 1
kernel.grsecurity.grsec_lock = 0
kernel.grsecurity.deny_new_usb = 0
kernel.osrelease = 3.2.64-grsec

[spender]

Have you tried a vanilla 3.2.64 kernel with the same config? The problem is likely unrelated to grsecurity. See (for instance): http://ubuntuforums.org/showthread.php?t=2235670

-Brad

[jlambrecht]

Hi, thanks for your response.

I did not mention this is with a vanilla source from kernel.org and the matching patch from grsecurity.net

I'm afraid this might be a regression ?

[jlambrecht]

A good night sleep can work for me ...

just found viewtopic.php?t=2489&p=10284 titled "CONFIG_PAX_MEMORY_UDEREF breaks i915 driver"

PAX_MEMORY_UDEREF

By saying Y here the kernel will be prevented from dereferencing
userland pointers in contexts where the kernel expects only kernel
pointers. This is both a useful runtime debugging feature and a
security measure that prevents exploiting a class of kernel bugs.

The tradeoff is that some virtualization solutions may experience
a huge slowdown and therefore you should not enable this feature
for kernels meant to run in such environments. Whether a given VM
solution is affected or not is best determined by simply trying it
out, the performance impact will be obvious right on boot as this
mechanism engages from very early on. A good rule of thumb is that
VMs running on CPUs without hardware virtualization support (i.e.,
the majority of IA-32 CPUs) will likely experience the slowdown.

On X86_64 the kernel will make use of PCID support when available
(Intel's Westmere, Sandy Bridge, etc) for better security (default)
or performance impact. Pass pax_weakuderef on the kernel command
line to choose the latter.

---- By any standard my machine is much slower than running a non-grsec kernel. Though this kernel is running on bare-metal, at least AFAIK

** update **
[ ] Prevent invalid userland pointer dereference
** yep, pretty sure i have that one selected **

Could it be i have to build the i915 module from an external source repository ?

[spender]

The problem you're having and the one from that old thread aren't the same -- the issue in that post has been resolved for years now. You haven't demonstrated yet that this is a grsecurity problem, which is why I asked to have you confirm you don't have the problem with a vanilla kernel only of the same version and same config, without grsecurity patched in.

-Brad

[jlambrecht]

My Apologies.

I do not have any issue with the kernels supplied with Ubuntu. Once i get back to this machine i'll provide more accurate information.

I hope not to have made a fool of myself too much already. I saw the noticeable performance degradation and concluded this could be a related issue.

[jlambrecht]

I just booted the machine without a grsec patched kernel. Let me know what type of information i can provide.

#lsmod | grep i915
i915 783961 5
video 19476 1 i915
drm_kms_helper 55071 1 i915
drm 303102 4 i915,drm_kms_helper
i2c_algo_bit 13413 1 i915

# grep agp syslog
( booted into grsec kernel )
Nov 10 18:58:00 brix kernel: [ 11.127521] Linux agpgart interface v0.103
Nov 10 18:58:00 brix kernel: [ 11.280333] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
( booted into default ubuntu kernel )
Nov 10 19:00:04 brix kernel: [ 0.588881] Linux agpgart interface v0.103

# grep i915 syslog
( booted into grsec kernel )
Nov 10 18:58:00 brix kernel: [ 11.280333] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
( booted into default ubuntu kernel )
Nov 10 19:00:04 brix kernel: [ 2.521907] i915 0000:00:02.0: found PCI INT A -> IRQ 11
Nov 10 19:00:04 brix kernel: [ 2.521912] i915 0000:00:02.0: sharing IRQ 11 with 0000:00:03.0
Nov 10 19:00:04 brix kernel: [ 2.521914] i915 0000:00:02.0: sharing IRQ 11 with 0000:00:14.0
Nov 10 19:00:04 brix kernel: [ 2.521916] i915 0000:00:02.0: sharing IRQ 11 with 0000:00:16.0
Nov 10 19:00:04 brix kernel: [ 2.521920] i915 0000:00:02.0: sharing IRQ 11 with 0000:00:1c.0
Nov 10 19:00:04 brix kernel: [ 3.330918] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
Nov 10 19:00:04 brix kernel: [ 3.330919] i915 0000:00:02.0: registered panic notifier
Nov 10 19:00:05 brix kernel: [ 3.381569] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Nov 10 19:00:05 brix kernel: [ 3.386892] HDA driver get symbol successfully from i915 module

[jlambrecht]

For the sake of completeness

I've recompiled without CONFIG_PAX_MEMORY_UDEREF enabled, but i've also installed the latest and greatest driver from intel

https://01.org/linuxgraphics/
using https://download.01.org/gfx/ubuntu/14.0 ... tel1_amd64.

Right now graphics performance using a grsec patched kernel is much improved though not on par or near to Ubuntu stock kernel performance.

Epiphany Browser for example works fine now while it did not do so before. The i915 is still not loading with "modprobe: ERROR: could not insert 'i915': No such device"

[spender]

I need to see unames from both machines.

-Brad

[jlambrecht]

Just one machine really. I did not speak of multiple.

Linux brix 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Linux brix 3.2.64-grsec #17 SMP Mon Nov 10 21:08:33 CET 2014 x86_64

And to avoid any mistakes on my account, this is for an i7 4500u with integrated Intel HD 4400 GPU

[PaX Team]

so we're looking at four problems here, if i'm not mistaken. one is a performance issue (with and without UDEREF) and another with the i915 driver not loading (again with and without UDEREF). is that correct?

1. performance with UDEREF: this is a known property of UDEREF, and in my experience ivb and newer processors have a worse impact for some reason.
2. performance without UDEREF: we'd need to know what else you enabled in your config to determine whether it's something expected or a regression.
3. i915 not loading (regardless of UDEREF): having your config would be a starting point in debugging this. also what happens if you compile the i915 driver into the kernel, does it work then? can you also test a 3.17.x kernel? also in the future please post the full dmesg for both the working and failing cases.

[jlambrecht]

That must be a correct distinction to make.


Performance

1. With UDEREF performance is almost unworkable,
2. The kernel without UDEREF enabled is showing acceptable graphics performance, i915 module still does not load.

i915 module not loading

1. Attached is my .config
2. I'll try out a more recent kernel, though i prefer longterm kernels
3. I'll test the compile of this module into the kernel

[PaX Team]

where did you attach the config?

[jlambrecht]

I did, honest

http://hastebin.com/gabudajebi.vbs

[jlambrecht]

Any update on this yet ? I've not had the chance to continue on my own todo's.