The Consolidated B&EC "today I learned" Thread.

Not explicitly BE&C, but TIL ubuntu doesn't automagically purge kernels
https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels

Also it doesn't make a pagefile by default for encrypted LVM installs, even with everything on auto. Users complaining about random crashes solved

 

You know there is a context menu button on the keyboard right?

 

Automagically deleting kernels on systems that don't reboot frequently is problematic. I write a script that keeps the current running version (uname -r) and one kernel below (incase of breakages), and deletes everything after that.

Even that can still cause issues on machines that don't reboot frequently enough, with /boot filling up.

What version of Ubuntu? I've used the "auto LVM + encryption" option before and it's successfully created /boot on a partition, and root and swap on encrypted LVM without any problems. Quite a few major versions ago, however.

TBH I have't used the automagic version in a while. I should re-test, as I've got a few guides for our level 1 guys that rely on that.

 

Yeah - except when there's not (it was an MSI gaming laptop). I actually did say "without a mouse or that key available."

 

Tried on Ubuntu 14.10 and then xubuntu 14.04. Could be PEBKAC, but other colleagues reported the same. Most people didn't notice as 8gb ram was enough generally, unless you spun up a few VM's.

The script is a good idea, in my case autoremove also failed as the volume was too full haha, dpkg -i <everything less than current -1> fixed it

 

Don't forget an "apt-get autoremove --purge" after that. Helps to clean up random bits of headers, source, tools, qemu fluff, and other random things that are tied to old removed kernels.

 

Cool thanks for the tip

 

TIL Windows update can go stupid and eat up all the ram. Pretty sure I saw 3.5G committed out of my laptop's 8G. Chrome takes up a bunch as well, but it seems to spread the ram use over 10 or so separate processes. And it just happened to be while I was struggling with testing two palo alto VMs in vmware player that needed 5G total. The spinning rust was getting pretty angry with all the swapping.

start>run>services.msc and stop windows update service. Problem solvered.

 

There's a patch to fix that. KB3114409 i believe it was?

 

there were a few updates for this.

i think we deployed these two.

https://support.microsoft.com/en-us/kb/2938066
https://support.microsoft.com/en-us/kb/3083324


we were getting smashed with this last year.

trusted installer and svchost hogging stupid amounts of memory.

trusted installer is still a bit of a dick about it, but not as much as before.

 

An update to fix a broken update system. Oh the ironing.

 

Apparently "blkdiscard --secure" can securely wipe an SSD, where previously I used to have to do this song and dance.

Something I'm going to try when I return from annual leave.

 

I'd be curious as to whether the flash is actually entirely erased at a chip level, or whether some controllers might cheat a bit and leave things intact on the flash itself.

 

Yes, always a genuine concern with flash.

And to be honest, until Open Channel SSDs and software like LightNVM become common place...

https://en.wikipedia.org/wiki/Open-channel_SSD
http://lightnvm.io/
https://lwn.net/Articles/641247/

... we'll never be 100% sure that we can trust flash devices to be securely erased.

 

i think 3135445 also addresses this issue now.

 

I'm going to call bullshit on the fact that flash devices will never be securely erased. If someone can do a secure overwrite (2-pass random data for good measure) and then still manage to recover data off it, I'll eat my hat. Even writing sequential 0's should be enough to reduce the chance of successful data recovery to under 1% on any sort of modern storage device.

 

SSDs don't work that way. Just because you say "write a 0 to sector 0x1234" doesn't mean that it will end up there. The firmware can place it somewhere else for performance reasons, could de-duplicate the write, and often SSDs have spare cells off to the side for write-wear-levelling purposes (ever wondered why an SSD is 240GB, not 256GB?).

If you are writing to a firmware-controlled SSD (i.e.: almost every SSD on the market today), you have absolutely zero control of where data goes, and you cannot be 100% sure that you've even filled the drive due to spare cells and write levelling.

https://en.wikipedia.org/wiki/Wear_leveling#Techniques
"A pool of reserve space can also be kept. When a block or sector does fail, future reads and writes to it can be redirected to a replacement in that pool."

If you are writing to an Open-channel SSD, then you do have that control. Read the links I posted above to see the difference.

 

What is the risk of someone being able to construct useful data from what is left in these random leftover blocks?

 

Who are you defending against? A government actor? or bobs salvage?

The general accepted idea is that SSD's are really really bad at data integrity - hence checksuming filesystems are a must (BTRFS, ZFS, ReFS).

 

I understand how wear levelling works and what it means.

What I don't understand how you'd still be able to recover data even with this in place. Surely this reserved section is only used when blocks begin to fail? A normal, healthy SSD shouldn't be touching the reserved blocks. If they did that would defeat the purpose of being a reserved space. I could understand data recovery being a possibility if the drive wasn't healthy and there were a bunch of blocks that were readable but no longer writable, but then again it would be retired from production at this stage and most likely discarded anyway.

If someone has managed to fill a drive with 1kb .txt files and then do a secure erase, I'd really like to see proof if anyone getting a single readable thing out of it after that. If it's possible, I'd be pretty gobsmacked.