LWN: Comments on "memfd_secret() in 5.14"

memfd_secret() in 5.14

alopatindev — Sun, 22 Aug 2021 11:28:39 +0000

I'll clarify what I mean by potential "stability issues" in case of implementing the signalling idea: suppose that process reads the global flag and acknowledges that it can read/write the protected memory. But just before it starts reading/writing, the flag gets updated and now the process crashes after attempting to read/write.

I guess there's no way to guarantee process stability with this design. Is that right?

memfd_secret() in 5.14

alopatindev — Sat, 21 Aug 2021 13:44:22 +0000

> Protected memory is realistically going to be used for stuff like encryption keys, so it's unlikely that it's going to make any measurable impact on OOM.

I was thinking the same, thanks for clarification!

> Typically in a multithreaded app you will have a slim signal handler that sets some kind of a global flag that is processed "soon" by whatever thread that cares about it.

Cool but I worry about this "soon". Are there any risks for (multithreaded) app devs with this solution, that they might run into some stability issues that are hard to debug?

How about this approach:
- add some flag (or more likely some sync primitive) in the kernel that allows reading/writing to the protected memory by a process (the flag is controlled by some additional syscall for instance)
- when the flag is set — the kernel is disallowed to hibernate (the hibernation will be postponed until all such flags are reset)
- when the flag is reset — the app is disallowed to write to the protected memory (it will always get SIGBUS in this case)
- when all the flags are reset by all processes and the hibernation is started, since the processes are suspended, all the protected memories become allowed to be written by the kernel (but not to be read!), the memories will be zeroed out (by the kernel) and released and the flags will no longer be allowed to set (syscall will return error)
- as soon as apps wake up and they try to set the flag — they get errors, so they fully release the protected memory and call memfd_secret again.

Perhaps this would solve this hibernation without sacrificing security and apps stability at the same time?

What do you think: is that feasible and will it really improve anything for app devs? Thanks.

memfd_secret() in 5.14

Cyberax — Sat, 21 Aug 2021 01:17:02 +0000

> I like this idea. I wonder how multithreaded app should handle this signal though. Which thread is supposed to handle the signal: the main one, the random one, all of them?

Typically in a multithreaded app you will have a slim signal handler that sets some kind of a global flag that is processed "soon" by whatever thread that cares about it.

> Another question: do I understand correctly that the protected memory can't even be written to swap in case if the system is about to run OOM? (Or else I guess it would not make much sense to disable just hibernation, without disabling ordinary swapping).

Protected memory is realistically going to be used for stuff like encryption keys, so it's unlikely that it's going to make any measurable impact on OOM.

memfd_secret() in 5.14

HenrikH — Sat, 21 Aug 2021 00:24:30 +0000

How can the salary be both "the same" and "2x-3x less" at the same time?

memfd_secret() in 5.14

alopatindev — Sat, 21 Aug 2021 00:22:43 +0000

> send a signal to prepare the app for impending shutdown and/or after the restore

I like this idea. I wonder how multithreaded app should handle this signal though. Which thread is supposed to handle the signal: the main one, the random one, all of them?

Another question: do I understand correctly that the protected memory can't even be written to swap in case if the system is about to run OOM? (Or else I guess it would not make much sense to disable just hibernation, without disabling ordinary swapping).

And another completely unrelated idea: how about (at least optionally) zeroing protected memory (by kernel) before completely releasing it? I know that apps suppose to do that, but it's so easy to implement it incorrectly, that I personally would be happy if kernel simply would not allow to leak incorrectly released memory with sensitive data.

memfd_secret() in 5.14

jhartzell42 — Fri, 20 Aug 2021 23:42:13 +0000

I think that features useful for servers and completely useless for laptop users are ... still useful for server users, and can proceed without damaging laptop users, who will simply ... not use those features. Why should the laptop use case hold the server use case back? Why are server-only features a waste of time in your book?

memfd_secret() in 5.14

ncm — Fri, 20 Aug 2021 07:14:50 +0000

Far be it from me to agree with Cyberax, he is actually correct here. It is always permissible for an app to die while waking up from hibernation if its state cannot be restored and it cannot cope with that. I do not expect my ssh sessions to survive hibernation, and would expect ssh-agent to forget its keys.

If such an app has some way not to shut down, but to ask for its secrets to be restored instead, and continue, that might be better sometimes. But in no case does a need to clear secrets first mean hibernation must be disabled.

memfd_secret() in 5.14

NYKevin — Tue, 10 Aug 2021 08:59:45 +0000

Secure boot checks the signature on the thing that receives control from UEFI (e.g. GRUB). It doesn't know or care about the fact that GRUB hands control over to the Linux kernel, much less what RAM image the Linux kernel subsequently decides to load up.

Otherwise, this chain of attestation would never end. You'd have to sign the kernel, and systemd, and GNOME, and Firefox, and...

memfd_secret() in 5.14

NYKevin — Tue, 10 Aug 2021 08:53:46 +0000

> which is relatively easy to bypass

Well... I don't know about that. You have to have arbitrary kernelspace code execution, which is supposed to be impossible even for root (assuming, for the sake of argument, that the kernel has been locked down and won't load arbitrary modules). If that is "relatively easy," then it means you have found a serious security vulnerability, regardless of whether memfd_secret() is in use or not, and regardless of whether the attacker is root or not.

In particular, this syscall defends against "simple" buffer overreads where the kernel is tricked into copying a bunch of random kernel-visible memory into an attacker-visible buffer, but without arbitrary code execution. That is also supposed to be impossible, of course, but constructing an overread attack is probably easier than constructing an ACE attack. In this sense, then, it can be thought of as a form of defense in depth, where we try to make attacks more difficult to construct, rather than trying to provide absolute guarantees of security.

memfd_secret() in 5.14

pabs — Tue, 10 Aug 2021 01:51:11 +0000

Hmm, I wonder how the kernel knows the hibernation image is trustworthy. Normally that requires a trust chain from Microsoft to the thing being loaded, but with hibernation there can be none since only code running on the machine can sign the hibernation image.

memfd_secret() in 5.14

calumapplepie — Tue, 10 Aug 2021 01:34:56 +0000

Nope. Works like a charm.

Bit finnicky, though. You might remember me, I was talking about running a kernel bisect in #debian-next for a while, to figure out when hibernate-to-swapfile broke. Of course, while I was testing kernels to see where I should put the bisection bounds, it magically started working. On every one of the QEMU images I had created, including the ones that I had just found to not work.

Of course, when was the last time you read a story with charms that were completely explained, logical, and infallible? Sounds like a boring story to me, and I sure am glad that hibernation isn't like that!

memfd_secret() in 5.14

Cyberax — Tue, 10 Aug 2021 00:47:50 +0000

It'll be useful for VPN session keys, access tokens for hardware TPMs, session cookies for sudo and other similar ephemeral but important credentials.

memfd_secret() in 5.14

jhoblitt — Mon, 09 Aug 2021 23:18:33 +0000

`memfd_secret()` seems to be trying to do the impossible and project the memory of a process from the kernel in software. It is not a replacement for a TEE but in fairness would be much easier to use. For the specific case of DRM, which is trying allow a 3rd party to restrict the functionality of an end-users device to prevent copying, it is completely unsuitable. (This is also ignoring the fundamental flaw of DRM in that data has be unencrypted somewhere to be displayed and will always be vulnerable to copying.) A loadable module should be able to find and remap the pages to allow them to be dumped. The system call could equally be modified to copy the data or simply remap it to `memfd_create()`.

DRM isn't a use case I think the kernel should bother to accommodate. I'm much more interested in functionality that protects "my" private keys. A good test would be how is luks, gpg/gpg-agent, ssh-agent, openssl, etc. going to use this?

memfd_secret() in 5.14

excors — Mon, 09 Aug 2021 22:18:43 +0000

> Keystore does offer certain protections and may, probably, make sure you can't talk to Netflix directly, but it can not ensure that uncompressed video wouldn't be accessible to the rest of the system. memfd_secret can offer such ability.

The TEE can (and does) do that - the decrypted bitstream and the decoded pixels are stored in RAM that's made inaccessible to the kernel, and the GPU won't render those pixels onto a kernel-accessible buffer or send them to a display that's not protected by HDCP etc. Since that hardware support already exists and seems to be quite widespread on Android, it would be a step backwards to start relying on the kernel to enforce the security boundary.

memfd_secret() in 5.14

khim — Mon, 09 Aug 2021 21:41:00 +0000

> Because existing feature doesn't provide the same level of protection?

Keystore does offer certain protections and may, probably, make sure you can't talk to Netflix directly, but it can not ensure that uncompressed video wouldn't be accessible to the rest of the system. memfd_secret can offer such ability.

And widevine doesn't come with apps in Android world, rather, it's something your device vendor provides. Thus the fact that old devices don't have it is not a big deal — very often they don't have the means to play 4K HDR video anyway, thus can safely be demoted to tier 2 or 3.

memfd_secret() in 5.14

jhoblitt — Mon, 09 Aug 2021 21:33:11 +0000

I'm not seeing a compelling use case for a feature that doesn't really provide much security... especially for the DRM use case where the administrator of the system is probably considered the primary threat.

In particular, android already has keystore (which supports TEE). Why would android apps bother to support a feature which will not be supported on the majority of devices for years (~1/2 of the android population is still <= 9) and provides inferior security to an already universal feature (since 4) which takes advantage of hardware isolation where supported?

memfd_secret() in 5.14

khim — Mon, 09 Aug 2021 21:19:56 +0000

> Something like Widevine couldn't require it until something like a decade from now.

Why? When Android and ChromeOS would be updated it can use it. Android usually takes longer, but not decade, more like 1-2 years.

The fact that this may break someone on desktop Linux is not a big deal for Google: Linux users are not their primary customers (e.g. Google Drive still have no Linux client).

Also: remember that Widevine is not-all-or-nothing: there are three levels of support. Would be easy to push devices without memfd_secret into tier2 or 3.

> rhel7/centos7, which is still widely deployed on business workstations, is using a kernel from 2013.

Not even close. If you would look on just a version number, then RHEL uses ancient kernel, but if you look on the list of features it supports… it carries tons of stuff backported from “latest and greatest”. If memfd_secret would be useful it will be backported, too, no problem.

memfd_secret() in 5.14

jhoblitt — Mon, 09 Aug 2021 21:06:37 +0000

Who would use it for DRM? Android? Something like Widevine couldn't require it until something like a decade from now. rhel7/centos7, which is still widely deployed on business workstations, is using a kernel from 2013.

memfd_secret() in 5.14

khim — Mon, 09 Aug 2021 20:59:30 +0000

Use it for DRM is complete no-brainer and you can be 100% sure it would be, eventually, used for that.

But I don't think it's just DRM, there are more interesting applications if you consider hypervisors, at least.

memfd_secret() in 5.14

khim — Mon, 09 Aug 2021 20:57:09 +0000

That special hardware, though, may be yet another hypervisor. Although not sure how feasible that would be, but the idea sounds interesting: essentially a microkernel which is basically does MMU and IOMMU — and that's it.

memfd_secret() in 5.14

jhoblitt — Mon, 09 Aug 2021 16:10:37 +0000

That is pretty much where I was going with the line of inquiry. If this is a security feature which is relatively easy to bypass, and there are by CPU instructions to create protected ephemeral memory regions (and TPMs to protect cryptographic keys at rest) how likely is it to see use in the wild?

memfd_secret() in 5.14

jhoblitt — Mon, 09 Aug 2021 16:06:33 +0000

In the case of a guest kernel, it isn't surprising if the host kernel provided protection features, but I think it is likely theoretically impossible to protect processes within a guest against the compromise of the host kernel without special hardware support that protects the guest kernel memory itself against the host kernel.

memfd_secret() in 5.14

NYKevin — Mon, 09 Aug 2021 15:12:01 +0000

> Is it theoretically possible project process pages against a compromised kernel without hardware support?

*With* hardware support, you can use SGX or an equivalent technology. This sort of thing is increasingly available on consumer-grade hardware. But without hardware support, somebody has to have access to those pages (either the kernel or a hypervisor), because that's just The Way CPUs Work (TM). Of course, there's always the option of running on the bare metal with no kernel, but that's probably not what you had in mind.

memfd_secret() in 5.14

hkario — Mon, 09 Aug 2021 12:59:07 +0000

application bugs: you can't use that memory in syscalls

memfd_secret() in 5.14

sandsmark — Mon, 09 Aug 2021 11:14:11 +0000

Since the only real usecase I can see for this is protecting DRM like Widevine (i. e. don't let the user inspect the code running), it doesn't matter much if the module is killed when going into suspend.

It just needs to run when you're trying to access DRM protected content in e. g. Firefox or Chrome, and when waking from suspend it can just get reloaded and check that it is running in an environment that the user hasn't messed with again.

Assuming I'm right, this is going to be fun. The API exposed to DRM modules is already pretty extensive (I remember at least including file IO and some network access in CDM11), but it is kind of limited now because on Linux you just have the "lowest" security level. They can't "trust" the operating system because the user has too much access to their own devices (except on Android).

But with this I'm assuming the goal is to allow the next level and will include API for the black box CDM binaries to inspect the whole system.

memfd_secret() in 5.14

sandsmark — Mon, 09 Aug 2021 11:03:13 +0000

I just assumed it was for DRM purposes (the Netflix type).

I. e. try to stop the user from inspecting the code running running on their machine (for example the Widevine module loaded in Firefox or Chrome).

memfd_secret() in 5.14

kleptog — Mon, 09 Aug 2021 10:32:10 +0000

The statistics are interesting, but I wonder if they're skewed by many companies having people log in remotely via Citrix or just using an online website or some such. Then sure, users can use any computer they like, it doesn't matter. Similarly, if the phone is only used for phone calls and no actual data is stored I can imagine the "using own phone for work" is doable.

The GDPR basically makes storing company data on uncontrolled personal computers a non-starter for most businesses. But remote access gives the user a controlled system, and web-browsers promise not to cache data fetched via TLS.

They can of course say you have to bring your own device otherwise they won't hire you. On the flip side, they're not allowed to just randomly add monitoring to your personal device and if anything goes wrong (like your home laptop gets hacked) you as employee bear no liability. Which is why companies often hand out laptops anyway because as owner they have many more possibilities to secure the device.

memfd_secret() in 5.14

chris_se — Mon, 09 Aug 2021 09:30:05 +0000

> As mentioned, potentially waking up and causing a fire.

Any device with a Lithium-Ion battery can catch fire, whether it's drawing power or not. And even if your device is shut down (not even hibernating), you could also trigger your power button accidentally. (Hasn't happened to me with a laptop yet, but has happened countless times with my cell phone, causing it to reboot.)

Was there a risk 30 years ago when there was no thermal throttling and no thermal cutoffs in devices, especially CPUs? Sure. Is there a non-zero risk that any device that contains energy storage catches fire? Absolutely. But hardware has come a long way since then to mitigate those risks and I think this concern is overblown. Heck, even 15 years ago with my then laptop I had a couple of times when it didn't even enter sleep (stochastic bugs in hardware and/or the kernel) and I didn't check before putting it into the bag because I was in a hurry. And while the inside of the bag got warm to the touch (at most 40C), nothing got really hot, the laptop throttled down and just drained its battery much quicker than in suspend mode, causing it to shut off and causing me some inconvenience.

Millions of people put their laptop in sleep mode in their bags daily, and I've yet to see an epidemic of cases where laptops catch fire due to this. The data just doesn't bear out that this is an issue that one should be concerned about. Your device catching fire because the manufacturer did a bad job with that specific model is by far a much likelier outcome than it catching fire due to being stuffed into a bag in suspend mode.

I'm not against hibernate, and I think that hibernating laptops is a very legitimate use case, especially if you want to leave it off (without draining battery) for a significant amount of time. But please don't argue for your position with fear-mongering against other legitimate ways of using your own device.

memfd_secret() in 5.14

anselm — Mon, 09 Aug 2021 09:15:54 +0000

There can also be regulatory-environment issues that work against BYOD. Here in Germany (as in the rest of the EU) there are very strict personal-data protection requirements that need to factor into companies' risk assessments. Many companies reasonably conclude that having customer or client data stored on (or even accessible from) employee-owned hardware is not a Good Idea, due to compliance issues and the increased risk of data breaches and associated fines/bad PR.

(The article you cite looks interesting but the statistics it quotes seem fishy in various respects. It is also tainted by the fact that the author himself seems to be a big fan of BYOD. I probably wouldn't want to lean on it too heavily for support.)

memfd_secret() in 5.14

khim — Mon, 09 Aug 2021 07:51:06 +0000

> Guess what, my friends who are not software developers usually also have company laptops and phones – and like it that way.

Interesting. So you have certainly managed to avoid the trend. Because statistic doesn't support your words at all: 87% of businesses are dependent on their employee’s ability to access mobile business apps from their smartphone and 67% of employees use personal devices at work.

I would guess this percentage is smaller in US and EU and bigger in third-world countries (almost all my friends from Egypt, Iran and Russia don't know about BYOD or any such fancy acronyms because no one ever thought about providing them with company smartphone and very rarely they got a company-provided laptop), but Bitglass, the Next-Gen CASB company, is based in Silicon Valley with offices worldwide — and it observes what I observe and not what you and Wol are observing.

And while your words sound convincing — they don't explain why things you observe and independent statistic observes don't match.

Because statistic very clearly shows that use of personal devices for work purposes is growing, not shrinking and the mitigation strategy chosen by the Industry is to make them… “less pesonal”, I guess: make sure bootloader is locked or security enclaves are installed (things like Intel SGX are developed for that purpose) and so on.

Add to that the fact that states (not just China or Iran, but also EU and US) increasingly want to ensure that nefarious sites they want to ban remain inaccessible to the most of the population — and you can easily imagine where all that is going.

memfd_secret() in 5.14

anselm — Sun, 08 Aug 2021 23:54:39 +0000

Just ask your friends who are not a software developers.

Guess what, my friends who are not software developers usually also have company laptops and phones – and like it that way. After all it's a lot easier to ignore or switch off the company phone outside business hours, over the weekend, or during your vacation than your own phone, especially given that with such an arrangement your boss and colleagues don't need to know your private phone number, which is none of their business.

From a company POV, apart from the recruitment issues mentioned earlier, my friends' employers' IT operations and support people presumably prefer dealing with mostly-uniform hardware from known suppliers (including on-site support contracts, and having spares on hand if a machine breaks) and a common standardised software and UI setup, and definitely don't want the security nightmare of employees maintaining VPN connections into the company from their own machines that are also independently connected to the public Internet for non-company stuff (because of course they don't want to route all their employees' Netflix traffic through the company VPN, either). Many companies tend to figure out eventually that giving people centrally-maintained company hardware to use on the job is cheaper in the long run than dealing with the ongoing hassle and expense of getting people's random privately-bought computers to work properly (and securely) on the company's network. The lucky ones do so before the first malware infestation of the company's network via an employee's BYOD computer.

memfd_secret() in 5.14

mjg59 — Sun, 08 Aug 2021 17:25:40 +0000

That's relevant in terms of how long a device can keep state, but not relevant to whether it'll catch fire in your bag.

memfd_secret() in 5.14

khim — Sun, 08 Aug 2021 17:19:03 +0000

> This whole thread is because you're advocating TAKING AWAY OTHER PEOPLES' CHOICE.

Seriously? You think I want to see people who don't have a choice? I don't.

But if people don't care about fighting for that choice (doesn't matter if that's because of ignorance or because they don't really want to have choice in the first place) then it would be taken from it.

I'm only discussing the implications.

> As soon as we lose the WILL to defend freedom, we lose the war.

Who are these mythical “we”? 2½ geeks? They don't really matter much in the grand theme of things. The majority of people? They don't care and thus it's not even worth discussing if war would be lost or not. We can can only discuss how and when that loss would happen.

> But thanks for making me look like RMS. Thanks for making me look like a person who actually DOES BELIEVE in personal choice.

He is also a person who went from someone whose voice was important to someone who is ostracized and [almost] kicked out from his own organization, don't forget that.

It's only matter of time when both his and yours opinions would become irrelevant.

Mine don't matter much, too, I freely admit that. But at least I don't pretend that I can do things which I can not, really, do.

memfd_secret() in 5.14

khim — Sun, 08 Aug 2021 16:55:10 +0000

> Personally I would not be prepared to work for an employer who is unwilling to provide me with a suitable computer and phone to use for company business.

They probably can. If you are really fussy. But it's often just easier for both user and company when you only need one phone and one laptop to travel somewhere.

> The IT job market being what it is these days, paying for decent tools is a prerequisite for companies that want to attract (and keep) top-quality talent – and compared to a software developer's compensation, the price of even very good hardware is virtually negligible, so putting off potential applicants by requiring them to supply their own work equipment at their own expense (and then insisting on controlling what software is installed on that equipment and how it is configured) doesn't even make good business sense.

Who said anything about IT job market? It's tiny. Various estimates put number of software developers worldwide between 20 and 30 million. But there are half-billion of laptops in use and many billions of smartphones. Simple math shows that the software developers are tiny, almost negligible percentage of all users.

Yes, there are shortage of software developers and yes, because of that they can enjoy luxury of being treated differently. But majority of people are not in that position. They couldn't really play “oh, I want to do whatever I want with the device I own — and you have to bend over backward to accommodate my wishes” games. If accountant or a simple clerk would try that game — they would be fired and someone else would take their place. It's not that hard.

And the needs of these people are what drives the development of software and hardware. Most of them want to have locked down device — if that would bring more money for food and other spendure.

Just ask your friends who are not a software developers.

And if that's what they want then Industry would provide that. And kernel development, today, is part of the Industry. It doesn't matter if you like that or not — it's just the fact.

memfd_secret() in 5.14

Wol — Sun, 08 Aug 2021 16:32:28 +0000

> I don't like it, too. But I, unlike Wol, can see a bit farther than the end of my own nose and can see what and why happens because of that change.

You probably don't have to look that far to find plenty of posts by me where I see what is happening, and indeed, I rail against people who are blind to the realities of life. After all, there are plenty of occasions - on LWN - where I rail *against* this blind belief in some thing called "freedom".

But thanks for making me look like RMS. Thanks for making me look like a person who actually DOES BELIEVE in personal choice. This whole thread is because you're advocating TAKING AWAY OTHER PEOPLES' CHOICE.

So on a site full of people dedicated to Freedom, and Choice, thanks for making me look good!

I believe Fascism is defined as "Rule By Corporation". If you want to actively help that, that's down to you. As soon as we lose the WILL to defend freedom, we lose the war. Personally, I don't want to be a corporate slave.

Cheers,
Wol

memfd_secret() in 5.14

khim — Sun, 08 Aug 2021 16:28:01 +0000

> Unlike in America, in Europe mistreating your employees can really hurt

Where do you see “mistreatment”? Nobody forces you to do anything. It's entirely up to you to install VPN (and other company-provided software) or not.

And KPI are objective, too: reaction time, number of closed tickets and so on. If you fail to deliver — why should you get the appropriate bonus? It's not called “bonus” for nothing. You have to earn it.

> Employees can easily walk away from cases like this with two or three years salary in damages. To say nothing of the hit the company takes defending the case.

These are pure words at this point. I have friends both in UK and continental EU and it's really not hard to give people who misbehave 2x-3x less money.

As long as salary is the same and on paper there are no problems Employment Tribunal can do nothing. For added safety you may organize additional income to come in form of dividends or stocks (I don't think you can get stock options in EU, but that's not a big deal if your accountants are proficient enough).

Again: it really feels as if you live in the imaginary world where laws like these are perceived as something to follow and not an obstacle to overcome.

memfd_secret() in 5.14

Wol — Sun, 08 Aug 2021 16:07:13 +0000

> > And saying "let us tamper with your computer or get sacked" does not count as informed consent - it's called "unfair dismissal", which can be VERY expensive, let alone the (I believe) 5-year jail sentence that goes along with hacking the employee's personal computer.

> Can you give me the list of companies which were fined for that? And who got the jail sentence?

I'm not aware of any hacking occurring. Because the employee who did it would be liable for the jail sentence. Probably at the employer's expense.

As for fines, it's damages, not fines. It's actually pretty easy to take your employer to an Employment Tribunal. There have been plenty of cases of that. And in a case like this it would be a slam-dunk with serious damages. Unlike in America, in Europe mistreating your employees can really hurt. Employees can easily walk away from cases like this with two or three years salary in damages. To say nothing of the hit the company takes defending the case.

Cheers,
Wik

memfd_secret() in 5.14

anselm — Sun, 08 Aug 2021 16:03:33 +0000

Personally I would not be prepared to work for an employer who is unwilling to provide me with a suitable computer and phone to use for company business. The IT job market being what it is these days, paying for decent tools is a prerequisite for companies that want to attract (and keep) top-quality talent – and compared to a software developer's compensation, the price of even very good hardware is virtually negligible, so putting off potential applicants by requiring them to supply their own work equipment at their own expense (and then insisting on controlling what software is installed on that equipment and how it is configured) doesn't even make good business sense.

memfd_secret() in 5.14

khim — Sun, 08 Aug 2021 13:07:04 +0000

Answered the part where you, at least, admit that other people exist and may even, gasp, have desires different from yours.

> And while, as a gentoo user, your alternative is easy for me, many others would find that difficult and it is precisely those people we want to attract!

The majority of people are perfectly happy to live without hibernation and without the ability to change kernel options. They value the ability to pay with their phone in a shops or watch movies on Netflix much more than any software freedoms — otherwise devices of type jail made cool, designed to sever fools from their freedom wouldn't have outnumbered all others by count of 10-to-1 (and soon 100-to-1, I suspect).

Ok. Can you explain what kind of people you want to attract, why do you think I want to attract these same people, too, and why are you sure they even exist (except for the ones who have already switched to OpenBSD and Gentoo)?

memfd_secret() in 5.14

khim — Sun, 08 Aug 2021 12:44:23 +0000

> And saying "let us tamper with your computer or get sacked" does not count as informed consent - it's called "unfair dismissal", which can be VERY expensive, let alone the (I believe) 5-year jail sentence that goes along with hacking the employee's personal computer.

Can you give me the list of companies which were fined for that? And who got the jail sentence?

I think you still are living in the imaginary world where law means a lot more than it does in reality. PJ lived there for a few years. She have got an epiphany eight years ago. You still live in a delusion.

In a world where Supreme Court decision is easily ignored talking about what's written in this or that law is pointless.

And if you think that it's “just the insanity on the other side of the pond” then here is how princple of solidarity trumps the actual laws.

The only thing that matter is how laws are actually treated in real world. And not even how they are interpreted by courts but by how they are, then, applied by police and other government institutions.

> If I'm the *owner* I have every right to disable (or enforce) this security feature.

For a next few years, sure, you would have such right. Maybe even longer — for a devices not connected to the network.

> But don't treat the owner as if they're a "mere user". And as I said elsewhere, I can be a "grumpy old man". I do not like being what I can, and can not, do with MY OWN computer.

That's nice way if putting it. But who said there are enough people like you to matter? Heck, who said you would have the right to do that in the future? Once upon time land was treated like that, too. And buildings. You owned it — you could do whatever you want with it. Can kill the trespasser or change building shape in any way you like.

Today it's not true (violate any of bazillion related laws and you can easily be prosecuted for what you do on your own land with your own property) and as world becomes more and more connected laptops will follow (phones are already there, more-or-less).

I'm just looking of how the world behaves and make the appropriate decision based on that.

You, on the other hand, start with your likes and dislikes and then act as if they matter one jot.

No, they only matter when others allow them to matter. And that happens in rarer and rarer cases.

At some point your ability of doing what you want (and not what others think you should want) would be cancelled. And no, becoming a “grumpy old man” wouldn't save you. Unless you have some hypersonic missiles stashed under your bed and could actually protect your choice of life you would do as others would decide.