Re: [GIT PULL] First batch of KVM changes for 4.1

Andy Lutomirski
2015-04-17T22:25:55Z

On Fri, Apr 17, 2015 at 3:04 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> Muahaha. The auditors have invaded your system. (I did my little
>> benchmark with a more sensible configuration -- see way below).
>>
>> Can you send the output of:
>>
>> # auditctl -s
>> # auditctl -l
>
> # auditctl -s
> enabled 1
> flag 1
> pid 822
> rate_limit 0
> backlog_limit 320
> lost 0
> backlog 0
> backlog_wait_time 60000
> loginuid_immutable 0 unlocked
> # auditctl -l
> No rules

Yes, "No rules" doesn't mean "don't audit".

>
>> Are you, perchance, using Fedora?
>
> F21. Yup.
>
> I used to just disable auditing in the kernel entirely, but then I
> ended up deciding that I need to run something closer to the broken
> Fedora config (selinux in particular) in order to actually optimize
> the real-world pathname handling situation rather than the _sane_ one.
> Oh well. I think audit support got enabled at the same time in my
> kernels because I ended up using the default config and then taking
> out the truly crazy stuff without noticing AUDITSYSCALL.
>
>> I lobbied rather heavily, and
>> successfully, to get the default configuration to stop auditing.
>> Unfortunately, the fix wasn't retroactive, so, unless you have a very
>> fresh install, you might want to apply the fix yourself:
>
> Is that fix happening in Fedora going forward, though? Like F22?

It's in F21, actually. Unfortunately, the audit package is really
weird. It installs /etc/audit/rules.d/audit.rules, containing:

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# This suppresses syscall auditing for all tasks started
# with this rule in effect. Remove it if you need syscall
# auditing.
-a task,never

Then, if it's a fresh install (i.e. /etc/audit/audit.rules doesn't
exist) it copies that file to /etc/audit/audit.rules post-install.
(No, I don't know why it works this way.)

IOW, you might want to copy your /etc/audit/rules.d/audit.rules to
/etc/audit/audit.rules. I think you need to reboot to get the full
effect. You could apply the rule manually (or maybe restart the audit
service), but it will only affect newly-started tasks.

>
>> Amdy Lumirtowsky thinks he meant to attach a condition to his
>> maintainerish activities: he will do his best to keep the audit code
>> *out* of the low-level stuff, but he's going to try to avoid ever
>> touching the audit code itself, because if he ever had to change it,
>> he might accidentally delete the entire file.
>
> Oooh. That would be _such_ a shame.
>
> Can we please do it by mistake? "Oops, my fingers slipped"
>
>> Seriously, wasn't there a TAINT_PERFORMANCE thing proposed at some
>> point? I would love auditing to set some really loud global warning
>> that you've just done a Bad Thing (tm) performance-wise by enabling
>> it.
>
> Or even just a big fat warning in dmesg the first time auditing triggers.
>
>> Back to timing. With kvm-clock, I see:
>>
>> 23.80% timing_test_64 [kernel.kallsyms] [k] pvclock_clocksource_read
>
> Oh wow. How can that possibly be sane?
>
> Isn't the *whole* point of pvclock_clocksource_read() to be a native
> rdtsc with scaling? How does it cause that kind of insane pain?

An unnecessarily complicated protocol, a buggy host implementation,
and an unnecessarily complicated guest implementation :(

>
> Oh well. Some paravirt person would need to look and care.

The code there is a bit scary.

--Andy

>
> Linus

--
Andy Lutomirski
AMA Capital Management, LLC