2.16 final, 512MB usb pup_save with heavy encryption,

Please post any bugs you have found
Post Reply
Message
Author
User avatar
tronkel
Posts: 1116
Joined: Fri 30 Sep 2005, 11:27
Location: Vienna Austria
Contact:

2.16 final, 512MB usb pup_save with heavy encryption,

#1 Post by tronkel »

Seems to be a prob with universal install to USB in 2.16-final

I chose to create a 512MB encrypted (heavy) pup_save for an install to USB stick. On reboot into the system the new 512MB encrypted pup_save gets detected on the stick OK, but the freemem applet only shows 69MB as being available. I Gig USB stick is formatted to VFAT and PMOUNT reports the correct amount of unused space.

If an attempt is made to download a file larger than 69MB to the root folder with Seamonkey , the freemem applet shows its usual low memory warning whereupon Seamonkey then crashes.

On the next reboot the partially downloaded file is still there, but freemem then shows available free memory as back to 69MB.

Something seems to be going wrong when the 2 layers are merged in the shutdown script. I don't understand this area of Puppy very well. Some explanation would be appreciated here.
Life is too short to spend it in front of a computer

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#2 Post by BarryK »

I don't think it's a bug. The script that calculates free space is /usr/sbin/calcfreespace.sh and the relevant code is:

Code: Select all

case $PUPMODE in
 3|7|13) #home partition/file mntd on pup_ro1, tmpfs on pup_rw
  SIZEFREE=`df -k | grep ' /initrd/pup_ro1$' | tr -s ' ' | cut -f 4 -d ' '`
  SIZETMP=`df -k | grep ' /initrd/pup_rw$' | tr -s ' ' | cut -f 4 -d ' '`
  [ $SIZETMP -lt $SIZEFREE ] && SIZEFREE=$SIZETMP
  ;;
 6|12) #home partition/file mntd on pup_rw (no tmpfs)
  SIZEFREE=`df -k | grep ' /initrd/pup_rw$' | tr -s ' ' | cut -f 4 -d ' '`
  ;;
 *)
  SIZEFREE=`df -k | grep ' /$' | tr -s ' ' | cut -f 4 -d ' '`
  ;;
esac
You you be on PUPMODE 13, and it is calculating free space in RAM (pup_rw) and free space in your pup_sve file (pup_ro1) and using the smaller of the two.
In other words, you may have plenty of RAM space but your pup_save is full so there is no point putting more than that into RAM as there is insufficient space to save it..

rrolsbe
Posts: 185
Joined: Wed 15 Nov 2006, 21:53

How does this apply to /tmp which is also in RAM

#3 Post by rrolsbe »

Barry

Since /tmp is also in RAM and it is not written back to the pup_save file, the size of the pup_save file should have no bearing on using storage in /tmp. Does it?

Regards
Ron

User avatar
tronkel
Posts: 1116
Joined: Fri 30 Sep 2005, 11:27
Location: Vienna Austria
Contact:

puppy.swp

#4 Post by tronkel »

Is here any point in having a puppy.swp swap-file on the USB stick?

How would reads/writes to the swap-file affect the operating life of the stick?. Would it speed things up to any significant extent anyway (i.e is it worth having a swap-file in PUPMODE13 at all especially when encryption is involved?)
Life is too short to spend it in front of a computer

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#5 Post by BarryK »

No, you do not want a swap file on the usb drive. It would be slow, and would hammer certain locations in the Flash memory and probably kill the drive pretty quickly.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

Re: How does this apply to /tmp which is also in RAM

#6 Post by BarryK »

rrolsbe wrote:Barry

Since /tmp is also in RAM and it is not written back to the pup_save file, the size of the pup_save file should have no bearing on using storage in /tmp. Does it?

Regards
Ron
True, but the script is not that clever ...someone will have to modify it to exclude /tmp ...anyone game?

User avatar
Gekko
Posts: 443
Joined: Sat 22 Jul 2006, 09:57
Location: Sydney, New South Wales

#7 Post by Gekko »

generate the size of the pupsave, generate the size of the /tmp, pupsave minus /tmp, printf.

wdef
Posts: 91
Joined: Fri 13 Apr 2007, 20:16

#8 Post by wdef »

Using unencrypted swap with encryption is not a good idea if you're at all serious about securing data with encryption. You just don't know what plaintext or keys are getting swapped out

I haven't looked at the encryption stuff in this Puppy but it should ideally warn the user to disable swap if using encryption, or, better, it should encrypt swap.

But of course serious people use loop-aes with multiple gpg encrypted keys and not that cryptoloop ....(just kidding!!)

rrolsbe
Posts: 185
Joined: Wed 15 Nov 2006, 21:53

Agree, if used, encrypted swap is a must for good security.

#9 Post by rrolsbe »

All of the machines I boot puppy from have enough RAM that a swap file is not required; however, it would be nice if I could store the encrypted pup_save file on the puppy boot CD and use it in a read only mode, IE.. no RW media required to store the pup_save file. As a work around, I currently store the pup_save file on the CD with a diffent name then copy/rename it to R/W media, reboot to access contents and delete when finished. Also, the encrypted pup_save file contents is available as clear text while in use. I like the idea of having the option of running totally from optical boot media then simply powering the computer off at the end of the sessions, IE.. great mode for open wireless.

Regards
Ron

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#10 Post by PaulBx1 »

Seems like a lot of work to avoid having to do a shutdown. :wink: But maybe I miss the point.
Also, the encrypted pup_save file contents is available as clear text while in use.
I believe the pup_save file proper remains encrypted, but of course stuff read from there into memory is cleartext while in memory (and in swap, if one is so rash as to use it). If that's so, that's about as good as it gets anywhere in the world of encryption. Correct me if I'm wrong...


I haven't looked at the encryption stuff in this Puppy but it should ideally warn the user to disable swap if using encryption, or, better, it should encrypt swap.
I have nagged about that, in vain I think (I haven't done anything with 2.16 so don't know for sure). Actually I lobbied to get the boot to happen with swap off by default if encryption is used.

I had decided to delete my swap partition so I wouldn't need to run a swapoff command in my rc.local to disable the swap, but when I did that, puppy created a pupswap.swp file for me anyway, without even asking me if I wanted it! :cry: So now I have "swapoff /initrd/mnt/dev_save/pupswap.swp" in my rc.local...

John Doe did some work with dmcrypt which would have allowed encrypted swap, but at the time Puppy's use of Busybox commands made it impossible. The offending command has now been made a full one, so a hard-core encryption fan might take another shot at it. Search the forum for his work on this.

Bottom line, if you use encryption now, you need to disable swap manually and have enough memory not to need it. A simple warning to this effect sure would be worthwhile, if nothing else.
But of course serious people use loop-aes with multiple gpg encrypted keys and not that cryptoloop ....(just kidding!!)
Well, we are only half serious around here. :wink:

As someone who has done his fair share of sniping at cryptoloop, I can sympathize. But hey, it's a heck of a lot better than what we had before! While I wouldn't hide stolen cruise missile plans in my pupsave, heh heh, I figure good (or bad) old cryptoloop delivers 95% or 98% of the utility of loop-aes and dmcrypt. And that's nothing to sneer at...

It wouldn't hurt for another hard-core encryption geek to join the Puppy development team. Maybe some day we could have more up-to-date encryption alternatives and features. As it is right now, though, I'm happy.

Post Reply