Announcement

Collapse
No announcement yet.

Linux 5.6 Is Looking Like It Will Be Spectacular With A Long List Of Features

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

  • C8292
    replied
    Originally posted by Neraxa View Post
    Filesystem related things on Linux have long been a mess, full of half assed solutions and disclaimers like "we know its broken, and we don't care", or, "you can't do it the way you want, you can only do it this way, even though it does not work well for you". For many users, having encryption done above the filesystem is far preferable, since encrypting everything at the block layer is overkill. Most people don't need /usr/bin encrypted. Talking about needless performance degradation. So the idea that this is the only well supported way to have encryption is retarded. A lot of people just want per directory encryption, and they want it to be secure, reliable and robust. Reading the documentation for the kernels ecryptfs solution gives you the impression that no one cares about it, and the kernel people don't like it that you are using it. and the idea that people should encrypt /usr/bin and everything is absurd. Encrypting at block layer is what many people do not want. But for no good reason, kernel people think you should have to encrypt everything at the block layer. There is no technical reason, encryption above filesystem can be perfectly robust, no excuses.
    Well.. actually with new self-encrypting SSDs and sedutil I solve many of these issues

    Leave a comment:


  • Flaburgan
    replied
    5.6 will also come with A64 motherboard support so the pinephone will be able to run on a vanilla kernel!

    Leave a comment:


  • cynical
    replied
    Full disk encryption overhead is not high. I think it’s a waste of time to complain about it. Either you don’t want any overhead, or you care enough about security to be fine trading some performance for it.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by -MacNuke- View Post
    Most people I know just encrypt everything. It's not like that you execute multiple gigabytes of binaries per second from /usr/bin on a daily basis.
    Is that a challenge?

    Leave a comment:


  • brent
    replied
    Originally posted by amdtesterman View Post

    there won't be any cppc support because Linux developpers want schedutil to be the only governor in Linux. They want to add the features of cppc to this governos. intel pstate was different because there was no plans to do this before. Correct me if it is not.
    That's pretty sad if it is true. It's not the first time that kernel development politics hinder progress. What's wrong with getting an AMD-specific CPPC2 implementation in now and later converging to a schedutil-based implementation that makes both intel_pstate and the AMD CPPC2 implementation obsolete?

    Perfect is the enemy of good.

    Leave a comment:


  • -MacNuke-
    replied
    Originally posted by Neraxa View Post
    Thats not a good solution for everyone. Partitions come with too many side effects, such as how they can create a disk usage structure that cannot be easily changed later, given that it can be difficult to predict from the outset how much each partition will need, you could end up wasting space or have space locked up in one partition as the other partition becomes full. So this can be a very messy set up. If you need really fined grained control over which directories should be encrypted, it can lead also to a mind boggling mess of mount points.
    And there is LVM which fixes most of these problems. Shrinking may be an issue depending on your filesystem but extending is pretty easy. Sure, one can always construct a scenario where there is a random problem but that works everywhere.
    Most people I know just encrypt everything. It's not like that you execute multiple gigabytes of binaries per second from /usr/bin on a daily basis.

    edit: And btw. only encrypting i.e. /home gives one a nice opportunity to single-user boot your PC and place a keylogger/trojan into /usr/bin. Since it is not encrypted it easily accessible.
    Last edited by -MacNuke-; 26 January 2020, 05:41 PM.

    Leave a comment:


  • anarki2
    replied
    Originally posted by Neraxa View Post
    Filesystem related things on Linux have long been a mess, full of half assed solutions and disclaimers like "we know its broken, and we don't care", or, "you can't do it the way you want, you can only do it this way, even though it does not work well for you". For many users, having encryption done above the filesystem is far preferable, since encrypting everything at the block layer is overkill. Most people don't need /usr/bin encrypted. Talking about needless performance degradation. So the idea that this is the only well supported way to have encryption is retarded. A lot of people just want per directory encryption, and they want it to be secure, reliable and robust. Reading the documentation for the kernels ecryptfs solution gives you the impression that no one cares about it, and the kernel people don't like it that you are using it. and the idea that people should encrypt /usr/bin and everything is absurd. Encrypting at block layer is what many people do not want. But for no good reason, kernel people think you should have to encrypt everything at the block layer. There is no technical reason, encryption above filesystem can be perfectly robust, no excuses.
    The problem with cherry-picking directories for encryption is that there's never a guarantee that your sensitive information will happen to be in those encrypted dirs. Especially when your developers DEMAND sudo rights, which they usually do. In which case the value of encryption on your cherry picked directories is exactly zero. When it comes to encryption, FDE is the only sane way to do it, otherwise it's a 50-50 in which case, why even bother.

    Have you actually measured the performance loss with LUKS? It's the same kind of sentiment as with SSL exceptions, because encrypting everything is sooo expensive. Like <1% these days. So why the hell would you risk it.

    ZFS is unfit for single disk scenarios (read: 95% of desktops), Btrfs is EOL'd on RHEL, eCryptfs is EOL'd, fscrypt is [email protected] at best (already ranted about it to great extent), so you really have no other option but LUKS. With Clevis TPM2 automatic unlock it's pretty decent, that's the setup we've been deploying for the past 2 months or so.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by Neraxa View Post

    Thats not a good solution for everyone. Partitions come with too many side effects, such as how they can create a disk usage structure that cannot be easily changed later, given that it can be difficult to predict from the outset how much each partition will need, you could end up wasting space or have space locked up in one partition as the other partition becomes full. So this can be a very messy set up. If you need really fined grained control over which directories should be encrypted, it can lead also to a mind boggling mess of mount points.
    That's literally why I stated using ZFS. I know I'm not the only one who partiton-fucked themselves once or twice over the years. I was reading about it and went, hold up, so you're telling me that something with the benefits of LVM without the downside of known partition sizes actually exists? Sign me up.

    But if I could only shrink and move my XFS /home over ....is a phrase I will never say again

    Leave a comment:


  • CochainComplex
    replied
    Originally posted by Neraxa View Post

    Thats not a good solution for everyone. Partitions come with too many side effects, such as how they can create a disk usage structure that cannot be easily changed later, given that it can be difficult to predict from the outset how much each partition will need, you could end up wasting space or have space locked up in one partition as the other partition becomes full. So this can be a very messy set up. If you need really fined grained control over which directories should be encrypted, it can lead also to a mind boggling mess of mount points.
    how about https://btrfs.wiki.kernel.org/index....ide#Subvolumes

    Leave a comment:


  • amdtesterman
    replied
    Originally posted by narciso View Post
    No AMD Zen2 CPPC support yet?
    there won't be any cppc support because Linux developpers want schedutil to be the only governor in Linux. They want to add the features of cppc to this governos. intel pstate was different because there was no plans to do this before. Correct me if it is not.
    Other thing, it is not only for zen 2, it is too for zen cpu's , Michael had an error there and there is no correction yet in that thread I think.

    Leave a comment:

Working...
X