On Sat, Aug 20, 2016 at 3:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Noah Misch <n...@leadboat.com> writes: >> On Fri, Aug 19, 2016 at 07:22:02PM -0400, Tom Lane wrote: >>> So maybe we ought to work towards taking those out? > >> Maybe. It's a policy question boiling down to our willingness to spend >> cycles >> zeroing memory in order to limit trust in the confidentiality of storage >> backing the data directory. Think of "INSERT INTO t VALUES(my_encrypt('key', >> 'cleartext'))", subsequent to which bits of the key or cleartext leak to disk >> by way of WAL padding bytes. A reasonable person might expect that not to >> happen; GNU Privacy Guard and a few like-minded programs prevent it. I'm on >> the fence regarding whether PostgreSQL should target this level of vigilance. >> An RDBMS is mainly a tool for managing persistent data, and PostgreSQL will >> never be a superior tool for data that _must not_ persist. Having said that, >> the runtime cost of zeroing memory and the development cost of reviewing the >> patches to do so is fairly low. > > [ after thinking some more about this... ] > > FWIW, I put pretty much zero credence in the proposition that junk left in > padding bytes in WAL or data files represents a meaningful security issue. > An attacker who has access to those files will probably find much more > that is of interest in the non-pad data. My only interest here is in > making the code sanitizer-clean, which seems like it is useful for > debugging purposes independently of any security arguments. > > So to me, it seems like the core of this complaint boils down to "my > sanitizer doesn't understand the valgrind exclusion patterns that have > been created for Postgres". We can address that to some extent by trying > to reduce the number of valgrind exclusions we need, but it's unlikely to > be practical to get that to zero, and it's not very clear that adding > runtime cycles is a good tradeoff for it either. So maybe we need to push > back on the assumption that people should expect their sanitizers to > produce zero warnings without having made some effort to adapt the > valgrind rules.
One idea is to add protect additional memory-clearing operations with #ifdef SANITIZER_CLEAN or something of that sort. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers