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: <20131009033946.GS6882@two.firstfloor.org>
Date:	Wed, 9 Oct 2013 05:39:46 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, peterz@...radead.org,
	Andi Kleen <ak@...ux.intel.com>, fweisbec@...il.com
Subject: Re: [PATCH 6/6] x86: Allow disabling HW_BREAKPOINTS and PERF_EVENTS

Some more comments.

>   - your patches might break apps/ABI

Can you please explain that a bit more. We have a lot of CONFIG options
that disable syscalls, /sys, lots of stuff. Whoever uses them needs
to know what they are doing. I thought it was pretty
much consensus that Linux is supposed to be a very configurable OS,
which people can taylor from small embedded to large kitchen sink
included using CONFIG_*. 

Are you saying that Linux should not be configurable small to big? (I would
find that hard to believe). If that's really your standpoint I would
like to see some confirmation on this, as it would seem a big 
departure from traditional practice.

Or is the concern that you want it default y or EXPERT, so what
the defaults are? That sounds reasonable.

Or should it be more modular like Peter pointed out (that
would seem like a good solution for generic distros, but not so
good for deeply embedded like running on Quark)

BTW afaik pretty much every other architecture still allows to disable
it, just x86 has this dependency loop problem.

> 
>   - your patch-set unnecessarily complicates things, making the kernel
>     less maintainable

I actually simplified some things, like unnecessary
dependencies between perf and profile.

These should be applied in any case as they are independent.
I can repost them.

Given some of the ifdefs/configs were not nice, perhaps there's a better
solution for this from Frederic.

-Andi
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ