Package Details: sedutil 1.20.0-3

Git Clone URL: https://aur.archlinux.org/sedutil.git (read-only, click to copy)
Package Base: sedutil
Description: TCG OPAL 2.00 SED Management Program
Upstream URL: https://github.com/Drive-Trust-Alliance/sedutil
Licenses: GPL3
Submitter: R00KIE
Maintainer: R00KIE
Last Packager: R00KIE
Votes: 42
Popularity: 0.036433
First Submitted: 2015-10-18 14:02 (UTC)
Last Updated: 2023-06-03 18:38 (UTC)

Dependencies (7)

Required by (0)

Sources (12)

Pinned Comments

R00KIE commented on 2016-08-27 21:39 (UTC)

To build this package you need to install one of the following: linux-headers: if you are using Arch's kernel linux-lts-headers: if you are using Arch's LTS kernel

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

darkbasic commented on 2016-12-13 17:36 (UTC) (edited on 2016-12-13 17:38 (UTC) by darkbasic)

Yes, it makes perfectly sense being able to move the device to an older machine, good point. Completely forgot about EFI stub, I will have a look at what I can achieve with secure boot. By the way, did you experience any issue with EFI entries? If I create an EFI entry and then I lock the SSD turning the power off, then the entry disappears, probably because the BIOS can't find the partition anymore (but the EFI entry still exists in efibootmgr). After unlocking the SSD through the shadow MBR I expected the BIOS to show the EFI entry once again, but it doesn't happen on my Dell XPS 13 9343 BIOS A09. Am I the only one with this issue? Currently I'm booting using the default entry only.

R00KIE commented on 2016-12-13 16:56 (UTC)

For me it makes sense to support both bios and uefi because I still have machines that are bios only and those can be used in case my main machine breaks down (this has been useful to me in a very recent past). There might also be interest for people with older machines that don't support aes-ni but still want to use encryption, by using a sed that comes without performance penalty. Regarding secure boot, I haven't looked much into it yet. You can use more than one method of whitelisting your bootloader, from what I've seen you can use either hashes or signatures so I'd like to give the alternatives a try myself before releasing anything half baked and can provide some pointers for other people. Cryptboot seems like a nice helper to deal with secure boot, I haven't taken too long looking at it but it seems a bit geared towards grub, I'd rather have the PBA image be as generic as possible, what people do/use after the disk is unlocked should not be my concern (less risk of bugs or borking things). There is also the fact that if you are using a uefi machine you don't need a bootloader, you can boot the kernel directly[1], which I have been doing and so far it works well. In this case I suppose you only need to sign your kernel image before you create the PBA image or include the hash in the whilelist, but like I said before I haven't tested it yet. [1] https://wiki.archlinux.org/index.php/EFISTUB

darkbasic commented on 2016-12-13 16:26 (UTC) (edited on 2016-12-13 16:26 (UTC) by darkbasic)

That makes sense, I thought about creating an hybrid image but from my point of view it wasn't worth the additional effort because we really want secure boot support anyway, possibly using something like cryptboot[1] to sign the image. I still didn't implement secure boot in my helper because I still have to figure out the best way to accomplish it, especially if I really want to use something like cryptboot. Any idea? [1]https://github.com/xmikos/cryptboot

R00KIE commented on 2016-12-13 14:01 (UTC)

@darkbasic I'll include your first patch to unbreak building (again) until upstream fixes the problem[1]. In Arch we don't have linux versions below 4.4 so we don't really need the conditionals but I'll include it as is as most probably that is what upstream will use. Regarding the uefi image creation script, I have been working on a new script which will create hybrid images (bios+uefi) and I'm planning to move away from separate scripts for bios and uefi which means I will not use your script, but I thank you for taking the time to implement and test it, I can serve as an alternative/reference for other people. I'm also planning to move the sources to github, I have been contacted by email regarding that and I'll probably do it after upstream releases a new version, for now I'll just push my changes and fix building. [1] https://github.com/Drive-Trust-Alliance/sedutil/pull/56#issuecomment-263739472

darkbasic commented on 2016-12-12 23:44 (UTC)

I created an helper to make the PBA image with EFI support, please add it to the pkgbuild as mklinuxpba-efi: https://paste.pound-python.org/show/1mka8Z0H4v7iDHdNkg0V/

darkbasic commented on 2016-12-12 13:16 (UTC) (edited on 2016-12-12 13:16 (UTC) by darkbasic)

To fix the issue I removed your patch and added this one: https://github.com/bcarmo-caio/sedutil/commit/5ca6100917a025f6e11ae20838e1e37e7db2d587.patch Now it compiles flawlessly.

darkbasic commented on 2016-12-12 13:09 (UTC)

g++ -m64 -Wall -D_FORTIFY_SOURCE=2 -O2 -c -Werror -I.. -I../../Common -I../../Common/pbdkf2 -std=c++11 -MMD -MP -MF "build/Release_x86_64/GNU-Linux/_ext/5c0/DtaDevOS.o.d" -o build/Release_x86_64/GNU-Linux/_ext/5c0/DtaDevOS.o ../DtaDevOS.cpp In file included from ../DtaDevLinuxNvme.h:21:0, from ../DtaDevLinuxNvme.cpp:33: /usr/lib/modules/4.8.13-1-ARCH/build/include/linux/nvme.h: In function ‘bool nvme_is_write(nvme_command*)’: /usr/lib/modules/4.8.13-1-ARCH/build/include/linux/nvme.h:858:57: error: ‘unlikely’ was not declared in this scope if (unlikely(cmd->common.opcode == nvme_fabrics_command)) ^ make[2]: *** [nbproject/Makefile-Release_x86_64.mk:184: build/Release_x86_64/GNU-Linux/_ext/5c0/DtaDevLinuxNvme.o] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from ../DtaDevLinuxNvme.h:21:0, from ../DtaDevOS.cpp:36: /usr/lib/modules/4.8.13-1-ARCH/build/include/linux/nvme.h: In function ‘bool nvme_is_write(nvme_command*)’: /usr/lib/modules/4.8.13-1-ARCH/build/include/linux/nvme.h:858:57: error: ‘unlikely’ was not declared in this scope if (unlikely(cmd->common.opcode == nvme_fabrics_command)) ^ make[2]: *** [nbproject/Makefile-Release_x86_64.mk:194: build/Release_x86_64/GNU-Linux/_ext/5c0/DtaDevOS.o] Error 1 make[2]: Leaving directory '/tmp/yaourt-tmp-niko/aur-sedutil/src/sedutil-1.12/linux/CLI' make[1]: *** [nbproject/Makefile-Release_x86_64.mk:80: .build-conf] Error 2 make[1]: Leaving directory '/tmp/yaourt-tmp-niko/aur-sedutil/src/sedutil-1.12/linux/CLI' make: *** [nbproject/Makefile-impl.mk:40: .build-impl] Error 2 linux-headers is installed.

R00KIE commented on 2016-08-27 21:39 (UTC)

To build this package you need to install one of the following: linux-headers: if you are using Arch's kernel linux-lts-headers: if you are using Arch's LTS kernel

R00KIE commented on 2016-08-27 21:37 (UTC) (edited on 2016-12-13 14:02 (UTC) by R00KIE)

@jarondl I was looking into this and I haven't found yet a way to makedepend on either linux-headers or linux-lts-headers. Those are the headers packages for the two kernels in [core], so making it a hard dependency on either of them is not right. For now I'll make a comment sticky warning that one of them needs to be installed.

jarondl commented on 2016-08-21 01:03 (UTC)

Hi, Could you add a dependency on linux-headers? Thanks

« First ‹ Previous 1 2 3 4 Next › Last »