lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 17 Nov 2010 14:14:43 -0800
From:	Kees Cook <>
To:	Pavel Machek <>
Subject: Re: [Security] proactive defense: using read-only memory

Hi Pavel,

On Wed, Nov 17, 2010 at 11:00:54AM +0100, Pavel Machek wrote:
> > - Modules need to be correctly marked RO/NX. This patch exists[3], but is
> >   not in mainline. It needs to be in mainline.
> Why not.

That was answered in another thread: basically, it was side-tracked, but
has been recently re-proposed.

> > - Pointers to function table also need to be marked read-only after
> >   they are set. An example of this is the security_ops table pointer. It
> >   gets set once at boot, and never changes again. These need to be handled
> >   so it isn't possible to just trivially reaim the entire security_ops
> >   table lookup somewhere else.
> But there are too many of those. You can't block them all...

Well, I don't think "too many" is a good reason. And I think it is possible
to block them all if we're careful and diligent. Maybe I'm naive; we'll see.

> > - Entry points to set_kernel_text_rw() and similar need to be blockable.
> >   Having these symbols available make kernel memory modification trivial;
> What prevents attacker to just inlining those functions in the
> exploit?

The goal is to make it harder for an attacker to create, change, or hide
kernel code in memory. If they're able to already execute arbitrary code,
then yes, it's doesn't change anything. But the point is to make it harder
to get to that point to start with.

> If you want protection domain inside kernel, perhaps you should take
> ukernel approach?

Someone might want to, but I'm not interested in that. It's not impossible
to make the existing kernel more resilient to attack.


Kees Cook
Ubuntu Security Team
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists