Posts by sky42

    The Team LibreELEC did give me space on there server, so that you now find my latest releases under http://sky42.libreelec.tv/. But there will only be the last 1 or 2, so that i not use so much space.

    I did change the version numbers:

    1.42.x -> 1.x with Custom Update Channel LibreELEC-8.x-sky42-1.x

    3.42.x -> 3.x with Custom Update Channel LibreELEC-8.x-sky42-3.x

    6.42.x -> 6.x with Custom Update Channel LibreELEC-8.x-sky42-6.x

    7.42.x -> 6.x with Custom Update Channel LibreELEC-8.x-sky42-7.x

    Now you can use Custom Update Channel in LE Settings

    - set Automatic Updates manual

    - enable Show Custom Channels

    - change Custom Channel 2 to http://sky42.libreelec.tv/ or for just 8.x channels http://sky42.libreelec.tv/release/.8/

    - choose a Update Channel LibreELEC-8.x-sky42-Y.x where Y is the 8.2.5-Y.42.z version you use so far

    - and now use Available Versions and choose

    the new places for download

    http://sky42.libreelec.tv/release/8.2/

    HiDrive mirror

    And to see the size difference here some ls with my LE master version 1725942 patched with all the crypto stuff and 8.90.004 which was not build by my, but as far as i can tel that is LE master 1725942.

    kernel

    sky42@howcome:/zfs/sky42/libreelec/sky42$ ls -lg 9.0/*/*.kernel 8.90.004/*/KERNEL

    -rw-r--r-- 1 sky42 16007536 Aug 31 17:05 8.90.004/Generic/KERNEL

    -rw-r--r-- 1 sky42 7231208 Aug 31 13:21 8.90.004/RPi2/KERNEL

    -rw-r--r-- 1 sky42 7066200 Aug 31 14:29 8.90.004/RPi/KERNEL

    -rw-r--r-- 1 sky42 16019824 Sep 1 07:49 9.0/Generic/LibreELEC-Generic.x86_64-9.0-devel-20180901074840-1725942.kernel

    -rw-r--r-- 1 sky42 7230464 Sep 1 07:26 9.0/RPi2/LibreELEC-RPi2.arm-9.0-devel-20180901072539-1725942.kernel

    -rw-r--r-- 1 sky42 7070584 Sep 1 07:24 9.0/RPi/LibreELEC-RPi.arm-9.0-devel-20180901072412-1725942.kernel

    -rw-r--r-- 1 sky42 7230872 Sep 1 07:28 9.0/Slice3/LibreELEC-Slice3.arm-9.0-devel-20180901072730-1725942.kernel

    -rw-r--r-- 1 sky42 7069736 Sep 1 07:29 9.0/Slice/LibreELEC-Slice.arm-9.0-devel-20180901072847-1725942.kernel

    system

    sky42@howcome:/zfs/sky42/libreelec/sky42$ ls -lg 9.0/*/*.system 8.90.004/*/SYSTEM

    -rw-r--r-- 1 sky42 235331584 Aug 31 17:05 8.90.004/Generic/SYSTEM

    -rw-r--r-- 1 sky42 138616832 Aug 31 13:21 8.90.004/RPi2/SYSTEM

    -rw-r--r-- 1 sky42 138149888 Aug 31 14:29 8.90.004/RPi/SYSTEM

    -rw-r--r-- 1 sky42 235986944 Sep 1 07:49 9.0/Generic/LibreELEC-Generic.x86_64-9.0-devel-20180901074840-1725942.system

    -rw-r--r-- 1 sky42 139218944 Sep 1 07:26 9.0/RPi2/LibreELEC-RPi2.arm-9.0-devel-20180901072539-1725942.system

    -rw-r--r-- 1 sky42 138743808 Sep 1 07:25 9.0/RPi/LibreELEC-RPi.arm-9.0-devel-20180901072412-1725942.system

    -rw-r--r-- 1 sky42 139358208 Sep 1 07:28 9.0/Slice3/LibreELEC-Slice3.arm-9.0-devel-20180901072730-1725942.system

    -rw-r--r-- 1 sky42 138891264 Sep 1 07:29 9.0/Slice/LibreELEC-Slice.arm-9.0-devel-20180901072847-1725942.system

    No i did some testing with my new builds and here are the results for hardware accelerated AES.

    The 0901-luks version is with all usable hardware acceleration on and 0901-noni is the same just hardware acceleration swited of in the kernel.

    short version:


    TL;DR

    full output of the tests

    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