Announcement

Collapse
No announcement yet.

Archinstall 2.5.1 Released With A Number Of Fixes For The Arch Linux Installer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Torxed View Post

    I don't think manufacturers need to do anything. The EFI binary could be arch developed (as an example), and as long as it has support for the DMCrypt logic (unlocking and dealing with everything) I suppose it could load the initramfs from the encrypted volume. But the limiting factor might be the actual size of the EFI storage on the motherboard if the encryption logic gets too big.
    Cool, I guess I'm not so firm with UEFIs inner workings.

    I have no idea how the memory handling of the EFI binaries are done tho, so there might be some limiting factors here making it impossible. As I suspect it can't utilize the full RAM at this stage.
    And for Argon2 it would need quite a lot, I typically use 6GB as that is my lowest anchor of all systems (actually 8GB but there needs to be a safety margin).

    LVM still happens inside. But I've seen people do LVM outside and encryption inside too, but I doubt that this is something a majority of people do?
    For maximum security you would want to have everything inside the LUKS container, as soon as you start to put layers outside the posibillity of information leaking out start to arise. For example LVM -> LUKS might leak when and where data was edited and give you clues about the encrypted system. That also holds true for mdadm/Raid. Still one would have to leverage a securtiy hole in the encryption algorithm and write a attack script. But if you know the position of a known file than you can break atleast AES, see March 2016: https://en.wikipedia.org/wiki/Advanc...#Known_attacks I'm not sure if Argon2 helps against this.

    All this needs regular inspection of the disk from someone with physical access, that isn't a usable vulnerability in my case, they could hit me with a wrech or install a keylogger while I'm not at home.

    Comment


    • #12
      Originally posted by elatllat View Post
      lvm can do mdadm things so using both is ugly.​
      Those sneaky bastards implemented raid an told no one? In that case LVM would also be left outside the LUKS container to not encode parity. You might need a second LVM inside LUKS for partioning or have multiple LUKS devices.

      Do you have any experience with LVM Raid? Changing discs, repairing, rebuilding? Is there a big player out there using it?

      Comment


      • #13
        Originally posted by Anux View Post
        ...
        The only issues I have with a stratis like stack is lvm snapshots are ugly and integritysetup was slow to format.
        But there is lvmcache which mdadm and btrfs do not have.
        I think big implementations do custom things like backblaze or use distributed systems like ceph.
        After ~15 years of LVM RAID use I moved 1 production array to btrfs RAID, as CoW is not really ideal for databases.

        [integritysetup/]cryptsetup/lvm is commonly used as there is no performance penalty, no practical use case for per LV crypo, and per LV integrity make no sense.

        Comment

        Working...
        X