Most active commenters
  • saagarjha(4)
  • BrandoElFollito(4)
  • TeMPOraL(3)

←back to thread

286 points joegibbs | 48 comments | | HN request time: 1.045s | source | bottom
1. arcticbull ◴[] No.42143642[source]
Periodic reboots are actually a PCI requirement for payment terminals heh, basically every point of sale on the market reboots every 24h.
replies(5): >>42143696 #>>42143718 #>>42143892 #>>42144077 #>>42144547 #
2. Gigachad ◴[] No.42143696[source]
Seems like a good defence in depth strategy. These days most systems have a pretty good boot chain security, so after a reboot you know the system is in a valid state and any potential malicious changes have been flushed out.
replies(5): >>42144335 #>>42144436 #>>42144554 #>>42144910 #>>42147261 #
3. paxys ◴[] No.42143718[source]
And Boeing 787 airplanes
replies(2): >>42143849 #>>42144862 #
4. ◴[] No.42143849[source]
5. EasyMark ◴[] No.42143892[source]
Yeah I reboot my iPhone every weekend whether it needs it or not.
replies(1): >>42144034 #
6. hackernewds ◴[] No.42144077[source]
also, pretty necessary for the Prism program at the NSA to reinstall and update their firmware
7. DaiPlusPlus ◴[] No.42144335[source]
Probably also helps with other kinds of transient hardware faults (and cosmic-rays) that can cause bitflips.

That said, on principle, there is no reason why ECC RAM should not be the standard (c.f. Linus Torvald’s ire at Intel using ECC as a market-segmentation ploy)

replies(1): >>42145042 #
8. raverbashing ◴[] No.42144436[source]
But wait for security cargo-culters call it "security by obscurity"
replies(3): >>42144463 #>>42145136 #>>42145456 #
9. ip26 ◴[] No.42144463{3}[source]
All that private key nonsense falls in this bucket as well. What else is a private key than an attempt to guard your system behind a thin veil of "an obscure number I know and you don't"? Classic security by obscurity.
replies(2): >>42144928 #>>42144993 #
10. eleveriven ◴[] No.42144547[source]
The fact that Apple is adopting a similar approach for iPhones, is pretty much in line with that idea, just applied to personal data protection, isn't it?
replies(1): >>42144860 #
11. eleveriven ◴[] No.42144554[source]
Exactly! Especially in a world where systems are under constant attack
12. create-username ◴[] No.42144860[source]
Isn’t Apple planning on turning iPhones into POS (point of sale) terminals?
replies(1): >>42145206 #
13. dymk ◴[] No.42144862[source]
Shouldn’t happen mid-flight though
replies(1): >>42145861 #
14. bugtodiffer ◴[] No.42144910[source]
This is so damn sad. I don't fully get why I have to reboot after kernel updates but accept it, but just every 3 days? Why?
replies(2): >>42145164 #>>42145453 #
15. portaouflop ◴[] No.42144928{4}[source]
So everything is security by obscurity?
replies(1): >>42145348 #
16. raverbashing ◴[] No.42144993{4}[source]
Officially no, as one (or more secrets) are allowed

But given how some "security specialists" behave, I wouldn't put it past them

17. close04 ◴[] No.42145042{3}[source]
> reboots the phone if it’s not unlocked for 72 hours

Scheduled reboots would help more with clearing malware or transient errors.

But for now, for anyone periodically using the phone, which I bet is most users, the phone will never reboot automatically.

replies(2): >>42145110 #>>42145399 #
18. derefr ◴[] No.42145110{4}[source]
Not never; phones also reboot when there are critical OS updates to apply — and that happens as long as the phone is both charging and locked at any time during a vendor-defined daily maintenance window (usually something like 2AM-4AM in the user's local time.)

This happens even if the user just put the phone to sleep a moment ago. The only way to prevent it is to never leave your phone locked and charging at the same time.

replies(1): >>42145150 #
19. mmcnl ◴[] No.42145136{3}[source]
Nothing wrong with security by obscurity. It's widely used and it is effective. Security is security. Usually there are easier and more effective methods though, so if it's your only security layer then you might have missed a few things.
replies(1): >>42145991 #
20. close04 ◴[] No.42145150{5}[source]
> phones also reboot when there are critical OS updates to apply

Of course, or when they run out of battery, or you drop them too hard, etc. But realistically you could go for weeks or months without a reboot. From a transient fault or malware perspective, that might as well be never.

replies(1): >>42145257 #
21. teekert ◴[] No.42145164{3}[source]
Read. It's only when you don't touch it for 3 days. And I bet if you didn't even touch it for 3 days you won't even notice if it has rebooted or not.
replies(1): >>42145414 #
22. savoytruffle ◴[] No.42145206{3}[source]
What do you mean "planning"? They already are in some places, including Apple Stores themselves. But more often you see iPads in that role with a bigger screen for customers. Are they doing the same behavior? (I don't see why not).
replies(1): >>42145524 #
23. derefr ◴[] No.42145257{6}[source]
"Critical security updates" for iOS come ~weekly.
replies(1): >>42145450 #
24. rikkert ◴[] No.42145348{5}[source]
always has been...
25. TeMPOraL ◴[] No.42145399{4}[source]
> But for now, for anyone periodically using the phone, which I bet is most users, the phone will never reboot automatically.

Samsung has an auto-reboot daily feature and has been pushing it a lot (in form of annoying notifications and settings suggestions). In principle, it may not even be a bad idea - but for one fact:

Rebooting the phone effectively turns it off. Until the user unlocks the phone, it won't connect to phone network. AFAIK it also won't start any of the usual background processes that listen to notifications, and it might not even connect to Wi-Fi.

Those "security" measures make automated reboots an useless feature. There really is only one good time to auto-reboot, and that's when the user is sleeping. But no way anyone's doing that when it means their phone won't be able to receive calls. Even during the day, the phone randomly rebooting and remaining disconnected until the user notices - it's probably even worse, and I imagine anyone would disable this feature after first time it activated.

replies(3): >>42145513 #>>42145599 #>>42145722 #
26. TeMPOraL ◴[] No.42145414{4}[source]
Sure they would. If the system was for interactive use, it likely requires some login or unlock password. If the system is supposed to respond to external events - such as receiving phone calls when the system in question is a phone - then a reboot will effectively disable it until the user notices.
replies(3): >>42145561 #>>42145659 #>>42145731 #
27. saagarjha ◴[] No.42145450{7}[source]
This is definitely not true. Apple releases security updates about once a month.
28. saagarjha ◴[] No.42145453{3}[source]
How do you expect to swap out your kernel without restarting your machine?
replies(1): >>42145552 #
29. saagarjha ◴[] No.42145456{3}[source]
Sounds like that's just you.
30. nyargh ◴[] No.42145513{5}[source]
I'm not sure this is true.

I have a Samsung with this feature. It rebooted overnight and this morning it was in BFU state with several mail and sms notifications. It was also connected to wifi and the cellular network.

replies(1): >>42145533 #
31. Cthulhu_ ◴[] No.42145524{4}[source]
For the moment they have an external payment / card terminal; other than the card reader itself, I don't see why an iphone wouldn't work as a formal payment terminal.
replies(1): >>42146090 #
32. TeMPOraL ◴[] No.42145533{6}[source]
It was true for my Galaxy S22, and is currently true with reboots after update. And yes, early on I had a situation where the phone rebooted overnight and remained stuck on the lock screen while disconnected from networks, until I woke up and noticed. Fortunately I didn't miss anything important, but after that I immediately reviewed all settings and disabled anything that could reboot the device automatically (including updates, which are set for manual installation now).
33. sintax ◴[] No.42145552{4}[source]
Don't know about apple, but on linux you can live patch a running kernel with security updates (kpatch/ksplice/...).
replies(1): >>42145615 #
34. exe34 ◴[] No.42145561{5}[source]
> receiving phone calls

don't be ridiculous, it's a _smart_ phone.

35. gambiting ◴[] No.42145599{5}[source]
>>Rebooting the phone effectively turns it off. Until the user unlocks the phone, it won't connect to phone network. AFAIK it also won't start any of the usual background processes that listen to notifications,

Well yes, because the storage and all the apps are encrypted until you unlock your phone. So you could have all the apps boot up and start listening for events, but it would be at the cost of reduced security elsewhere. Not sure what the right solution is tbh, I think personally I'd rather have all of my data encrypted even if it means my phone isn't actually "active" after a reboot.

36. saagarjha ◴[] No.42145615{5}[source]
Right, which means that an attacker can trick your kernel into patching itself to do something malicious.
replies(1): >>42145743 #
37. 42lux ◴[] No.42145659{5}[source]
Only if you still use a sim pin otherwise the phone would only be unavailable for the duration of the reboot.
38. BrandoElFollito ◴[] No.42145722{5}[source]
> Until the user unlocks the phone, it won't connect to phone network.

This is not true in my case (Samsung Galaxy S22+). The phone is fully operational after a reboot, connected to GSM, 5G and Wi-Fi

39. BrandoElFollito ◴[] No.42145731{5}[source]
No it won't. My phone is completely operational after a reboot.
replies(1): >>42147343 #
40. dizhn ◴[] No.42145743{6}[source]
And automatic periodical reboots give hackers the piece they were missing. :)
41. blitzar ◴[] No.42145861{3}[source]
Would interrupt my movie.
42. rileymat2 ◴[] No.42145991{4}[source]
The main reasonable criticism would be that it obscures the things you missed from naive audits while still being accessible by an attacker. So you hide the issue from the "good guys" while not baring much entry by the "bad guys". I have seen this pattern emerge many times, because what is obscure to you may not be obscure to someone else. So it /causes/ you to miss things.
43. rswail ◴[] No.42146090{5}[source]
It already does.

Part of the new PCI standard called "Software based PIN entry on COTS" [1] which is also known generically as "PIN on glass".

Banks are now offering it to one-person trade companies etc [2].

[1] https://blog.pcisecuritystandards.org/new-faqs-on-software-b...

[2] https://www.westpac.com.au/business-banking/merchants-and-pa...

44. bean-weevil ◴[] No.42147261[source]
True, although for a remote attack there's no reason it can't just be reinfected after the reboot.
45. ben_w ◴[] No.42147343{6}[source]
Yours might. My SIM, however, automatically locks on reboot. It came like that.
replies(1): >>42147449 #
46. BrandoElFollito ◴[] No.42147449{7}[source]
All the phones I have used were like this (Samsung, Google, Xiaomi, Redmi, Oppo - across years and years of models).

I am surprised you write that the SIM is locked upon reboot. What does this mean in technical terms? Do you mean that you have to enter the SIM PIN when your phone reboots?

replies(1): >>42147556 #
47. ben_w ◴[] No.42147556{8}[source]
> Do you mean that you have to enter the SIM PIN when your phone reboots?

Yes.

I can cancel the popup and then still use the rest of the phone, but when I do that I have no cellular network access until I unlock the SIM itself.

For the avoidance of confusion, the SIM PIN is independent of the phone PIN.

replies(1): >>42147617 #
48. BrandoElFollito ◴[] No.42147617{9}[source]
Ah, this is the normal behaviour of a SIM card. You can disable this PIN at startup (a setting in the phone). This is not recommendable, though, because if your phone gets lost or stolen your SIM may be used in a "layer" (a device that will make premium calls or SMS, the name is derived from a hen (that lays eggs)).

The solution is to use an eSIM - you can disable the PIN at bootup because it is protected by the phone lock anyway and will be operational immediately.