Re: [Discuss] ssd's in linux
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- > bounces+blu=nedharvey@blu.org] On Behalf Of Kent Borg > > On 11/08/2013 06:15 AM, Stephen Adler wrote: > > I'm thinking of upgrading my linux system by adding an SSD drive to > > use as my system disk. Has anyone done this? Any pros and cons > > regarings using SSD's? I'm more intrested in the cons. > > I have been wondering the same thing, I have an empty msata slot in my > Thinkpad, and little flash cards that fit in there are pretty cheap. > Especially the small capacity ones: ~60GB for ~70 dollars. > > But flash makes me worry. In the memory stick and SD space they like to > go from working to not working in an instant, with no warning nor change > to recover anything. And recently a Linux kernel release was delayed > when Linus' fancy SSD volume died--with no warning nor chance to recover > anything. Baaah. First of all, USB & sdcard are the cheap junk. Reliability in SSD's comes primarily from smart controllers, which USB & sdcard don't have. If you use USB & sdcard in a way similar to your laptop hard drive, you can bet the USB & sdcard will die frequently. Second of all, how many hard drives have you seen fail in your life? Failures happen to everything, and I'm certain that SSD is not the first drive that ever failed in the hands of Linus. Or anyone else. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] ssd's in linux
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- > bounces+blu=nedharvey@blu.org] On Behalf Of Jack Coats > > I found having 'enough ram', don't configure swap, or swap to a How many times have we had this conversation? Agreed you should never swap active memory, and therefore, you need to have enough memory in your system. And the linux kernel will use free memory for caching & buffering to gain performance. But if you add some swap to your system, your kernel will swap out idle processes, whenever the idle process is less active than some working cache data. By giving your system some swap, you gain performance, because the kernel is able to keep something in cache which is more valuable than a zombie process or whatever that could be put aside to make more room for more cache. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] ssd's in linux
We tend to go over the basics every time someone else asks the question that begs for basic answers. Few, if any of us, review archives, wikis, or do general searches before asking questions. If we did, the list would be full of cricket noises. That is why I tend to not reply to most of the posts I receive, but sometimes I chime in, adding to the entropy of the universe. On Sat, Nov 9, 2013 at 9:16 AM, Edward Ned Harvey (blu) wrote: >> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- >> bounces+blu=nedharvey@blu.org] On Behalf Of Jack Coats >> >> I found having 'enough ram', don't configure swap, or swap to a > > How many times have we had this conversation? Agreed you should never swap > active memory, and therefore, you need to have enough memory in your system. > And the linux kernel will use free memory for caching & buffering to gain > performance. > > But if you add some swap to your system, your kernel will swap out idle > processes, whenever the idle process is less active than some working cache > data. By giving your system some swap, you gain performance, because the > kernel is able to keep something in cache which is more valuable than a > zombie process or whatever that could be put aside to make more room for more > cache. -- ><> ... Jack On today's episode of 'This Ol Geek'... "Texas is the finest portion of the globe that has ever blessed my vision." - Sam Houston "Whatever you do, work at it with all your heart"... Colossians 3:23 "If you are not part of the solution, you are part of the precipitate" - Henry J. Tillman "Anyone who has never made a mistake, has never tried anything new." - Albert Einstein "You don't manage people; you manage things. You lead people." - Admiral Grace Hopper, USN "Life is complex: it has a real part and an imaginary part." - Martin Terma ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Cold Boot Attacks on Encryption Keys
Richard Pieri wrote: > Tom Metro wrote: >> The scenario is that you have strongly encrypted data on disk, >> decryption keys in memory, an OS configured so that it doesn't do >> something stupid, like write the keys to unencrypted swap space, and an >> OS hardened enough that physical access to the machine seems like the >> easier attack vector. > > The problem with this scenario is that it makes no sense. If your threat > is physical attack then why aren't you hardening your physical intrusion > prevention? Oh, physical security is already excellent in this scenario. Locked cage, 24/7 CCTV, and a security guard. The weakness is that your server is in a data center owned by a 3rd party, who can simply hand the keys over to someone else. The data center is legally obligated to comply with any requests from law enforcement, and in many cases not required or prohibited from informing you, so you have no opportunity to fight a frivolous warrant or prevent your server from being swept up along with a batch of your neighbor's servers. This scenario has played out in the news a bunch of times in the past few years. Figuring out how to secure data held in data centers, despite physical access to the machines, is going to be one of the challenges of the next few years. > ...there's a simple...way for me to circumvent all of your > clever...self-destructs... I go after your backups. They're encrypted too, with keys only held in memory. Of course having all these servers with keys only held in memory is going to make some IT guy have a bad day when recovering from a power failure. Not easy to scale this up to hundreds of servers while still keeping things secure. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Cold Boot Attacks on Encryption Keys
On Sat, Nov 09, 2013 at 03:55:18PM -0400, Tom Metro wrote: > > ...there's a simple...way for me to circumvent all of your > > clever...self-destructs... I go after your backups. > > They're encrypted too, with keys only held in memory. No. They're encrypted, with keys written down on paper and held by your lawyer. -dsr- ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Cold Boot Attacks on Encryption Keys
Tom Metro wrote: Oh, physical security is already excellent in this scenario. Locked cage, 24/7 CCTV, and a security guard. The weakness is that your server is in a data center owned by a 3rd party, who can simply hand the keys over to someone else. I must disagree with your assessment of "excellent". If a third party has physical access to your equipment and data then that equipment and data are not secure. If that third party has a greater interest in serving itself or other parties than it has in serving you then that equipment and data are distinctly vulnerable. They're encrypted too, with keys only held in memory. Then your disaster recovery options are nil. An encrypted backup that cannot be decrypted is mostly useless except for maybe being an example of how not to run a backup system. Dan's suggestion is great if legal threats are included in your threat model. Otherwise locked in a safe requiring two different security officers to unlock. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] Cold Boot Attacks on Encryption Keys
Richard Pieri wrote: > Tom Metro wrote: >> They're encrypted too, with keys only held in memory. > > Then your disaster recovery options are nil. An encrypted backup that > cannot be decrypted is mostly useless Sorry, I thought it was obvious that the keys had to come from somewhere. (Somewhere other than generating a new key every time the system reboots.) I was envisioning a system in which an administrator connects into the system after reboot and either supplies the entire key over a secure channel from an off-site system, or perhaps loads the key from a USB drive that is physically removed once loaded into memory, or enters a strong password to decrypt a stored key. I alluded to all this in the prior message when I questioned how scalable this approach is. Although I'm sure some automation could be used to load keys onto multiple systems, the more automated the system becomes, the likely it becomes that someone can get their hands on your key server. I'd be curious to know if anyone has deployed something like TrueCrypt on a sizable cluster of machines. How did they handle reboots? Dan Ritter wrote: >> They're encrypted too, with keys only held in memory. > > No. They're encrypted, with keys written down on paper and held > by your lawyer. I thought we were talking about data backups, not key backups. You want to store your key backups on paper with your lawyer, sure, that makes sense. But the keys used to encrypt your data needs to be loaded into memory after reboots. Even if you wrap your symmetric key in an asymmetric encrypted container, you still need the private key to expose the symmetric key at the time backups are being created. I don't think you want to be calling up your lawyer and paying him to recite strings of hex as you type them in after each reboot. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
