The following commit has been merged into the irq/core branch of tip:
Commit-ID: 8a94c1ab34d53476617f83610521cfb6674db8d4
Gitweb:
https://git.kernel.org/tip/8a94c1ab34d53476617f83610521cfb6674db8d4
Author:Ingo Rohloff
AuthorDate:Wed, 22 Apr 2020 13:28:57 +02:00
Committer
> > Locking twice? But what happens if some program calls loop_set_status more
> > than once? Losetup doesn't, but if such program exists, locking is still
> > screwed.
>
> No, it calls loop_release_xfer always before init_xfer, which will release
> the "permanent" use count.
Calling lock twice
Locking twice? But what happens if some program calls loop_set_status more
than once? Losetup doesn't, but if such program exists, locking is still
screwed.
No, it calls loop_release_xfer always before init_xfer, which will release
the permanent use count.
Calling lock twice in
Hi,
There is a bug in the locking scheme for the encryption functions,
which can be hooked into the loop device. I have a patch
which resolves the problem. First what happens:
If you do (for example) a losetup -e twofish /dev/loop0 test.lop
the following happens:
The loop0 device gets opened
Hi,
There is a bug in the locking scheme for the encryption functions,
which can be hooked into the loop device. I have a patch
which resolves the problem. First what happens:
If you do (for example) a losetup -e twofish /dev/loop0 test.lop
the following happens:
The loop0 device gets opened
n probably not ...
so long
Ingo Rohloff
PS: Burning a CD was only one trigger for the problem. In fact
accessing my CDBurner in any way (like mounting a CD, or reading
from it) will lock up my whole computer, as long as
"hdparm -d1 -X34" isn't called.
It also doesn't
n probably not ...
so long
Ingo Rohloff
PS: Burning a CD was only one trigger for the problem. In fact
accessing my CDBurner in any way (like mounting a CD, or reading
from it) will lock up my whole computer, as long as
"hdparm -d1 -X34" isn't called.
It also doesn't
Hi,
I found a way to crash an SMP 2.4-test11 kernel:
1. Create a BIG file (lets say about 300-400 MByte)
2. use losetup and the loop device to create an
ext2 filesystem within the file
3. mount the file
4. copy huge amounts of data into the file.
(for example copy your /usr directory into
Hi,
I found a way to crash an SMP 2.4-test11 kernel:
1. Create a BIG file (lets say about 300-400 MByte)
2. use losetup and the loop device to create an
ext2 filesystem within the file
3. mount the file
4. copy huge amounts of data into the file.
(for example copy your /usr directory into
> Ingo, do you have a BP6? Make sure you have the latest BIOS for your
> motherboard, there have been many BIOS updates for some dual-Celeron
> motherboards.
I have to admit that I'm not sure what kind of dual board I got
(i have to have a closer look).
The reason is that this board is
Ingo, do you have a BP6? Make sure you have the latest BIOS for your
motherboard, there have been many BIOS updates for some dual-Celeron
motherboards.
I have to admit that I'm not sure what kind of dual board I got
(i have to have a closer look).
The reason is that this board is orgiginally
Hi,
First a description of my machine:
I use a Dual Celeron System with glibc-2.1.3 and
linux-2.4test10 .
For information on peripherial devices I give the output of /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host
Hi,
First a description of my machine:
I use a Dual Celeron System with glibc-2.1.3 and
linux-2.4test10 .
For information on peripherial devices I give the output of /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host
>
> > > IV generation is what I am worried about.
> > > There is a paper about why it is a bad idea to use
> > > sequence numbers for CBC IV's. I just have to find the reference to it.
> > Does this mean sequence as in 0,1,2,3,4 ... or does this mean
> > any pre-calculate-able sequence ? In the
Reed Petty wrote:
> Caution is advised when depending upon crypto systems that use relative
> block numbers as IV. The security may not be a strong as hoped.
> There are some who believe that "not unique" IVs (across multiple
> filesystems) facilitates some methods of cryptanalysis.
...
Ahh
> So, the only provision that needs to be made to ensure backwards
> compatibility (both with the kerneli patch and other modules that still
> use absolute block numbers) is a way to switch between the new approach
> and the old, defaulting to the new. The easiest way to do this, IMO, is
> to
> BTW, kerneli would also not handle the case of switching block sizes anyways,
> with relative IVs or not, because it does not restart its CFB chain inside
> the device blocks every 512 byte blocks with a new IV.
My (inofficial) patch set for twofish and blowfish does though :-).
I'm not sure
> _I_ can use my approach, but not yours, to bring my already existing
> crypted fs into the new state. The losetup option to set the encryption
> chunk size is used only once for each fs, but at that one time you can
> do:
Ok, I understand what you mean.
> Q> losetup -e blowfish
Ian Sterling wrote:
> But, it seems to me that being able to have a different IV for
> each filesystem would be a good thing, but having it depend on something
> as volatile as sector of the disk, seems bad.
It's not the sector of the _disk_. It's the requested sector
of the loop device. The
_I_ can use my approach, but not yours, to bring my already existing
crypted fs into the new state. The losetup option to set the encryption
chunk size is used only once for each fs, but at that one time you can
do:
Ok, I understand what you mean.
Q losetup -e blowfish --use-fs-blocksize \
BTW, kerneli would also not handle the case of switching block sizes anyways,
with relative IVs or not, because it does not restart its CFB chain inside
the device blocks every 512 byte blocks with a new IV.
My (inofficial) patch set for twofish and blowfish does though :-).
I'm not sure if
So, the only provision that needs to be made to ensure backwards
compatibility (both with the kerneli patch and other modules that still
use absolute block numbers) is a way to switch between the new approach
and the old, defaulting to the new. The easiest way to do this, IMO, is
to allocate
Reed Petty wrote:
Caution is advised when depending upon crypto systems that use relative
block numbers as IV. The security may not be a strong as hoped.
There are some who believe that "not unique" IVs (across multiple
filesystems) facilitates some methods of cryptanalysis.
...
Ahh
Hi again,
Marc Mutz wrote:
> > The loop device supports different IVs;
> > the IVs are initilized with the requested block
> > number.
> > I believe a better way is to use the requested
> > sector number from CURRENT->sector.
> > Using this value should make the encryption and decryption
> >
Hi again,
Marc Mutz wrote:
The loop device supports different IVs;
the IVs are initilized with the requested block
number.
I believe a better way is to use the requested
sector number from CURRENT-sector.
Using this value should make the encryption and decryption
process
Hi,
First some explanation. Most cryption algorithms initialize
the cryption process with some init values, called IV (by me :-).
This means that two identical clear messages will give
different encrypted messages, if different IVs are used.
The loop device supports different IVs;
the IVs are
Hi,
First some explanation. Most cryption algorithms initialize
the cryption process with some init values, called IV (by me :-).
This means that two identical clear messages will give
different encrypted messages, if different IVs are used.
The loop device supports different IVs;
the IVs are
27 matches
Mail list logo
