Posts by sky42

    Why should there be hardware acceleration and more crypto moduls in the kernel:

    Hardware acceleration with AES-NI is 6-8 times faster. That is the case for many things like https, other SSL connections, SSH and also disk encryption. The kernel encryption/decryption implemetation is faster than just userspace software, becasue it is more optimized and using even hardware acceleration if possible, when you enable optimization/acceleration.

    When the kenrel supports a more complete set of encryption, than the community is able to build addons that are using/needing the kernel crypto support.

    Why would some one use disk encryption:

    There are at least 2 reasons.

    One is encryption at rest, so that data on the disk are encrypted and you can throw it away without thinking about the data. For HDDs you can overwrite them, when they are still working, but failed HDDs have still data and you can not properly delete them. The seconds case can be solved with a degausser, but thats about $ 20.000 (i bought 2 at work). For SSDs proper deleting through overwriting is not really possible, because of wearleveling technics of the SSD controller you will never reach all flash cells.

    The 2nd one is protecting your data, because you dont want somebody to access them. But these data are only cold secure, that means if it is swicthed off nobody can access it without your password or key. I see that used more and more for portable data devices (HDD, SSD, USB Stick). Also Android does encrypt the user data by default since Android 6, when you setup a PIN or password. iPhones doing that a lot longer.


    I propose to add more support for encryption and dm-crypt in the kernel. Encryption will be faster for e.g https and the community can build addons based on that.

    I would also like to include cryptsetup in LE, so that it is possible to use encrypted block devices. If cryptsetup is not included i can still build a addon, when the dm-crypt kernel support is included.

    With cryptsetup it is possible to use luks, loopaes, veracrypt, truecrypt encrypted devices. A veracrypt USB disc needs to be first open by cryptsetup and then you could normal mount e.g. a ntfs filesystem. There is no GUI for that in my proposal. I am not the right person to build a GUI portion for that, but with the kernel support and cryptsetup it is poosible to build a addon for that.


    The kernel image is growing about 16KB on Generic x86_64 and the system image about 1.5MB (cryptsetup included).

    I have now (finally) my own github account with a forked LibreELEC repo and created Pull Requests for the features, but so far only in my own repo.

    For cryptsetup and dependencies:

    PKG add cryptsetup, lvm2-minimal, config-md by sky42src · Pull Request #5 · sky42src/LibreELEC.tv · GitHub

    and this wil only be build if the kernel supports CONFIG_DM_CRYPT. The next 3 PR will do that.

    For the kernel modules i have covered 3 projects so far:

    linux (Generic): add more crypto modules + dm-crypt by sky42src · Pull Request #6 · sky42src/LibreELEC.tv · GitHub

    linux (RPi): add more crypto modules + dm-crypt by sky42src · Pull Request #7 · sky42src/LibreELEC.tv · GitHub

    linux (Amlogic): add more crypto modules + dm-crypt by sky42src · Pull Request #8 · sky42src/LibreELEC.tv · GitHub

    I am happy to provide patches for the other architectures. On Generic/RPi2 i use this every day (my LE userdata is encrypted).

    If somebody wants to try, you will find my builds here HiDrive and in the noni subfolder is a version without crypto hardware acceleration. The easiest way to test ist "cryptsetup benchmark --cipher aes-xts" with and with out hw acceleration. I will also add the pure le master, so that you can see the size difference and this will be in the orig subfolder.

    Thanks for reading and hopefully considering it

    sky42

    Iridium

    Thanks for the advice. I did think about it some time. Now i have done some more tests and minimized my patches. I also write a application, but still not sure about the new Subject "kernel support for encryption + adding dm-crypt" for a new thread i will open.

    Here is my draft:

    ------------------------------

    Why should there be hardware acceleration and more crypto moduls in the kernel:

    Hardware acceleration with AES-NI is 6-8 times faster. That is the case for many things like https, other SSL connections, SSH and also disk encryption. The kernel encryption/decryption implemetation is faster than just userspace software, becasue it is more optimized and using even hardware acceleration if possible, when you enable optimization/acceleration.

    When the kenrel supports a more complete set of encryption, than the community is able to build addons that are using/needing the kernel crypto support.

    Why would some one use disk encryption:

    There are at least 2 reasons.

    One is encryption at rest, so that data on the disk are encrypted and you can throw it away without thinking about the data. For HDDs you can overwrite them, when they are still working, but failed HDDs have still data and you can not properly delete them. The seconds case can be solved with a degausser, but thats about $ 20.000 (i bought 2 at work). For SSDs proper deleting through overwriting is not really possible, because of wearleveling technics of the SSD controller you will never reach all flash cells.

    The 2nd one is protecting your data, because you dont want somebody to access them. But these data are only cold secure, that means if it is swicthed off nobody can access it without your password or key. I see that used more and more for portable data devices (HDD, SSD, USB Stick). Also Android does encrypt the user data by default since Android 6, when you setup a PIN or password. iPhones doing that a lot longer.


    I propose to add a more support for encryption and dm-crypt in the kernel. Encryption will be faster for e.g https and the community can build addons based on that.

    I would also like to include cryptsetup in LE, so that it is possible to use encrypted block devices. If cryptsetup is not included i can still build a addon, when the dm-crypt kernel support is included.

    With cryptsetup it is possible to use luks, loopaes, veracrypt, truecrypt encrypted devices. A veracrypt USB disc needs to be first open by cryptsetup and then you could normal mount e.g. a ntfs filesystem. There is no GUI for that in my proposal. I am not the right person to build a GUI portion for that, but with the kernel support and cryptsetup it is poosible to build a addon for that.


    The kernel image is growing about 16KB on Generic x86_64 and the system image about 1.5MB (cryptsetup included).

    here is my patch for Generic x86_64

    kernel support for encryption and adding dm-crypt

    sky42-kernel-config-Generic-x86_64-encryption-4.18-v2.patch.txt

    cryptsetup package.mk and depedencies lvm2-minimal

    cryptsetup-package.mk.txt

    lvm2-minimal-package.mk.txt


    I am happy to provide patches for all the other architectures. With RPi2 and Wetek_Play i already did this a while ago. On Generic x86_64 i use this every day (my LE userdata is encrypted).


    Thanks for reading and hopefully considering it

    sky42


    ------------------------------

    some updates ... what was done:


    special Spectre/Meltdown update with protection up too Foreshadow L1TF from 3 days ago

    checker v39+ from here GitHub - speed47/spectre-meltdown-checker: Spectre & Meltdown vulnerability/mitigation checker for Linux

    and if you are into details how to protect read here L1TF - L1 Terminal Fault — The Linux Kernel documentation

    and some more insides here L1TF - L1 Terminal Fault Attack - CVE-2018-3620 & CVE-2018-3646 - Red Hat Customer Portal


    8.2.5-3.42.3-4.14.63 in Generic here HiDrive

    - kernel 4.14.63

    8.2.5-6.42.3-4.18.1 in Generic here HiDrive

    - kernel 4.18.1

    8.2.5-7.42.3-4.18.1 in Generic here HiDrive

    - kernel 4.18.1

    And to see what is possible on resolution and fps you can use "xranr".

    For me it looks like

    On the DP1 is a active DP 1.2 Adapter to HDMI 2.0 and the HDMI1 port is connected to my AVR just for audio

    careful the next 2 i have just compiled, but no tests so far

    some updates ... what was done (just the changes):


    8.2.5-6.42.3-4.18 in Generic here HiDrive

    - clean build, but no testing so far

    - kernel 4.18 with config from milhouse PR2880

    - backported linux (Generic): update to linux-4.18 by MilhouseVH · Pull Request #2880 · LibreELEC/LibreELEC.tv · GitHub

    - new kernel-firmware from LE master

    - xorg-server pci_id patch update from 1.20.1

    8.2.5-7.42.3-4.18 in Generic here HiDrive

    - clean build, but no testing so far

    - exactly like 6.42.3-4.18

    plus

    - LLVM 6.0.0

    - Mesa 3D 18.1.6


    rene12345

    2 new versions to test if you like.

    The NUC has the latest BIOS and is there also HDMI Firmeware (like the older ones)? The last thing i would test is BIOS settings UEFI only with no CSM (my i3-8100 is running that way) or the last one no UEFI at all, after that i would become desperate and try windows 10 to see if it is doing 4k 60 Hz at all.

    That is kind of tricky. All 3 components need to do the right thing. 4k UHD does not mean also with 60Hz. Look in the specs of you TV and AVR (deep). The NUC is capable of doing it, but there could be a firmware problem in all of the 3.

    Look here (with ssh on the NUC) "less /sys/kernel/debug/dri/0/i915_display_info" and you see what the GPUs is willing to do with the connected hardware. Also try direct connect to the TV and look again. If that works connect the second HDMI to the AVR just for audio. My setup works that way with a i3-8100, because my Onkyo 818 AVR does not do 4k, but my LG TV 55E6D does. Sometimes it is one of the HDMI cables, but just some times when they are old. My Onkyo as a example can scale up to 4k on the Output, but HDMI Inputs are only capable of Full HD 1920x1080.

    some updates ... what was done:


    8.2.5-3.42.3-4.14.61 in Generic, RPi2 here HiDrive

    - kernel 4.14.61

    - synced RPi2 kernel patches from LE master 4.14.54

    - removed ir-mce_kbd-decoder.c patches, now in upstream kernel 4.14

    - added wpa_supplicant: Fix EAPOL vulnerability [backport] by MilhouseVH · Pull Request #2874 · LibreELEC/LibreELEC.tv · GitHub

    - update Intel Microcodes to 20180807 Spectre/Meltdown protection up to v3a/4 (at least for my i3-4010U)

    - update Nvidia driver to 390.77


    8.2.5-6.42.3-4.17.14 in Generic here HiDrive

    - full release post #123 (plus following lines)

    - kernel 4.17.14

    - synced kernel config from LE master 4.17.6

    - updated improve-ir-timeout-handling patch from LE master 4.17.6

    - removed ir-mce_kbd-decoder.c patches, now in upstream kernel since 4.17.12

    - Gemini Lake GLK HDMI bugfix now v5 in upstream kernel since 4.17.12 (v4 patch removed)

    - added wpa_supplicant: Fix EAPOL vulnerability [backport] by MilhouseVH · Pull Request #2874 · LibreELEC/LibreELEC.tv · GitHub

    - update Intel Microcodes to 20180807 Spectre/Meltdown protection up to v3a/4 (at least for my i3-8100)

    - update Nvidia driver to 390.77

    some updates ... what was done:

    No more builds with 4.16, because it is now EOL.

    Edited 1st post: removed 5.42, removing lvm2/mdadm announced, 6.42 now with kernel 4.17, removed Xin1 versions


    8.2.5-6.42.3-4.17.2 in Generic here HiDrive

    - just build new images from testing version 8.2.5-6.42.3-201806171607-4.17.2 (for 14 days running fine on my coffee lake)

    - full release post #123


    8.2.5-6.42.3-4.17.3 in Generic here HiDrive

    - just kernel bump

    infoalter

    Thanks and you are welcome, but you are in the wrong thread.

    tomtomclub

    My 8.2.5 is not dead, but stable for the moment :) I will release a 6.42 with autofix for Gemini lake HDMI patch, there is already a test version since 12 days.

    My 9.0-devel is in deed dead, because Milhouse builds are now with 4.17, Gemini lake hdmi autofix and amd support. So no reason for me to continue.