memfd_secret() in 5.14 [LWN.net]

memfd_secret() in 5.14

Posted Aug 6, 2021 19:53 UTC (Fri) by mb (subscriber, #50428)
In reply to: memfd_secret() in 5.14 by Cyberax
Parent article: memfd_secret() in 5.14

>So that applications will get SIGBUS on future accesses.

That will probably crash the application. Even if it was equipped to handle SIGBUS, what could the application possibly do? The data is gone. Therefore it wouldn't help the widespread adoption to put critical data into secret memory areas.

to post comments

memfd_secret() in 5.14

Posted Aug 6, 2021 21:21 UTC (Fri) by khim (subscriber, #9252) [Link] (43 responses)

> The data is gone.

But is it irrevocably gone?

I don't think you are supposed to keep your only copy of secret keys there.

If that's something like Netflix decryption key, though, then you, probably, can request another one from Netflix.

This may or may not be useful, but storing stuff in a hibernation file would just make the whole excercise pointless: why hide data from kernel if attacker can just request a hibernation and pull it from the file?

memfd_secret() in 5.14

Posted Aug 7, 2021 6:35 UTC (Sat) by mb (subscriber, #50428) [Link] (42 responses)

>but storing stuff in a hibernation file would just make the whole excercise pointless

I don't think so. Hibernation files should be encrypted anyway, if there's any chance of sensitive data being handled on the machine.

memfd_secret() in 5.14

Posted Aug 7, 2021 8:40 UTC (Sat) by khim (subscriber, #9252) [Link] (41 responses)

Usually it's encrypted with the key which can be found in kernel memory somewhere and if we are protecting app from the kernel then it's assumed that whole kernel-visible memory is readable to the attacker.

It's probably possible to create a different hibernation scheme where some entity external to the kernel copies the whole RAM to disk and encrypts everything, but that wouldn't be usual hibernation module anyway and it wouldn't be affected by kernel options at all.

memfd_secret() in 5.14

Posted Aug 7, 2021 9:35 UTC (Sat) by mb (subscriber, #50428) [Link] (40 responses)

>Usually it's encrypted with the key which can be found in kernel memory somewhere

I use the kernel key management for disk + swap (hibernate) encryption.
Doesn't that wipe the key cache (after some timeout)?

I understand that hibernation reduces the security of memfd_secret().
However disabling hibernation or killing random apps does completely destroy the UX and it will prevent the widespread adoption of this security feature.
Let the user decide whether the risk of having an (encrypted) hibernation image is Ok or not.

memfd_secret() in 5.14

Posted Aug 7, 2021 9:46 UTC (Sat) by khim (subscriber, #9252) [Link] (39 responses)

> Let the user decide whether the risk of having an (encrypted) hibernation image is Ok or not.

How many times should we do the same mistake again and again? It doesn't work with security. Dancing pigs effect is very well known by now.

Case to the point:

> I use the kernel key management for disk + swap (hibernate) encryption. Doesn't that wipe the key cache (after some timeout)?

You don't even know how the whole thing works yet presume to be able to do the right choice. Most users know even less than you. They only know that “no security” knob gives them dancing pigs and the other one doesn't. Thus they would choose the “no security” knob 10 times out of 10.

> However disabling hibernation or killing random apps does completely destroy the UX and it will prevent the widespread adoption of this security feature.

That's fine. Unused feature doesn't waste any resources and can even be removed, eventually. “Security theatre” feature does waste the resources without providing any benefits. Thankfully Linux kernel is not developed by a corporation which would perceive security buzzwords more important than actual security thus they are not introducing features for press-releases, but for actual use.

memfd_secret() in 5.14

Posted Aug 7, 2021 10:06 UTC (Sat) by mb (subscriber, #50428) [Link] (38 responses)

>You don't even know how the whole thing works yet presume to be able to do the right choice.

Well, you're mixing two completely unrelated scenarios here.
I didn't base my "choice" on whether the keys are wiped from kernel memory or not.
I don't care, if there are keys in kernel memory.

But I do care, if hibernation stops working as soon as some random app starts using memfd_secret(). Yes, I know that for now that can't happen, as long as I don't enable that feature on the kernel command line. But that's exactly my point the whole time: This feature won't experience widespread use. Exactly because:

>Thus they would choose the “no security” knob 10 times out of 10.

They also will press the "more security" button 0 times out of 10.

memfd_secret() in 5.14

Posted Aug 7, 2021 10:23 UTC (Sat) by khim (subscriber, #9252) [Link] (37 responses)

> They also will press the "more security" button 0 times out of 10.

Indeed. That's why the only way to introduce new security feature is with “more security” choice being the only option. Users pick “more security” option quite easily if the alternative is not mere knob, but patch to the kernel, recompilation and other hassle of such level.

> This feature won't experience widespread use.

Why do you think so? I would expect that DRM-providers would adopt it quickly. Then VPNs and remote access apps would demand it. Then, eventually, Chrome and Firefox would join the crowd.

At that point it would become a moot point if you want to use hibernation or not: you system wouldn't be much useful if you would choose the hibernation. Although I expect that the ability to empty that security memory before hibernation would be adopted instead, but maybe not. I'm not really sure how useful hibernation is today. I don't use it thus I don't care.

> I don't care, if there are keys in kernel memory.

But I do care, if hibernation stops working as soon as some random app starts using memfd_secret().

And that's exactly and precisely why hibernation shouldn't be allowed to be used when memfd_secret is used. You don't care about security of memfd_secret() — and other users feel the same. Which means application developers couldn't rely on it. And if application developers couldn't rely on it then why is it there in the first place?

memfd_secret() in 5.14

Posted Aug 7, 2021 14:47 UTC (Sat) by Wol (subscriber, #4433) [Link] (36 responses)

> I'm not really sure how useful hibernation is today. I don't use it thus I don't care.

Well, on my (Windows) laptop, it's configured to hibernate every time I close the lid.

You do NOT want to put a sleeping laptop into a laptop bag. It could set the bag alight. It could fry the laptop. It could crash the OS and lose you all your work ...

Just because you don't have a laptop doesn't mean other people don't have any use for hibernation.

What we need is not asking people do you want secrets (or whatever). We need to put the choice to them and say "hibernation or secrets? Which is most important to YOU?". If they don't understand secrets, I'll guess they choose hibernation. Then the secrets app will crash. Fine - it'll make them investigate and maybe secrets IS more important.

But just because YOU have no use for hibernation ... as far as I'm concerned *I* have no use for secrets. My employer may disagree ... :-)

Cheers,
Wol

memfd_secret() in 5.14

Posted Aug 7, 2021 15:01 UTC (Sat) by khim (subscriber, #9252) [Link] (35 responses)

> You do NOT want to put a sleeping laptop into a laptop bag.

Why not?

> It could set the bag alight. It could fry the laptop. It could crash the OS and lose you all your work ...

How is that related to hibernation? If your OS is buggy then yes, all that can happen. With or without hibernation. In fact in my experience (back when I still tried to make hibernation work) “crash the OS and lose you all your work” was something which happened with hibernation 10 times more often than with suspend.

> Just because you don't have a laptop doesn't mean other people don't have any use for hibernation.

Who said I don't own a laptop? I own quite a few of them. With Linux, ChromeOS and Windows. Although Windows is not used very often, but even it works just fine without hibernation. I disabled it after finding few times my Windows partition being inaccessible from Linux.

> But just because YOU have no use for hibernation ... as far as I'm concerned *I* have no use for secrets. My employer may disagree ... :-)

And your employer would, eventually, win.

> Then the secrets app will crash.

Or it may refuse to even start. Which also valid option and much easier to support.

memfd_secret() in 5.14

Posted Aug 7, 2021 15:26 UTC (Sat) by mb (subscriber, #50428) [Link] (3 responses)

>Or it may refuse to even start. Which also valid option

Refusing to start, to crash or refusing to do other things (e.g. hibernate) is not really a valid option from UX perspective.

Programmers often tend to assume that it's valid to do such things. "Somebody else will care and clean up after me. Let the user just restart the app. etc...". But it's *not* Ok. People will get frustrated by broken software that crashes or doesn't work as expected. (as in: what the user(!) expects)
Users don't use software for the sake of software, but rather to get actual work done.

I cannot enable memfd_secret(), because I use hibernation.
Distributions cannot enable memfd_secret() by default either, because they have users using hibernation.
Therefore it's a turn-on-by-user security feature. Which is very bad, because people tend to not turn on such features out of fear of breaking something.

memfd_secret() is a useful feature. Even with (encrypted) hibernation. So (at least!) give me the choice to enable it, please. But I'd rather like to see it enabled by default. Even with unencrypted hibernation.

memfd_secret() in 5.14

Posted Aug 7, 2021 15:51 UTC (Sat) by khim (subscriber, #9252) [Link]

> Users don't use software for the sake of software, but rather to get actual work done.

True. And they would upgrade (or downgrade) to a certain version of OS or disable hibernation if that's needed to do their work.

> So (at least!) give me the choice to enable it, please.

Why? If I understand correctly that feature wasn't designed simply because someone was bored. And the people who developed it want to ensure kernel would never see or access these pages. They most certainly don't want to see that information stored or HDD or SSD, encrypted or not. Or else feature would be useless for them.

Why do you think making feature for some bystander is more important than making it useful for people who developed it in the first place?

> But it's *not* Ok. People will get frustrated by broken software that crashes or doesn't work as expected. (as in: what the user(!) expects)

If that's not Ok then why are OSes and applications developed around that paradigm (MacOS and Windows, Android and ChromeOS) are so much more popular than platforms which are “correct from UX perspective” ones?

Think about it. And no answer “they are popular because most users are secret masochists” is wrong.

memfd_secret() in 5.14

Posted Aug 7, 2021 16:17 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

> memfd_secret() is a useful feature. Even with (encrypted) hibernation. So (at least!) give me the choice to enable it, please. But I'd rather like to see it enabled by default. Even with unencrypted hibernation.

Just make it point out to the user - with strong warnings - that it will disable hibernation. You want it, fine. It just needs to be an either/or choice.

Cheers,
Wol

memfd_secret() in 5.14

Posted Aug 7, 2021 16:26 UTC (Sat) by khim (subscriber, #9252) [Link]

Isn't it how it's done today?

memfd_secret() in 5.14

Posted Aug 7, 2021 15:31 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (8 responses)

A suspended macbook will wake itself up every once in a while.

A software bug that makes it not suspend again, paired with a faulty temperature sensor might cause fire.

memfd_secret() in 5.14

Posted Aug 7, 2021 15:35 UTC (Sat) by khim (subscriber, #9252) [Link] (7 responses)

What would prevent it from doing that if it's hibernated? How would you even know it went to hibernation when you requested it?

The fact that some OSes are buggy and need hibernation to make you feel safe doesn't mean all of them are like that.

ChromeOS doesn't support hibernation at all yet I never seen or heard about it causing fire. Have you heard about such cases?

memfd_secret() in 5.14

Posted Aug 7, 2021 16:10 UTC (Sat) by Wol (subscriber, #4433) [Link] (6 responses)

> What would prevent it from doing that if it's hibernated?

Because a hibernated laptop is SWITCHED OFF!

A sleeping laptop is still running, still burning battery, and will die after (some definition of) a few hours. Potentially losing your work. As mentioned, potentially waking up and causing a fire. Etc etc.

A hibernated laptop is switched off and doesn't wake until you press the power switch, or wake-on-lan, or some EXTERNAL event causes it to fire up.

That's another reason for wanting to hibernate. If I don't have access to a charger, and don't need my laptop, I DON'T want it burning battery!!!

Cheers,
Wol

memfd_secret() in 5.14

Posted Aug 7, 2021 16:22 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

> Because a hibernated laptop is SWITCHED OFF!

And how do you know it's actually switched off? Many (most?) modern laptops have all these LEDs (power, suspend, mic off and so on) software driven.

Thus, in the end, you have to trust your software anyway.

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

Have you ever heard about EFI wakeup alarm clock? Your hibernated (and even, presumably, switched off) device can do that perfectly fine, too.

> A hibernated laptop is switched off and doesn't wake until you press the power switch, or wake-on-lan, or some EXTERNAL event causes it to fire up.

Who told you that? I don't even know how long ago we had systems which couldn't wake up on their own volition.

> If I don't have access to a charger, and don't need my laptop, I DON'T want it burning battery!!!

Power it off if it's really need to go to sleep for a few days. That's really rare need in today's world, though.

You would save much more power since after wake up there wouldn't be a browser with moder web pages which insist on draining your battery as fast as they can (LWN is rare exception).

memfd_secret() in 5.14

Posted Aug 7, 2021 17:41 UTC (Sat) by Wol (subscriber, #4433) [Link]

> Power it off if it's really need to go to sleep for a few days. That's really rare need in today's world, though.

Is it? Once again you're assuming everyone is the same as you.

It is NORMAL for me (living in a first world country) to have no access to mains power for several days at a time. Yes it's my choice. But if I can't recharge my laptop for a week, I want to save as much battery as I can, and that includes not having it wasting power sleeping.

(And while one person can't make much difference, why should I want to waste power? If EVERYBODY saved just a few watts here and there - and had the "let's save it" mindset), we might make a dent in global warming :-)

Cheers,
Wol

memfd_secret() in 5.14

Posted Aug 8, 2021 0:45 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (2 responses)

> Because a hibernated laptop is SWITCHED OFF!

Modern hardware has basically the same set of wakeup events when powered down as it does when suspended. The embedded controller is powered and can turn the machine back on whenever it feels like it. Unless you actually pull the battery, "Switched off" doesn't mean what you think it means - the only meaningful distinction between suspend and off is whether or not the RAM is in self-refresh.

memfd_secret() in 5.14

Posted Aug 8, 2021 9:57 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

Yup. And as I understand it, that's the difference between sleep and hibernate. Hibernate also means ram-refresh is OFF.

Which, when you're off-grid and battery life is critical, is important.

And I don't know which, in general, uses more battery. Rebooting? or restoring from hibernate? My gut feel is hibernate is likely to use less battery, because it doesn''t go through the (possibly) long start up sequence before getting to a usable system.

Cheers,
Wol

memfd_secret() in 5.14

Posted Aug 8, 2021 17:25 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

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

Posted Aug 9, 2021 9:30 UTC (Mon) by chris_se (subscriber, #99706) [Link]

> 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

Posted Aug 7, 2021 16:13 UTC (Sat) by Wol (subscriber, #4433) [Link] (21 responses)

> > But just because YOU have no use for hibernation ... as far as I'm concerned *I* have no use for secrets. My employer may disagree ... :-)

> And your employer would, eventually, win.

Does your employer really have all that power? Are you their slave? Over here, that's ILLEGAL.

(hint - it's MY laptop. And as far as my wife's laptop goes, there IS NO employer involved)

Cheers,
Wol

memfd_secret() in 5.14

Posted Aug 7, 2021 19:22 UTC (Sat) by mpr22 (subscriber, #60784) [Link] (11 responses)

"Do not put company data on any device that is not the company's" and "do not put software that is not company approved on any device that is the company's" are not illegal in any part of the United Kingdom of Great Britain and Northern Ireland to the best of my knowledge.

memfd_secret() in 5.14

Posted Aug 7, 2021 21:35 UTC (Sat) by Wol (subscriber, #4433) [Link] (10 responses)

No they aren't.

But if the company DEMANDS that I put company data on *my* laptop, and the company DEMANDS that company data is not put on any unsecured device, that combo will land the company in serious trouble if they insist!

They are demanding that I put company approved security software on a personal device. That falls foul of both employment law and the Computer Fraud And Abuse Act or whatever it's called.

And actually, my employer has just fallen foul of that combo this last week. No foul intent on either side, but they've supplied me with a company laptop that requires 2FA. That requires the authentication software to be installed on a secured mobile, and I refused point-blank to secure my personal mobile. Actually, the company had supplied me with a company mobile, but I was having problems setting it up, so they just had to accept that I was unable to log in to the corporate network. The equipment they'd supplied didn't work, and if I didn't want to use my equipment instead, there was nothing they could do about it. (They were happy about me using my personal phone, I wasn't!)

(If I choose not to secure my personal phone, that is down to me. I also choose to actively avoid putting anything sensitive on said phone, so I have no problem with that. And I also choose not to put any sensitive data on Google, so losing my phone won't compromise what isn't there to be compromised.)

You're making the same mistake as Khim - you're assuming everything is work, and work over-rides everything. It doesn't - what I do in my personal time with my personal kit is down to me, which is why I often find myself without electric - I go "off grid". From choice.

Cheers,
Wol

memfd_secret() in 5.14

Posted Aug 7, 2021 21:56 UTC (Sat) by mpr22 (subscriber, #60784) [Link] (9 responses)

> You're making the same mistake as Khim - you're assuming everything is work, and work over-rides everything.

Mostly, I'm assuming that if my employer wanted me to run a specific secure build of an operating system, they would provide the equipment to run it on.

Like, I have to run a 2FA app on my phone to use the company VPN, but I wasn't asked to install a special build or security profile or anything (and if they did, I would say "give me a company phone then, because you're not putting fancy nonsense on my personal device").

memfd_secret() in 5.14

Posted Aug 8, 2021 10:24 UTC (Sun) by khim (subscriber, #9252) [Link] (8 responses)

And here, again, you are not looking on large picture but specifically on your own company in your own tiny corner of the world.

Look outside, please. What usually happens is not that companies demand you to do something to your hardware. No, absolutely not. It's always your choice. You may follow BYOD route or not. If you wouldn't lock down your hardware and wouldn't install company software — that's fine, too. You would just have no access to VPN and would only be able to read mail while physically in office.

But, of course, at the end of the year your performance would be compared to performance of people who are not this finicky and if your KPI would be not sufficient… you would get smaller bonus or may even be fired.

That is how it usually works and that is how 90% of devices end up bound to the companies policies. Yes, there are some outliers and there would always be, probably, some expensive toys for freedom-lovers who are ready to pay for the privilege. But they would just not matter much for the big picture and can be, usually, ignored.

That is what I have meant and that is what is happening today. You may not like the fact that the overwhelming majority of phones are locked devices and laptops are slowly drifting in that direction, too — but that's just what objectively happens. Independently of our wishes.

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.

memfd_secret() in 5.14

Posted Aug 8, 2021 16:03 UTC (Sun) by anselm (subscriber, #2796) [Link] (5 responses)

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

Posted Aug 8, 2021 16:55 UTC (Sun) by khim (subscriber, #9252) [Link] (4 responses)

> 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

Posted Aug 8, 2021 23:54 UTC (Sun) by anselm (subscriber, #2796) [Link] (3 responses)

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

Posted Aug 9, 2021 7:51 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

> 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

Posted Aug 9, 2021 9:15 UTC (Mon) by anselm (subscriber, #2796) [Link]

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

Posted Aug 9, 2021 10:32 UTC (Mon) by kleptog (subscriber, #1183) [Link]

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

Posted Aug 8, 2021 16:32 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

> 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

Posted Aug 8, 2021 17:19 UTC (Sun) by khim (subscriber, #9252) [Link]

> 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

Posted Aug 7, 2021 20:09 UTC (Sat) by sjj (guest, #2020) [Link] (8 responses)

Why are you shouting?

memfd_secret() in 5.14

Posted Aug 7, 2021 21:47 UTC (Sat) by Wol (subscriber, #4433) [Link] (7 responses)

I'm emphasizing it.

I'm guessing they're reading it as "new comments", and losing context (I do the same :-(

But unfortunately Khim does seem to have the attitude "if I can't see a use for it, it's useless", and I do get wound up if people appear not to be reading what I actually wrote - if I write *my* laptop, I don't mean "the laptop my company gave me". I can be a grumpy old man :-)

Cheers,
Wol

memfd_secret() in 5.14

Posted Aug 8, 2021 10:10 UTC (Sun) by khim (subscriber, #9252) [Link] (6 responses)

> But unfortunately Khim does seem to have the attitude "if I can't see a use for it, it's useless"

Can, you, please stop ascribing your own faults to others. Because the only guy who does that her is named Wol, not Khim and not mpr22.

When I wrote that that's really rare need in today's world, though what was your answer? Something like “here we have millions of people who need to do that” or “there are half-billion people who have no choice”? Note. It was It is NORMAL for me (living in a first world country) to have no access to mains power for several days at a time.

Yeah, precisely and exactly “if I can't see a use for it, it's useless”… but where have others used such thinking?

> if I write *my* laptop

…then you talk about one specific laptop. Not about other billion laptops. And then you use that anecdote to justify something? Puhlease.

memfd_secret() in 5.14

Posted Aug 8, 2021 12:09 UTC (Sun) by Wol (subscriber, #4433) [Link] (5 responses)

> > But unfortunately Khim does seem to have the attitude "if I can't see a use for it, it's useless"

> Can, you, please stop ascribing your own faults to others. Because the only guy who does that her is named Wol, not Khim and not mpr22.

> When I wrote that that's really rare need in today's world, though what was your answer? Something like “here we have millions of people who need to do that” or “there are half-billion people who have no choice”? Note. It was It is NORMAL for me (living in a first world country) to have no access to mains power for several days at a time.

Please look at the words below. They are *YOUR* words, not mine!

> Indeed. That's why the only way to introduce new security feature is with “more security” choice being the only option. Users pick “more security” option quite easily if the alternative is not mere knob, but patch to the kernel, recompilation and other hassle of such level.

Given the choice of "security or hibernate", I don't give a monkeys what you choose. I *DO*, however, give a monkeys if you disable my preferred choice in favour of an option *I* have no use for. (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!)

Oh - and as for BYOD, I have no problem with that, either. As long as the company gives me decent recompense. But as I said to mpr22 (I think he got the wrong end of the stick), under UK law you are NOT allowed to tamper with someone else's device without (informed) consent. 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.

It's quite common on LWN for people to confuse a computer's OWNER with a computer's USER. That's very important when talking about peoples' rights. If I'm the *owner* I have every right to disable (or enforce) this security feature. If I'm just a USER then that changes the dynamics. 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.

Cheers,
Wol

memfd_secret() in 5.14

Posted Aug 8, 2021 12:44 UTC (Sun) by khim (subscriber, #9252) [Link] (3 responses)

> 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.

memfd_secret() in 5.14

Posted Aug 8, 2021 16:07 UTC (Sun) by Wol (subscriber, #4433) [Link] (2 responses)

> > 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

Posted Aug 8, 2021 16:28 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

> 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

Posted Aug 21, 2021 0:24 UTC (Sat) by HenrikH (subscriber, #31152) [Link]

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

memfd_secret() in 5.14

Posted Aug 8, 2021 13:07 UTC (Sun) by khim (subscriber, #9252) [Link]

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

Posted Aug 6, 2021 22:24 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

Crashing the app is fine. We can also do something like send a signal to prepare the app for impending shutdown and/or after the restore.

As a reaction, the application can re-obtain the secret from whence it came: security co-processor, web service, password prompt, etc.

memfd_secret() in 5.14

Posted Aug 20, 2021 7:14 UTC (Fri) by ncm (guest, #165) [Link]

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

Posted Aug 21, 2021 0:22 UTC (Sat) by alopatindev (guest, #153807) [Link] (3 responses)

> 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

Posted Aug 21, 2021 1:17 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> 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

Posted Aug 21, 2021 13:44 UTC (Sat) by alopatindev (guest, #153807) [Link]

> 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

Posted Aug 22, 2021 11:28 UTC (Sun) by alopatindev (guest, #153807) [Link]

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?