linux-kernel - Re: [PATCH 00/20] ceph: Ceph distributed file system client v0.10

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 16 Jul 2009 10:11:48 -0700 (PDT)
From:	Sage Weil <sage@...dream.net>
To:	Andi Kleen <andi@...stfloor.org>
cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/20] ceph: Ceph distributed file system client v0.10

On Thu, 16 Jul 2009, Andi Kleen wrote:
> Sage Weil <sage@...dream.net> writes:
> 
> > This is v0.10 of the Ceph distributed file system client.
> >
> > Changes since v0.9:
> >  - fixed unaligned memory access (thanks for heads up to Stefan Richter)
> >  - a few code cleanups
> >  - MDS reconnect and op replay bugfixes.  (The main milestone here is
> >    stable handling of MDS server failures and restarts, tested by
> >    running various workloads with the servers in restart loops.)
> >
> > What would people like to see for this to be merged into fs/?
> 
> Some more comments in the code probably wouldn't help. e.g. each
> file should have some description at the top what it does.

Will do.

> What I always wonder with new complex networking protocols 
> (which ceph essentially is): has there been some auditing/testing
> what happens when a server feeds unexpected/out of bounds data
> to the client? e.g. a security audit would be good. Otherwise
> you might end up with remote exploits.

There are some macros I use for parsing incoming messages that check the 
message bounds, so there's no danger of walking past the end of the 
message (see decode.h in patch 15/20).

I don't always verify that things like element counts are "sane", though, 
so there's currently the possibility of trying to allocate large chunks of 
memory.  Protecting against that sort of malicious data from the server is 
difficult in general, and I'm not sure what the best approach is.  The 
server needs to be trusted to some extent or another.  Client and server 
authentication isn't implemented yet, but the plan is for the client to 
have a cryptographic key (or keys) to authenticate both itself and the 
server before exchanging any meaningful data.

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