Discussion:
cost/benefit of some src.conf options
Dimitry Andric
2021-03-26 18:46:33 UTC
Permalink
Please can someone briefly explain the impact of the following, in
1. WITH_INIT_ALL_PATTERN=
2. WITH_KERNEL_RETPOLINE=
3. WITH_RETPOLINE=
How briefly, exactly? Quoting src.conf(5), in order:

WITH_INIT_ALL_PATTERN
Set to build the base system or kernel with stack variables
initialized to (compiler defined) debugging patterns on function
entry. This option requires the clang compiler.


WITH_KERNEL_RETPOLINE
Set to enable the "retpoline" mitigation for CVE-2017-5715 in the
kernel build.


WITH_RETPOLINE
Set to build the base system with the retpoline speculative
execution vulnerability mitigation for CVE-2017-5715.
these aren't enabled by default in arm64. Is there a reason for that?
First of all, because of the performance impact, which can be
significant depending on your specific use case. And secondly, because
compiling with non-default options tends to expose unexpected bugs in
the implementation. (Both in the compiler itself, and in the programs
which are compiled.)

That said, the retpoline mechanisms tend to be fairly well tested by
now, but will still have a non-negligible performance impact, maybe even
a large impact, depending on your workload. There is no simple answer
here, you will have to measure it for yourself.

The init pattern stuff is pretty new, and will almost certainly give
some unexpected effects, such as triggering assertions, and hopefully
exposing bugs. But you will most likely also run into corner cases that
are not handled well by the compiler and/or the software you are
building. The performance impact will certainly not be negligible due
to all the additional memory accesses. :)

-Dimitry
Chris
2021-03-26 21:35:11 UTC
Permalink
Post by Dimitry Andric
That said, the retpoline mechanisms tend to be fairly well tested by
now, but will still have a non-negligible performance impact, maybe even
a large impact, depending on your workload. There is no simple answer
here, you will have to measure it for yourself.
_ RETpoline is an alternative to IBRS;
_ the impact of RETpoline should be lower than IBRS;
_ IBRS is enabled by default.
Did I get it wrong?
My understanding is that retpoline is really only of interest if your box
might
accessed *locally* by *untrusted* individuals. See:

https://nvd.nist.gov/vuln/detail/CVE-2017-5715

--Chris
So, unless someone is willing to disable IBRS and live without mitigation,
it
would be interesting to know how performance differs between the two.
I've seen IBRS's impact on bhyve-hosted Windows guests reach 15%-20%.
I
guess "fairly well tested" does not mean "production ready", or it would be
enabled by default, wouldn't it? :)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
Andrea Venturoli
2021-03-27 20:58:51 UTC
Permalink
Post by Chris
My understanding is that retpoline is really only of interest if your
box might
accessed *locally* by *untrusted* individuals.
Thanks.

Does an user on a guest VM qualifies as *untrusted*?
Or does a closed-source software on such VM?

In any case, if RETpoline is so, then is IBRS.
The comparison would still be interesting to me.
tech-lists
2021-03-27 11:55:19 UTC
Permalink
Thanks everyone, now I know what to look for.

So far, for my use case [1] i've not detected any change. but then again
I've not looked that closely. I guess in order to test, need to time the
operation of various programs.

[1] raspberry pi 4/8GB, 2GHz, nginx, exim, poudriere, mutt, zfs.
--
J.
Loading...