Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 29 Oct 2016 06:57:07 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: David Windsor <dwindsor@...il.com>, "kernel-hardening@...ts.openwall.com"
	<kernel-hardening@...ts.openwall.com>, Hans Liljestrand
	<ishkamiel@...il.com>, Kees Cook <keescook@...omium.org>, AKASHI Takahiro
	<takahiro.akashi@...aro.org>, Colin Vidal <colin@...dal.org>
Subject: RE: Expanding HARDENED_ATOMIC

Hi David, 

Thank you for letting us know! The most up-to-date branch now is hardened_atomic_next since it contains most recent fixes and it is rebased on top of latest Linux-next stable. 
I will probably terminate hardened_atomic_on_next branch after I cherry-pick your documentation change. 

I would propose that we send the existing rfc this weekend without your new additions and then we can include them into new rfcv4 or it might be also new patch set all together since this one is already so big. 
What do you think?

Best Regards,
Elena.

> I've created a branch on Elena's github repo called hardened_atomic_on_next_expanded
(https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next_expanded)
which incorporates the PAX_REFCOUNT changes to extend atomic_t coverage to kernel reference counters that were originally integer types.  Our work to this point only addresses existing atomic_t users:
this patch is a first attempt to convert non-atomic_t reference counter users to use atomic_t, and thus get overflow protection.

The users addressed in this branch are:
  * struct fs_struct.users
  * struct tty_port.count
  * struct tty_ldisc_ops.refcount
  * struct pipe_inode_info.{readers|writers|files|waiting_writers}
  * struct kmem_cache.refcount

This branch currently does not compile, as I am in the process of cherrypicking the necessary changes from PAX_REFCOUNT.

I wanted to let Elena/Hans know about this now, as they are preparing the next RFC.  I don't know if we want to actually expand kernel coverage in this round of RFC's, but there shouldn't be much more work left to get this working.

Thanks,
David

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.