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
prev parent 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.