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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFznSpc+6DH6JGXRO0MqwJA_190QWbW9awKL=eNGByz0rg@mail.gmail.com>
Date:	Fri, 17 Apr 2015 18:04:59 -0400
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	John Stultz <john.stultz@...aro.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Gleb Natapov <gleb@...nel.org>, kvm list <kvm@...r.kernel.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Andrew Lutomirski <luto@...nel.org>
Subject: Re: [GIT PULL] First batch of KVM changes for 4.1

On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski <luto@...capital.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

> 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?

> 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?

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

           Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/