Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea@cpushare.com]

On Fri, Jul 14, 2006 at 01:20:26AM +0200, Pavel Machek wrote:
> I do not want to enter seccomp flamewar, and that's why I did not
> answer to Ingo.

Ok ;), I didn't imagine this was the reason. So we agree that the risk
introduced by the availability of the TSC is orders of magnitude
higher than whatever network timing attack.

> Strictly speaking, this is wrong. This is like adding noise into the
> room. You have to pick up maximum delay (ammount of noise), and you
> clearly can't override signal that's longer than maximum delay. But
>
> you also can't override signal that's half the maximum delay, given
> that transmitter will retransmit it 4-or-so times. Just average 4
> samples, and your random delays will cancel out.
> 
> No, this probably does not apply to seccomp, because we are picking
> unintended noise from affected computer.

Well, perhaps I wasn't clear enough, but I am only talking about
seccomp not some other unrelated and hypothetical network system.

I know a few algorithms are potentially vulnerable to network timing
attacks, the tcp sequence number and urandom comes to mind. urandom is
perhaps the worst of all (which btw, it also gets data from the
tsc). Those issues have absolutely nothing to do with seccomp.

As far as seccomp is concerned the only worry is the demonstration of
the timing side channel that was getting openssl keys by controlling
the host and running openssl commands on the other cpu at his
will. And to do that you need the TSC. Even that is totally vapourware
because the attacked environment was strictly controlled by the
attacker, it's unclear what would happen shall the attacked
environment being mostly random like in real life. Disabling the TSC
has been generally agreed good enough to stop it.

The second one in the priority list are the readonly ptes mapping HPET
on some x86-64 config. The network timing attack to CPUShare is way
over what I could actually worry about.

> OTOH I'm pretty sure I could communicate from seccomp process by
> sending zeros alone, and I cound communicate from another process on
> box running seccomp through your randomizing packetizer to my machine.

You mean you could communicate using some sort of morse-code and you
would use the frequency of the zero to send the messages? That's
certainly possible today (without any randomizer), but the timing will
be measurable through the internet, so you're talking morse-code in
cleartext over the internet. The whole internet will sniff your
message. Furthermore I register all ip and ports for all transactions,
so it's really no different from direct a tcp connection even if you
talk encrypted-more-code over it, you're only wasting some resources.

Also note, there's absolutely no way for you to know for sure who you
are talking with.

So I don't see anything to worry about, feel free to communicate with
the other side through seccomp if you want, I'm certainly not adding a
randomizer to prevent that.

Thanks.