All of lore.kernel.org
 help / color / mirror / Atom feed
From: Connor Kuehl <cipkuehl@gmail.com>
To: Dan Aloni <dan@kernelim.com>, Stephen Smalley <sds@tycho.nsa.gov>
Cc: Kees Cook <keescook@chromium.org>,
	Paul Moore <paul@paul-moore.com>,
	SELinux <selinux@vger.kernel.org>,
	Jeffrey Vander Stoep <jeffv@google.com>,
	Ondrej Mosnacek <omosnace@redhat.com>
Subject: Re: Does anyone use RANDSTRUCT?
Date: Sat, 14 Dec 2019 16:33:04 -0800	[thread overview]
Message-ID: <bc8d099a-2973-22cb-d6b0-cae8786eeea8@gmail.com> (raw)
In-Reply-To: <20191213223958.GB31026@gmail.com>

On 12/13/19 2:39 PM, Dan Aloni wrote:
>> Do you know if there is something inhibiting usage in e.g. Pixel devices?
>> Performance impact?
> About performance, the gcc RANDSTRUCT implementation also includes a
> performance-preserving feature where randomization takes cacheline
> boundary into consideration. The Clang implementation is expected to
> have this as well. It's a valid concern and definitely garners testing
> for anyone enabling the feature.

Just confirming this: the development branch (well I suppose that's 
technically the only branch :-) ) for Clang randstruct does already have 
this feature -- it will try its hardest to squeeze the fields into cache 
lines. It's worth noting however that this algorithm is in its first 
iteration with potentially many more to come as people that are much 
smarter than me start digging into it and contributing optimizations 
while Clang randstruct gets closer and closer to getting merged upstream.

Unfortunately I have not measured or collected any data on the 
performance implications of Clang randstruct yet... but that is 
something I am interested in doing once we've gotten all of the wrinkles 
figured out.

- Connor

      reply	other threads:[~2019-12-15  0:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13 15:40 Does anyone use RANDSTRUCT? Stephen Smalley
     [not found] ` <CAOSEQ1qhxdA+JW4M6rOqjzTuMXu2hr0jxRt9NfkuEcWW7-_BEQ@mail.gmail.com>
2019-12-13 15:53   ` Stephen Smalley
2019-12-13 18:05 ` Kees Cook
2019-12-13 18:36   ` Stephen Smalley
2019-12-13 22:39     ` Dan Aloni
2019-12-15  0:33       ` Connor Kuehl [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc8d099a-2973-22cb-d6b0-cae8786eeea8@gmail.com \
    --to=cipkuehl@gmail.com \
    --cc=dan@kernelim.com \
    --cc=jeffv@google.com \
    --cc=keescook@chromium.org \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.