On 05/17/2012 12:16 AM, RB wrote:

On Wed, May 16, 2012 at 5:40 PM, "Tóth Attila"<atoth@atoth.sote.hu> wrote:

What's the difference between your kernel konfig and Liberté Linux
2012.1's kernel konfig? Because you told it worked for you.


Quite a lot, not the least of which theirs is a 32-bit kernel and
mine's 64-bit. The 'diff -u' between them is 5k lines long, and
instead of going through that line-by-line my intent is to take the
quickest path first: start with Liberté's config on 3.3.6 and start
adding my own settings until it breaks. Plus, this "old" machine is
slow, it takes at least 30 minutes to compile a kernel, and given a
day job it's going to take a little while to test.


Please open a bug, attach both config files. It would be useful if you
also identify on which options it breaks. Liberte, last I looked, has
quite a few hardening features off. Pay attention to GRKERNSEC_IO,
PAX_PAGEEXEC, PAX_KERNEXEC, PAX_MEMORY_UDEREF.


Make sure its not a toolchain issue. It is not if you keep everything
the same and just boot on kernel and it works, the other and it doesn't.


I don't have this card so it would be difficult for me debug this for you.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

On Thu, May 17, 2012 at 3:04 PM, Anthony G. Basile
<basile@opensource.dyc.edu> wrote:
> Liberte, last I looked, has quite a few hardening features off.

True — this is made necessary by having to support virtualized
environments (and, of course, Xorg, wrt. GRKERNSEC_IO). Since out last
discussion on the subject, I have “discovered� the
GRKERNSEC_HARDENED_VIRTUALIZATION profile, which fits quite well the
settings that were carefully selected previously.

By the way, Liberté also mounts /dev with noexec, and I received no
complaints so far (see bug #92921). I also grepped the driver sources
before making the change, and didn't find any attempts to map /dev/mem
with PROT_EXEC. No idea if the noexec issue is still present with
proprietary drivers, though.

--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)

2012.Május 17.(Cs) 15:07 idÅ‘pontban Maxim Kammerer ezt Ã*rta:
> On Thu, May 17, 2012 at 3:04 PM, Anthony G. Basile
> <basile@opensource.dyc.edu> wrote:
>> Liberte, last I looked, has quite a few hardening features off.
>
> True — this is made necessary by having to support virtualized
> environments (and, of course, Xorg, wrt. GRKERNSEC_IO). Since out last
> discussion on the subject, I have “discovered� the
> GRKERNSEC_HARDENED_VIRTUALIZATION profile, which fits quite well the
> settings that were carefully selected previously.
>
> By the way, Liberté also mounts /dev with noexec, and I received no
> complaints so far (see bug #92921). I also grepped the driver sources
> before making the change, and didn't find any attempts to map /dev/mem
> with PROT_EXEC. No idea if the noexec issue is still present with
> proprietary drivers, though.

How would I change the way /dev gets mounted? I don't have noexec as an
option listed by mount for the udev entry.
In my policy file Xorg is permitted to execute /dev/mem: is that no longer
needed? I use the radeon driver, not the proprietary.

Regards:
Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

>
> --
> Maxim Kammerer
> Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
>
>

On Thu, May 17, 2012 at 5:40 PM, "Tóth Attila" <atoth@atoth.sote.hu> wrote:
> How would I change the way /dev gets mounted? I don't have noexec as an
> option listed by mount for the udev entry.

I mount devtmpfs on /dev in initramfs, but you can add an entry to
/etc/fstab, too — see /etc/init.d/udev-mount for details (referring to
OpenRC 0.9.8.4 here).

> In my policy file Xorg is permitted to execute /dev/mem: is that no longer
> needed? I use the radeon driver, not the proprietary.

I didn't encounter any issues with radeon. Apparently, executing
/dev/mem is not needed for any open-source Xorg drivers in portage
tree. The only issue I have seen is that sometimes there is a /dev/mem
*write* failure when FB_UVESA kernel module is loaded, but that is
caused by GRKERNSEC_KMEM, not /dev noexec, and is apparently harmless
(however, I use v86d[x86emu], so YMMV).

--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)

On 05/17/2012 10:08 AM, Maxim Kammerer wrote:
> On Thu, May 17, 2012 at 5:40 PM, "Tóth Attila" <atoth@atoth.sote.hu> wrote:
>> How would I change the way /dev gets mounted? I don't have noexec as an
>> option listed by mount for the udev entry.
>
> I mount devtmpfs on /dev in initramfs, but you can add an entry to
> /etc/fstab, too — see /etc/init.d/udev-mount for details (referring to
> OpenRC 0.9.8.4 here).
>
>> In my policy file Xorg is permitted to execute /dev/mem: is that no longer
>> needed? I use the radeon driver, not the proprietary.
>
> I didn't encounter any issues with radeon. Apparently, executing
> /dev/mem is not needed for any open-source Xorg drivers in portage
> tree. The only issue I have seen is that sometimes there is a /dev/mem
> *write* failure when FB_UVESA kernel module is loaded, but that is
> caused by GRKERNSEC_KMEM, not /dev noexec, and is apparently harmless
> (however, I use v86d[x86emu], so YMMV).
>
Is there a bug open for this?

--
-- Matthew Thode (prometheanfire)

On Thu, May 17, 2012 at 6:50 PM, Matthew Thode
<prometheanfire@gentoo.org> wrote:
> Is there a bug open for this?

There is now (bug #416415). The issue is with reading EBDA area (not
with writing as I wrote previously). I think I didn't open the bug
previously because after looking at v86d sources, the issue seemed
harmless. I think that the issue manifests on some hardware
configurations as well, although the bug mentions only virtualized
environments. If anyone wants to explore further, the easiest way is
probably to try the second boot menu option (VESA) in Liberté Linux
2012.1 — the warning will be shown on the console after "Initializing
VESA framebuffer" notice, if at all.

--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)

2012.Május 17.(Cs) 17:08 idÅ‘pontban Maxim Kammerer ezt Ã*rta:
> On Thu, May 17, 2012 at 5:40 PM, "Tóth Attila" <atoth@atoth.sote.hu>
> wrote:
>> How would I change the way /dev gets mounted? I don't have noexec as an
>> option listed by mount for the udev entry.
>
> I mount devtmpfs on /dev in initramfs, but you can add an entry to
> /etc/fstab, too — see /etc/init.d/udev-mount for details (referring to
> OpenRC 0.9.8.4 here).

It works. Thx: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

>
>> In my policy file Xorg is permitted to execute /dev/mem: is that no
>> longer
>> needed? I use the radeon driver, not the proprietary.
>
> I didn't encounter any issues with radeon. Apparently, executing
> /dev/mem is not needed for any open-source Xorg drivers in portage
> tree. The only issue I have seen is that sometimes there is a /dev/mem
> *write* failure when FB_UVESA kernel module is loaded, but that is
> caused by GRKERNSEC_KMEM, not /dev noexec, and is apparently harmless
> (however, I use v86d[x86emu], so YMMV).
>
> --
> Maxim Kammerer
> Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
>
>

On Thu, May 17, 2012 at 6:04 AM, Anthony G. Basile
<basile@opensource.dyc.edu> wrote:
> Please open a bug, attach both config files. *It would be useful if you also
> identify on which options it breaks. *Liberte, last I looked, has quite a
> few hardening features off. *Pay attention to GRKERNSEC_IO, PAX_PAGEEXEC,
> PAX_KERNEXEC, PAX_MEMORY_UDEREF.

It took less time to work it out than I expected; a bit of a binary
search through the grsecurity/PaX options I had enabled pretty clearly
indicates the culprint is PAX_MEMORY_UDEREF. Using both
xf86-video-intel-2.17.0-r3 and 2.19.0 and xorg-server-1.11.3 and
1.12.1, there's a bug introduced between hardened-sources-3.2.2-r1 and
>=3.2.11 that by enabling PAX_MEMORY_UDEREF the i915/i965 kernel
module gets a "BUG: unable to handle kernel NULL pointer dereference"
in i915_gem_execbuffer_reserve when starting X.

I'll submit a bug shortly.

On 05/17/2012 01:42 PM, RB wrote:
> On Thu, May 17, 2012 at 6:04 AM, Anthony G. Basile
> <basile@opensource.dyc.edu> wrote:
>> Please open a bug, attach both config files. It would be useful if you also
>> identify on which options it breaks. Liberte, last I looked, has quite a
>> few hardening features off. Pay attention to GRKERNSEC_IO, PAX_PAGEEXEC,
>> PAX_KERNEXEC, PAX_MEMORY_UDEREF.
>
> It took less time to work it out than I expected; a bit of a binary
> search through the grsecurity/PaX options I had enabled pretty clearly
> indicates the culprint is PAX_MEMORY_UDEREF. Using both
> xf86-video-intel-2.17.0-r3 and 2.19.0 and xorg-server-1.11.3 and
> 1.12.1, there's a bug introduced between hardened-sources-3.2.2-r1 and
>> =3.2.11 that by enabling PAX_MEMORY_UDEREF the i915/i965 kernel
> module gets a "BUG: unable to handle kernel NULL pointer dereference"
> in i915_gem_execbuffer_reserve when starting X.
>
> I'll submit a bug shortly.
>
must be why I never hit it (I enable kernexec but leave uderef disabled
for virt).

--
-- Matthew Thode (prometheanfire)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18.05.2012 09:18, Matthew Thode wrote:
> On 05/17/2012 01:42 PM, RB wrote:
>> On Thu, May 17, 2012 at 6:04 AM, Anthony G. Basile
>> <basile@opensource.dyc.edu> wrote:
>>> Please open a bug, attach both config files. It would be
>>> useful if you also identify on which options it breaks.
>>> Liberte, last I looked, has quite a few hardening features off.
>>> Pay attention to GRKERNSEC_IO, PAX_PAGEEXEC, PAX_KERNEXEC,
>>> PAX_MEMORY_UDEREF.
>>
>> It took less time to work it out than I expected; a bit of a
>> binary search through the grsecurity/PaX options I had enabled
>> pretty clearly indicates the culprint is PAX_MEMORY_UDEREF.
>> Using both xf86-video-intel-2.17.0-r3 and 2.19.0 and
>> xorg-server-1.11.3 and 1.12.1, there's a bug introduced between
>> hardened-sources-3.2.2-r1 and
>>> =3.2.11 that by enabling PAX_MEMORY_UDEREF the i915/i965
>>> kernel
>> module gets a "BUG: unable to handle kernel NULL pointer
>> dereference" in i915_gem_execbuffer_reserve when starting X.
>>
>> I'll submit a bug shortly.
>>
> must be why I never hit it (I enable kernexec but leave uderef
> disabled for virt).
>

For me X works fine with UDEREF enabled. I'm using xorg-server-1.12.1
and xf86-video-intel-2.19.0. (2 laptops, 1 core2 duo, 1 first
generation i5, if that has got something to do with it)

WKR
Hinnerk


PS: Issuing grep -i pax on my .config I get:

# PaX
CONFIG_PAX_KERNEXEC_PLUGIN=y
CONFIG_PAX_PER_CPU_PGD=y
CONFIG_PAX=y
# PaX Control
# CONFIG_PAX_SOFTMODE is not set
CONFIG_PAX_EI_PAX=y
CONFIG_PAX_PT_PAX_FLAGS=y
CONFIG_PAX_XATTR_PAX_FLAGS=y
# CONFIG_PAX_NO_ACL_FLAGS is not set
CONFIG_PAX_HAVE_ACL_FLAGS=y
# CONFIG_PAX_HOOK_ACL_FLAGS is not set
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
# CONFIG_PAX_EMUTRAMP is not set
CONFIG_PAX_MPROTECT=y
# CONFIG_PAX_MPROTECT_COMPAT is not set
# CONFIG_PAX_ELFRELOCS is not set
CONFIG_PAX_KERNEXEC=y
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_BTS=y
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD="bts"
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y
CONFIG_PAX_MEMORY_STACKLEAK=y
CONFIG_PAX_MEMORY_UDEREF=y
CONFIG_PAX_REFCOUNT=y
CONFIG_PAX_USERCOPY=y
# CONFIG_PAX_SIZE_OVERFLOW is not set




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPtgQaAAoJEJwwOFaNFkYcQ6sH/0JevLNBb1GJWoOvmwzFl8Vw
TCOkwOj7b3iHLXANHt3D3JzPAyLFoSs6kj9MTSHF8IsDfYv8A5 1f5glFw8nnfjVh
+JmD19S0PLSI4u2P6jZbze7/ugI2E8QUUpHE+BVD0VQ1l5sSZ0Ydul5+9sOoH6WY
XMzAHCxiXGmahtANM2I5pdCv1ZVCFCDqm5n6Z9hiijC58WeYPR DQgUgXRaWKm34q
4JZrfShPxOnMO4W0ceCSVCF4E1oECPzD7lwNiu+jmdWCb3uGgV kO3l15I4RM+w3T
TnH9iqV9t/6vAG0bv6K70H6jDCI5aKhPKxXiI/dXUxA2c1eAzckfp4qJxhVydzk=
=Ez18
-----END PGP SIGNATURE-----