clang not ready for KASAN?

[Marc Herbert]

We've noticed some board have switched kernel compilation to clang. This gives good background: https://lwn.net/Articles/734071/

Unfortunately:

$ USE=kasan emerge-reef chromeos-kernel-4_4

scripts/kconfig/conf --silentoldconfig Kconfig
scripts/Makefile.kasan:25: CONFIG_KASAN: compiler does not support all options. Trying minimal configuration
...
...
/mnt/host/source/src/third_party/kernel/v4.4/drivers/net/wireless/iwl7000/mac80211/mlme.c:3595:6: error: stack frame size of 3416 bytes in function 'ieee80211_sta_rx_queued_mgmt' [-Werror,-Wframe-larger-than=]
void ieee80211_sta_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
^
1 error generated.

Should gcc still be preferred when using KASAN? This seems to work:

USE="-clang kasan" emerge-reef chromeos-kernel-4_4

Is this the recommended and sustainable solution? Other?

How would one enable KASAN in some non-interactive (nightly) build? Same USE=-clang flag in some package.use file somewhere?

Thanks in advance!

[Doug Anderson]

Hi,

On Mon, Nov 20, 2017 at 3:43 PM, Marc Herbert <marc.h...@gmail.com> wrote:

We've noticed some board have switched kernel compilation to clang. This gives good background: https://lwn.net/Articles/734071/

Unfortunately:

$ USE=kasan emerge-reef chromeos-kernel-4_4

scripts/kconfig/conf --silentoldconfig Kconfig
scripts/Makefile.kasan:25: CONFIG_KASAN: compiler does not support all options. Trying minimal configuration
...
...
/mnt/host/source/src/third_party/kernel/v4.4/drivers/net/wireless/iwl7000/mac80211/mlme.c:3595:6: error: stack frame size of 3416 bytes in function 'ieee80211_sta_rx_queued_mgmt' [-Werror,-Wframe-larger-than=]
void ieee80211_sta_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
^
1 error generated.

Yeah.  Feel free to follow:

https://bugs.chromium.org/p/chromium/issues/detail?id=781317

...which is currently ownerless but has gotten some attention.

 

Should gcc still be preferred when using KASAN? This seems to work:

USE="-clang kasan" emerge-reef chromeos-kernel-4_4

Is this the recommended and sustainable solution? Other?

Recommended?  Well, it's the only option known to work for now, so I guess I'd recommend it.  ;)

Sustainable?  Not in the long term if we actually want to stop supporting gcc in our chroot (no idea if we will actually do that).  ...but even if we eventually planned to remove gcc from our chroot we couldn't do it for years since there's no real plan to move older kernels (before 4.4) to clang.  ...so seems to me that using "-clang" definitely will work for quite a while.

 

How would one enable KASAN in some non-interactive (nightly) build? Same USE=-clang flag in some package.use file somewhere?

Specify it in the same place you specify USE=kasan?

-Doug

[Nicolas Boichat]

Hi,

Also, you end up testing something slightly different than what we run
in production (clang compiled code may behave a little differently
from gcc). But, well, kasan does instrument all memory accesses, so
it's already quite a bit different from production, so maybe it isn't
so severe.

>
>
>>
>> How would one enable KASAN in some non-interactive (nightly) build? Same
>> USE=-clang flag in some package.use file somewhere?
>
>
> Specify it in the same place you specify USE=kasan?

I use this for KASan:
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/321571,
that sets USE=kasan globally in make.defaults.

I'm not sure if setting USE="-clang" globally is the right thing to do
(are there other packages using that USE flag?).

Removing src/overlays/overlay-reef/profiles/base/package.use should do
the trick:
https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/780699

(untested, please let me know)

Best,

>
> -Doug
>
> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>

[Matthias Kaehlcke]

not many, but one important one:

equery-kevin h clang

 * Searching for USE flag clang ... 

[I--] [??] chromeos-base/chromeos-chrome-0:0

[I--] [??] chromeos-base/libmojo-395517-r1:0

[I-O] [  ] sys-kernel/chromeos-kernel-4_4-9999:0

 

Removing src/overlays/overlay-reef/profiles/base/package.use should do
the trick:
https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/780699

(untested, please let me know)

This hack should do for now, but probably soon a slightly different hack would be needed, since we plan to switch all remaining devices with v4.4 kernel to clang.

--

Matthias Kaehlcke |

Software Engineer |

m...@google.com

[marc.h...@intel.com]

Thanks for all the details and suggestions, really appreciated! We will experiment more and report again later.

I don't think this warning has been discussed though:

scripts/Makefile.kasan:25: CONFIG_KASAN: compiler does not support all options. Trying minimal configuration

While I'm struggling with Makefile.kasan and cc-option, it looks like the kernel Makefiles fall back on the most basic set of ASAN features before they even fail to compile.

I couldn't really relate the features dropped by Makefile.kasan with https://clang.llvm.org/docs/AddressSanitizer.html#limitations

So even after 781317 and all other errors are fixed, gcc should still be preferred to get the full KASAN experience? 

By the way do the address sanitizers in gcc and llvm share any code with each other? Or are they just different (re-)implementations of the same ideas under different licenses?

Thanks in advance!

[Matthias Kaehlcke]

For this specific case it would be interesting to be able to set/clear a USE flag depending on the value of another flag, similar to specifying (R)DEPENDs, but AFAIK there is no provision for this.

Mike, do you by chance have an idea on how to elegantly fall back to gcc when ASAN is enabled?