Torvalds Warns the World: Don't Use the Linux 5.12-rc1 Kernel

[elw3]

A real example would be brute-force cracking a zipfile locked with a password. Even small differences in speed help a lot.

I doubt ram speed has any influence at that at all. Of course i dont know how zip cracking works. If it can only verify the password after trying to open the whole thing, then yes it impacts a lot.
If its just a verification of a header the impact would be zero.
But my point here rather was personal speaking: My system is as snappy as i need it, any further would be a pointless waste of energy, thus i keep my ram as slow as possible.

 

[FBnil]

@elw3 Zipfiles are weird: the index data (central directory) is at the end of the file. So, yes, you use a $pass to decrypt the first part to check for PK (0x04034b50) 4CC (the 4 first bytes of a file usually give you the filetype).
Then decompress until you find a central directory marker, and check if that decompresses to something useful. So you need the whole file (which by Linux caching means it is read to memory only once, if you have the memory)
This central directory at the end means it can be used to append files into the zip file, but you can not use it to stream decompress because it needs to read the whole file first.

 

[Djoga'Ro]

For developing certain type of scripts that process a large input datafile I also made use of a RAM disk that made re-running code so much faster

Ain't that a waste of RAM? One should rather use tmpfs. ?

 

[levi]

tmpfs is a ram disc I always thought.

 

[Djoga'Ro]

A RAM disk when a storage driver allocates some memory and uses that as its own backend to serve you a blockdevice you can write to. Linux will still do caching for that block device.
tmpfs is no block device, but memory backed storage and Linux knows to do no caching.
At least that's how I understand it.

 

[FBnil]

Ain't that a waste of RAM? One should rather use tmpfs. ?

Oh, I didn't mean a "brd.ko Ramdisk", just a custom tmpfs. But it DOES have less effect on the system. So when I fill a tmpfs, then things get pushed into swap, but with a real ramdrive, they don't, because they are truly allocated. I havent thought about the double caching it could be doing. Good point.

Modern Linux come with a /dev/shm (shared memory tmpfs). By default they are half of the RAM, but you can resize them:

mount -o remount,size=3G /dev/shm

(or as much RAM as you can spare) then

cat /dev/zero > /dev/shm/file.tmp

Then check "free -h" again.

edit: Note that the remount is not without risk: all data will be wiped, so if a program is using it, it might crash. So you might just want to define your own with a separate mountpoint.

 

[netcat]

i like the direction this thread is going
i wasn't even really aware of /dev/shm
i'm gonna find uses for it

 

[FBnil]

@netcat I use something like this:

#!/usr/bin/bash

# first we check if /dev/shm is writeable if not, fallback to /tmp
TMPDIR=/dev/shm
if [ ! -d $TMPDIR ] || [ ! -w $TMPDIR ]; then
    TMPDIR=/tmp
fi
TMPFILE=$(mktemp $TMPDIR/myprogram.XXXXXXXXXX)

if [ ! -f $TMPFILE ];then
    echo "Could not create a temporal file, aborting"
    exit 2
fi

# Generate an auto-delete of the temporal file on exit
remove_tmpfile() {
    [[ -f $TMPFILE ]] || return
    rm -rf "$TMPFILE"
}
trap remove_tmpfile INT TERM EXIT

# File exists while this bash script is running, it wont be after it ends
ls -la $TMPFILE

 

[levi]

From my recollection, having /dev/shm mounted as tmpfs predated having a dedicated /tmp folder, but I may be wrong. But yeah, I'd expect if you have a /tmp folder you're very likely to have a /dev/shm folder as well.

As far as I know /dev/shm wasn't really designed for users to put stuff in. It was designed to support interprocess communication. That said I do use it myself to decrypt my password store into which I don't want to save to disk and then have to worry about destroying that more completely when it comes to disposing of it. I've not seen any programs leaving stuff in there for any length of time, although the model that IPC follows I guess stuff in there should only be there momentarily, being deleted as soon as the receiving process has consumed it.

 

[comradekingu]

Torvalds goes on to point out that if you aren't using swap at all, this problem wouldn't bite you.

Yeeees.

 

[netcat]

I do use it myself to decrypt my password store into which I don't want to save to disk

omg this my use-case too..
lemme guess: you use gpg, have a wrapper to make sure you're re-encrypting with the same key, and you couldn't get it to work with pipes?
let's come up with a better solution - keep plaintext in process memory only!
this is a real vulnerability to my data. it would be trivial for a cracker to modify my (perl) script to send my sensitive data wherever.
if they have access to my system - of course, which they don't because it's off
i guess what i'm really guarding against is someone getting hold of my disk - ok. but i have introduced a vulnerability.
happy to talk about it here openly, in true open source spirit

 

[FBnil]

No system is truly secure when you need the unencrypted version.
I keep my password in environment variables, but you can still poke in /proc to get it back.
All you can do is minimize the time you have it present. Delete as soon as you dont need it anymore.
The only secure way to use swap (which can hold your unencrypted data) is to fully encrypt your system. All of it.
I remember Snowden in an interview put a blanket on top of his head to type in his password to open his laptop. As pin needle camera's exist. Or good microphones, that can actually (with multiple microphones) deduce which key was pressed by it's sound (concentrate on, for example, the spacebar; you will hear that it is different sounding, just like the shift. Press qpqpqp Can you hear the difference? So might microphones).The video display actually leaks the image too (in a CCC they showed how, with a cheap laptop, they could read the screen using the leaked radiowave signal coming from the laptop)
I like keepassXC, it write the password in combinations with capslock randomly going on/off.


for that eavesdropping thing: DDG: rfi tempest


Kind of reminds me of the movie "The Darkest Hour", where this guy had a faraday cage with his electronics inside.

 

[levi]

omg this my use-case too..
lemme guess: you use gpg, have a wrapper to make sure you're re-encrypting with the same key, and you couldn't get it to work with pipes?
let's come up with a better solution - keep plaintext in process memory only!

I don't script it, it's simply enrcypted with the private key of a key in my local keystore that I unlock into my /dev/shm space.

Something like

gpg -o /dev/shm/code -d code.encoded

And then if it's been changed in my ram disc to e.g. reset a password, I do:

gpg -o code.encoded -r my_secret_key_name -e /dev/shm/code

On top of that I write the password store (my code file) in a human derived encoding. I look up the word in a word list and take the line number and mangle that with reversible mathematics to write it down.

 

[netcat]

ultra portable mini computers are easy to misplace
lack of encryption makes the pyra less secure than most smartphones
this is unfortunate, especially since we are elite technologists
pyra should have /home encrypted by default
zfs anyone?

 

[λ the β-Redex Reducer]

I use BTRFS with LUKS for encryption on my laptop. But I totally agree that the Pyra needs encryption to be secure. But only encrypting the home directory is not secure because the other directories could also contain secret data, even if only temporary. Best is to encrypt the entire system except for /boot. But only the entire /home would definitely be a good start and much better than nothing.

 

[pyrat]

But how do you want that to be ? If the disk is encrypted from factory then ED would have the keys to all the Pyras. Isn't it better to let every one encrypt it by themselves ? You could have some installer that generates the key before installing, but isn't that overcomplicated ? How do you know the installer isn't sending the key elsewhere ? I like encrypted devices, but I don't like the manufacturer doing it. And if I was ED I wouldn't want the responsability either.

 

[sebt3]

I use BTRFS with LUKS for encryption on my laptop. But I totally agree that the Pyra needs encryption to be secure. But only encrypting the home directory is not secure because the other directories could also contain secret data, even if only temporary. Best is to encrypt the entire system except for /boot. But only the entire /home would definitely be a good start and much better than nothing.

I clearly disagree. The most sensible data I'm going to have on my pyra will be ... my game saves. No need to crypt this.
I never understound this vision "everything should be encrypted secure and stuff" It's only worth it *if* you have data to secure, else all you do is reduce your performance and add failure points..
The later argument will be the one that make ED agree with me

 

[netcat]

@sebt3 what year is it?
every stupid mobile device is encrypted
we are crypto anarchists
we are freedom loving hackers
privacy is an innate right that we invoke continuously
don't give me technical excuses to existential needs
if it's substantial overhead on the pyra that's a design flaw
a serious shortcoming and lack of foresight
i'm not telling anyone to encrypt their psx roms
but ~/.ssh as well as all the keystores you're not aware of should be
secure by default
this is the unix way, in the mobile age
in crypto we trust

 

[FBnil]

Well, Encryption lowers the per.for.ma.n.ce. But sure, why not. And if you get hacked from the outside... well, let's hope they can only access the smallest unencrypted part, and not %d^@v F NOCARRIER

It's only worth it *if* you have data to secure,

The Pyra will be a rooted Mobile Phone eventually, right? My conversations and pictures are valuable to me.


@netcat chmod -r 777 ~/.ssh ! Information want to be freeeeeeee

 

[Bosbeetle]

and pictures

Good thing the pyra doesnt have a camera!