[arch-general] AppArmor support

[Carsten Mattner]

On 9/10/18, Levente Polyak via arch-general <arch-general at archlinux.org> wrote:

> It is quite definitively equally stable as vanilla linux is, there is no
> crazy overly invasive stuff in hardened that would justify claiming
> otherwise.

That hasn't been my experience, and I'm happy to hear I might be an
outlier. I am grateful for the work you put in and hope to see hardened
features be completely included in Linus' tree some day.

> What you most likely encountered, like literally all other "instability"
> issues so far, is that with your setup you triggered a stock vanilla
> linux bug with the difference that hardened immediately shuts itself
> down for security reasons. These bugs are corruption and integrity
> related and shutting down follows "better safe then sorry" for the
> hardened variant.
> There are various kernel configs doing so, to name some:
> CONFIG_BUG_ON_DATA_CORRUPTION, CONFIG_DEBUG_LIST, CONFIG_DEBUG_SG and
> lots more including slab sanitizing/verifying specifically in
> combination with CONFIG_PANIC_ON_OOPS.

That's a possible explanation, and I wasn't complaining, but what I
wrote seems to signal that. I'm sorry it sounded like a complain.
The message I was trying to convey is that proposing linux-hardened
to make use of a feature that's been stable in Linus' tree isn't
a good idea due to stability and reluctant support likelihood when
you run into a problem.

If I have a problem with Fedora, I first ask in Fedora's forums
because they patch their kernel a lot. With Arch, I don't have
to because "linux" only carries a couple backports of fixes,
and all I need to show is config.gz.

With all that being said, I'm genuinely glad to hear that linux-hardened
generally works and I have just been unlucky to hit the right code paths.

> Just a crazy idea but how about contributing back instead of just
> complaining? People on the bug tracker always help guiding how to report
> upstream or finding relevant commits. Yeah, i know it takes a while to
> compile, but it's not that complicated:
> - take a look at the panic in hardened
> - peek the code around it to find out which of the protective config
>   values may have triggered it (if not already obvious from the panic)
> - reproduce on stock/vanilla kernel by building it including the
>   responsible configs
> - report upstream using the gathered information of the vanilla kernel
> - bonus points for git bisecting the commit that broke it
>
> This would not only contribute to make hardened run on your or similar
> setups, all vanilla linux users would benefit by helping to fix a bug
> that can or does result in a corruption.

I did and do. I have open bugs in freedesktop and kernel bugzilla which
are not resolved and in NEW state for months and years. These are usually
regressions in drivers due to the Linux driver packaging model and
insufficient testing on supported hardware configurations. What happens
is that a driver that works flawlessly on hardware rev-1.8 suddenly starts
misbehaving with a newer kernel that has seen improvements, refactorings,
and support for newer hardware. It's most prominent in the graphics stack,
which is complex, hard to test, and easy to break. I don't blame the
developers for having a hard time, I'm discouraged stable drivers for
old hardware get regressions and stop being tested as well as hardware
of years -2/+2 years.

Therefore, I hope you don't mind if my frustration level with the issues
I'm tracking right now is high enough that I'm not in the mood to debug
and track issues I can avoid by using a different stable kernel branch.

Greg, rightfully for the most part, always encourages people to upgrade
to the latest stable branch, but he never talks about preventable
regressions that happen due to speed and unnecessary modifications in
stable drivers for older hardware. What's telling is that it's primarily
hardware drivers, while the general kernel code isn't regressing. If
Linux had a driver ABI......