• 0 Posts
  • 186 Comments
Joined 2 years ago
cake
Cake day: June 18th, 2023

help-circle


  • Fabric with some performance-enhancing mods is a great choice as well, yes! I’ve been wanting to test it on my server for a while now, just haven’t got around to it yet.

    Paper changes some of the more quirky vanilla redstone behavior, although - again - it’s very configurable so some of that original behavior can be restored.

    I’d mostly base it on which plugin/mod ecosystem you prefer/require.


  • World simulation (ticks) is single-threaded, but things like world generation are multithreaded. I’d recommend Paper as server software as it’s more performant out of the box (vs. vanilla) and configurable (ex. how many threads world generation is allowed to use).

    If you host multiple worlds I recommend spinning up a Paper instance for each world separately and connect them with Velocity.

    Ryzen 7000 should have better single-threaded performance than your i5-9500 but as it’s a VM ymmv depending on whether Sparked Host overprovisions their machines.












  • It doesn’t already have to be running. BitLocker retrieves its keys from TPM by default, so just booting a device will place the keys in memory.

    To minimize downtime, abruptly restart the target system during the Windows boot process, specifically before the login screen appears, as this approach has proven effective in scenarios involving the retrieval of Full Volume Encryption Keys (FVEKs).

    By kernel-level debugging with WinDbg, the researcher observed BitLocker operations during the Windows boot process, which revealed that while Microsoft attempts to erase encryption keys using functions like SymCryptSessionDestroy, some keys persist on the heap, potentially due to incomplete key destruction mechanisms.


  • Is this really a BitLocker issue or more an issue inherent in the hardware design?

    EDIT: Okay, looks like Microsoft could do better:

    By kernel-level debugging with WinDbg, the researcher observed BitLocker operations during the Windows boot process, which revealed that while Microsoft attempts to erase encryption keys using functions like SymCryptSessionDestroy, some keys persist on the heap, potentially due to incomplete key destruction mechanisms.

    But maybe the hardware/UEFI should immediately wipe memory upon restarting anyway…?