public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] TIF_NOTSC and SECCOMP prctl
@ 2006-07-18 10:20 Chuck Ebbert
  2006-07-18 13:29 ` andrea
  0 siblings, 1 reply; 8+ messages in thread
From: Chuck Ebbert @ 2006-07-18 10:20 UTC (permalink / raw)
  To: andrea@cpushare.com
  Cc: bruce@andrew.cmu.edu, linux-kernel, Alan Cox, Arjan van de Ven,
	Adrian Bunk, Lee Revell, Linus Torvalds, Ingo Molnar

In-Reply-To: <20060714060932.GE18774@opteron.random>

On Fri, 14 Jul 2006 08:09:32 +0200, andrea@cpushare.com wrote:

> The below patch seems to work, I ported all my client code on top of
> prctl already. (it's a bit more painful to autodetect a kernel with
> CONFIG_SECCOMP turned off but I already adapted to it)

AFAIC the /proc method of controlling seccomp is so ugly it should
just go, but what about backwards compatibility?

I have a couple of questions:


+void disable_TSC(void)
+{
+       if (!test_and_set_thread_flag(TIF_NOTSC))
+               /*
+                * Must flip the CPU state synchronously with
+                * TIF_NOTSC in the current running context.
+                */
+               hard_disable_TSC();
+}

This gets called from sys_prctl().  Do you need to worry about preemption
between the test_and_set and TSC disable?


--- a/include/asm-i386/processor.h      Thu Jul 13 03:03:35 2006 +0700
+++ b/include/asm-i386/processor.h      Fri Jul 14 07:47:57 2006 +0200
@@ -256,6 +256,10 @@ static inline void clear_in_cr4 (unsigne
        cr4 &= ~mask;
        write_cr4(cr4);
 }
+
+extern void hard_disable_TSC(void);
+extern void disable_TSC(void);
+extern void hard_enable_TSC(void);

Maybe these should be inline?  They're really small and that way you
don't need #ifdef around the code for them.


> Reviews are welcome (then I will move into x86-64, all other archs
> supporting seccomp should require no changes despite the API
> change). Thanks.

For x86_64 you need this:

ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt-current/patches/tif-flags-for-debug-regs-and-io-bitmap-in-ctxsw

But I don't think Andi plans on pushing it for 2.6.18.

-- 
Chuck

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [patch] let CONFIG_SECCOMP default to n
@ 2006-07-11 14:17 andrea
  2006-07-11 14:32 ` Arjan van de Ven
  0 siblings, 1 reply; 8+ messages in thread
From: andrea @ 2006-07-11 14:17 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Adrian Bunk, Andrew Morton, Lee Revell, linux-kernel, Alan Cox,
	Linus Torvalds

On Tue, Jul 11, 2006 at 09:36:25AM +0200, Ingo Molnar wrote:
> 
> * andrea@cpushare.com <andrea@cpushare.com> wrote:
> 
> > On Fri, Jun 30, 2006 at 11:47:53AM +0200, Ingo Molnar wrote:
> > > and both are pledged and available to GPL users. [..]
> > 
> > If the GPL offered any protection to my system software I would 
> > consider it too, but the GPL can't protect software that runs behind 
> > the corporate firewall. [...]
> 
> so you admit and confirm that you explicitly and intentionally do not 
> pledge your patent to GPL users. [..]

How many times do I need to say it. The pending patent has nothing to do
with the kernel, and it is _not_ pledged under the GPL.

The software world is moving from proprietary software that runs on top
of end user computers, to proprietary software that runs behind the
firewall. And the GPL is getting old and not capable to cope with the
second kind of usage of the software. This is being discussed in gplv3
context.

This isn't too bad, because as long as the software you run is open
source, you're guaranteed to be in control of what runs on your
computer, in control of your privacy, and in control of your security.
So it's a better model, you pratically run the proprietary software on
the server through the firefox open source client stack, but but the
general forced-contribution-mode that the GPL allows, tends to weaken
signficantly when software is only meant to run behind the firewall of
large corporations that don't depend on external companies for their own
software support.

I've no magic solution for this, I'm not a lawyer so I've no idea if
anything more than the GPL would be enforceable under US law in the
first place (until recently it wasn't even 100% sure that the GPL was
enforceable), so I certainly can't help on this side.

> [..] That is troubling (and unethical) in my 

You should talk about ethics to the people that written the law,
certainly not with me. I've to comply with the law and with the rules of
economy. It's not my fault the fact that if I don't file patents I risk
troubles ahead. I'm against patents too and it wasn't fun to pay for the
legal costs of the filing. I seem to recall that transmeta also filed a
software patent over the CMS but it seems people had not many problems
to work for them (you once sent emails @transmeta.com too). Transmeta
perhaps was the smallest player, there are many more bigger examples
that I won't be making.

Furthermore I obtained no patents yet, it could be the way I written the
text is wrong or whatever, I'm not the most expert in terms of patents,
I did my best just to be sure I couldn't regret having done a fatal
and obvious mistake later and it seems everything is going fine, but
doing my best is definitely no guarantee of success. So it could be all
this will be void if I've bad luck and they reject my application.

> opinion and strengthens my argument that this feature should be _at a 
> minimum_ be made default-off, just like hundreds of other kernel 
> features are.

See the below email of yours.

Also note, seccomp is the basic mode, at some point trusted
computing will be supported by xen so then I'll have a compelling reason
to switch the client side from seccomp to xen. But even then I'll be
always supporting seccomp for a long time because it's the most solid
and simplest mode of all.

> I'm also wondering what the upstream decision would have been, had you 
> disclosed this patent licensing intention of yours. (to use the GPL-ed 

Talking about patents when submitting seccomp, would be like talking
about mp3 patents when submitting alsa code or talking about google
server side patents when submitting a new tcp/ip feature that could
allow google render html faster. This whole discussion is officially
offtopic and it's a pure waste of bandwidth(tm), believe it or not.

All grid computing providers out there are welcome to start using
seccomp today to make their clients more secure against possible
software bugs in the remote computed bytecode. I welcome boinc to start
using seccomp too, I welcome worldcommunitygrid to use seccomp on the
linux client, I welcome all OS vendors to add seccomp to their OS, I
even tried to contact apple since it should be easy to port seccomp to
their kernels.

As far as cpushare is concerned, I never had anything to hide. The legal
part of the website is there since day zero I think.

> Linux kernel as a vehicle for your 'invention', while not fully living 
> up to the basic quid-pro-quo.).

If you prefer I can move all patent pending code on top of windows,
though I believe the "powered by" ads on my site were nice ads for free
software and open source (and obviously I'm very proud to be using them
like I'm very proud to be able to contribute to free software as well).
If you check the user agreement I even stated that any income generated
by cpucoins transactions started by cpushare will be donated to the
development of open source software.

> So i'd like to request the patch below to be included in v2.6.18.

Here the email that now you're forcing me to remind you:

http://www.cpushare.com/hypermail/cpushare-discuss/06/01/0080.html

	"ok, i agree with you here - having it on by default does make
	sense from an API uniformity POV."

I didn't feel the need of mentioning this opinion of yours before as
backing for my arguments pro Y, because I thought you were agreeing with
my previous post and that my arguments alone were enough, but since you
changed your mind again...

Note that I don't think Y or N makes any difference at the end for my
project. But fedora could set it to N under your advice and that would
do more damage to my project than whatever default setting we have
in-kernel. So if you want to hurt my project, you should ask Dave to
turn off seccomp instead of asking Linus to turn off it in the kernel
source.

Even more significant is that fact that it turns out 90% of the
interested userbase seems windows based, so for 90% of users it won't
matter if seccomp is even in the kernel.

Even if you seem to believe I don't care about the kernel when I talk
about seccomp, I really think Y is the right setting for the kernel, and
I'm not speaking for my own personal usages of seccomp, for the reason
why you also agreed with it in the above email a few months ago.

But like I said in previous emails, if these discussion about Y or N
have to keep going, then feel free to apply Ingo patch to make him
happy. I'm happy either ways even but I think Y is the appropriate
setting like with EPOLL and friends, now that all overhead triggered by
the purely paranoid additional feature has been removed by default.

config EPOLL
        bool "Enable eventpoll support" if EMBEDDED
        default y

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2006-07-26 11:44 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-18 10:20 [PATCH] TIF_NOTSC and SECCOMP prctl Chuck Ebbert
2006-07-18 13:29 ` andrea
2006-07-25 21:44   ` andrea
2006-07-26  8:07     ` Ingo Molnar
2006-07-26 11:45       ` andrea
  -- strict thread matches above, loose matches on Subject: below --
2006-07-11 14:17 [patch] let CONFIG_SECCOMP default to n andrea
2006-07-11 14:32 ` Arjan van de Ven
2006-07-11 15:31   ` andrea
2006-07-11 16:24     ` Alan Cox
2006-07-12 15:43       ` Andi Kleen
2006-07-12 21:07         ` Ingo Molnar
2006-07-13  1:51           ` Andrew Morton
2006-07-13  7:44             ` James Bruce
2006-07-13  8:34               ` andrea
2006-07-13  9:18                 ` Andrew Morton
2006-07-14  6:09                   ` [PATCH] TIF_NOTSC and SECCOMP prctl andrea
2006-07-14  6:27                     ` Andrew Morton
2006-07-14  6:33                       ` andrea

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox