Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storage manager encryption #178

Merged
merged 15 commits into from
Jun 26, 2024
Merged

Storage manager encryption #178

merged 15 commits into from
Jun 26, 2024

Conversation

dutow
Copy link
Collaborator

@dutow dutow commented Apr 15, 2024

This PR currently contains two commits:

  1. makes the current code compile on PG17 without breaking anything on PG16, but not trying to make the extension work with PG17.
  2. adds an SMGR based AES-CBC encryption, which works with the patched PG17 development branch

Copy link

github-actions bot commented Apr 15, 2024

Performance test results:
Normal queries: 9120
TDE queries: 8450
Percentage: 92%

Because the current smgr patchset is based on the PG17 branch, smgr
development needs to be based on that. But our current copied PG16
code doesn't compile with PG17.

This commit doesn't try to make the pg_tde AM work with PG17, only
"comments out" with conditional commands parts that do not compile.

PG16 builds work as before, without any changes.

PG17 at least compiles with missing code, probably doesn't really work.
* Encrypts XLog pages while writing them to the segment file.
* Add WAL ecryption GUC.
* Both streaming and logical replication are working.
* TODO: needs key management.
@dutow dutow closed this Jun 4, 2024
codeforall and others added 12 commits June 11, 2024 19:26
…es. (#196)

This commit implements ddl-start and ddl-end event triggers to identify index
creation operations on encrypted tables. Upon creating an index on an encrypted
table, the trigger function updates the global state, which can be accessed by
the storage manager (mgr) to decide if smgr_create needs to do encryption or not.

The start-ddl function analyzes the CREATE TABLE and CREATE INDEX statements
and identifies if the table uses the pg_tde access method. When the table is
created or the one on which the index is being created utilizes the
pg_tde access method, the start-ddl trigger function populates relevant
information about the encrypted table into a global structure.
This structure can be accessed using the GetCurrentTdeCreateEvent() function.
After the execution of the current DDL command finishes, the end-ddl
function clears out this structure.
…on (#199)

* Introduces `pg_tde2` access method
* New access method uses the event trigger changes from #196
* Keys are now loaded from the keyring
* This required changes to the map file / master key infrastructure
* This commit only modifies/fixes those as little as required for simplicity.
  More refactoring/changes coming in separate commits / PRs
* Removes reliance from MyDatabaseId, as things now have to work with multiple databases in the checkpointer
* Removes some error reports, where functions should work even without a configured keyring
* Fixes some bugs in the map file functions
* Map file functions now work with multiple databases in a single process, but this is a hackish solution, global state needs a proper refactoring
* Contains anti-recursion hack in the new SMGR code, which is needed until we store the metadata in the catalog
With this commit, old pg_tde code should work as before in the
same branch, and CI tests also should pass.
* Make the *.map *.dat processing code aware of custom databases and
  table spaces
* Add XLog GUC and init the keyring based on that. Only FS for now
* Make the internal/external key infrastructure work with custom
  (not stored in the database) keyrings.
* Check and create an internal key for XLog during the server start.
If the key is created (not the first start with the EncryptWAL), then
upload it into the cache. We can't read the key from files while
writing the XLog to the disk as it happens in the critical section and
no palloc is allowed.

* Create a custom cache for the global catalog external key as we can't
use PG's hashmap during the (again, no pallocs in critical section).
During the server start, when pg_tde module is loading and it needs to
read *.map, *.dat file, InitFileAccess is yet to be called, hence Vfd
isn't ready to use. The same gonna happen during recovery. So use raw
pread/pwrite calls istead.
Add key management for WAL

Make the *.map *.dat processing code aware of custom databases and
table spaces

Add XLog GUC and init the keyring based on that. Only FS for now

Make the internal/external key infrastructure work with custom
(not stored in the database) keyrings.

Check and create an internal key for XLog during the server start.
If the key is created (not the first start with the EncryptWAL), then
upload it into the cache. We can't read the key from files while
writing the XLog to the disk as it happens in the critical section and
no palloc is allowed.

Create a custom cache for the global catalog external key as we can't
use PG's hashmap during the (again, no pallocs in critical section).

During the server start, when pg_tde module is loading and it needs to
read *.map, *.dat file, InitFileAccess is yet to be called, hence Vfd
isn't ready to use. The same gonna happen during recovery. So use raw
pread/pwrite calls istead.
@dutow dutow reopened this Jun 25, 2024
@dutow dutow merged commit 4312c48 into main Jun 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants