Oopsing cryptoapi (or loop device?) on 2.6.*

Oopsing cryptoapi (or loop device?) on 2.6.*

[Michal Kwolek]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

Hi,

I've got a reproducible oops when using cryptoloop on vanilla 2.6.0,
2.6.1 and 2.6.2 (2.4.* works fine).

Way to reproduce:
dd if=/dev/urandom of=crypto bs=1024 count=some_size
losetup -e some_cipher /dev/loop0 crypto
#Any of those commands causes oops and hard lockup:
cp /dev/loop0 /dev/null
mkreiserfs /dev/loop0
mkfs.ext2 /dev/loop0

Loop without cryptoapi works fine:
dd if=/dev/urandom of=crypto bs=1024 count=some_size
losetup /dev/loop0 crypto
cp /dev/loop0 /dev/null
#ok, no oops

Sometimes it writes 10KB sometimes 10MB before it oopses. It may be just
coincidence but without HT enabled it lived longer. As it locks hard 
after oops I don't have oops messages in log. I have written down some:

1.
init: panic: Segmentation violation at 0x40126A83! Sleeping for 30 sec...

2.
Unable to handle kernel paging request at virtual address 87550c8a
EIP is at cleanup_bitmap_list +0x48/0x68
...

3.
Unable to handle kernel paging request at virtual address
EIP IS AT get_cnode +0x61/0x94
...

4.
Unable to handle kernel paging request at virtual address faad7260
EIP is at journal_mark_dirty +0x1b5
Calltrace:
flush_old_commits +0x113/0x16f
reiserfs_write_super +0x98/0x9a
sync_supers +0xd0/0xea
do_sync
sys_sync
syscall_call

5.
syncing...(after mkfs so it was almost done)
Unable to handle kernel paging request at virtual address 9756a996
EIP is at cleanup_bitmap_list +0xb/0xd4
Calltrace:
autoremove_wake_function
cleanup_freed_for_journal_list
...

6.
attempted to kill init
bad: schedulling while atomic
EIP is at add_wait_queue

And much more (mostly in FS code)

Tested ciphers: aes, blowfish (both as module and compiled in)

Filesystems with crypto file: ReiserFS, FAT

Tested sizes of crypto file: 50MB, 10GB

Tested disk drives and controllers:
ICH5 with WD120JB (pata), external
CMD649 (Kouwell 671A) with 80GB Seagate barracuda IV

Tested chipsets:
I865 (Asus P4P800), I875 (Abit IC7 G)

Other hardware: P4 2.6 (HT, SMP kernel), 1GB RAM (High memory support 
4GB). Thoroughly tested with memtest and mprime95.

See lspci and config in attachment.

Kernel is not tainted.

Write me please if additional information is need.

miho

PS. Excuse my poor english.

[-- Attachment #2: lspci.txt --]
[-- Type: text/plain, Size: 1265 bytes --]

0000:00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02)
0000:00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801EB USB (rev 02)
0000:00:1d.1 USB Controller: Intel Corp. 82801EB USB (rev 02)
0000:00:1d.2 USB Controller: Intel Corp. 82801EB USB (rev 02)
0000:00:1d.3 USB Controller: Intel Corp. 82801EB USB (rev 02)
0000:00:1d.7 USB Controller: Intel Corp. 82801EB USB2 (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI Bridge (rev c2)
0000:00:1f.0 ISA bridge: Intel Corp. 82801EB LPC Interface Controller (rev 02)
0000:00:1f.1 IDE interface: Intel Corp. 82801EB Ultra ATA Storage Controller (rev 02)
0000:00:1f.3 SMBus: Intel Corp. 82801EB SMBus Controller (rev 02)
0000:01:00.0 VGA compatible controller: nVidia Corporation NV35 [GeForce FX 5900] (rev a1)
0000:02:05.0 RAID bus controller: CMD Technology Inc PCI0649 (rev 02)
0000:02:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:02:07.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
0000:02:07.1 Input device controller: Creative Labs SB Audigy MIDI/Game port (rev 03)
0000:02:07.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port

[-- Attachment #3: config.txt --]
[-- Type: text/plain, Size: 22582 bytes --]

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_STANDALONE=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
# CONFIG_HPET_EMULATE_RTC is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_SOFTWARE_SUSPEND is not set
# CONFIG_PM_DISK is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set
CONFIG_ACPI_BOOT=y

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_USE_VECTOR is not set
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_HOTPLUG is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m

#
# Device Drivers
#

#
# Generic Driver Options
#

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_TASKFILE_IO=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
CONFIG_BLK_DEV_CMD64X=y
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_REPORT_LUNS is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX_CONFIG=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA23XX is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
# CONFIG_IP_NF_NAT is not set
# CONFIG_IP_NF_MANGLE is not set
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IP_NF_TARGET_ULOG is not set
# CONFIG_IP_NF_TARGET_TCPMSS is not set
# CONFIG_IP_NF_ARPTABLES is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
# CONFIG_PPPOE is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# Bluetooth support
#
# CONFIG_BT is not set

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD8111=m
# CONFIG_I2C_ELV is not set
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
# CONFIG_I2C_PARPORT_LIGHT is not set
CONFIG_I2C_PIIX4=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_VELLEMAN is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m

#
# I2C Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
# CONFIG_SENSORS_ASB100 is not set
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
# CONFIG_SND_RTCTIMER is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# PCI devices
#
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
CONFIG_SND_EMU10K1=y
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# ALSA USB devices
#
# CONFIG_SND_USB_AUDIO is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_XPAD is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network adaptors
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_BRLVGER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_TEST is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
CONFIG_DEVPTS_FS_XATTR=y
# CONFIG_DEVPTS_FS_SECURITY is not set
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-2"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
CONFIG_NLS_CODEPAGE_852=m
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
CONFIG_NLS_CODEPAGE_1250=m
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
CONFIG_FRAME_POINTER=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_TEST is not set

#
# Library routines
#
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jari Ruusu]

Michal Kwolek wrote:
> I've got a reproducible oops when using cryptoloop on vanilla 2.6.0,
> 2.6.1 and 2.6.2 (2.4.* works fine).
> 
> Way to reproduce:
> dd if=/dev/urandom of=crypto bs=1024 count=some_size
> losetup -e some_cipher /dev/loop0 crypto
> #Any of those commands causes oops and hard lockup:
> cp /dev/loop0 /dev/null
> mkreiserfs /dev/loop0
> mkfs.ext2 /dev/loop0
> 
> Loop without cryptoapi works fine:
> dd if=/dev/urandom of=crypto bs=1024 count=some_size
> losetup /dev/loop0 crypto
> cp /dev/loop0 /dev/null
> #ok, no oops

Can you try again using loop-AES? loop-AES does not fall apart like the
mainline implementation does. loop-AES is here:

http://mail.nl.linux.org/linux-crypto/2004-02/msg00006.html

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[bill davidsen]

In article <402A4B52.1080800@centrum.cz>,
Michal Kwolek  <miho@centrum.cz> wrote:

| I've got a reproducible oops when using cryptoloop on vanilla 2.6.0,
| 2.6.1 and 2.6.2 (2.4.* works fine).
| 
| Way to reproduce:
| dd if=/dev/urandom of=crypto bs=1024 count=some_size
| losetup -e some_cipher /dev/loop0 crypto
| #Any of those commands causes oops and hard lockup:
| cp /dev/loop0 /dev/null
| mkreiserfs /dev/loop0
| mkfs.ext2 /dev/loop0
| 
| Loop without cryptoapi works fine:
| dd if=/dev/urandom of=crypto bs=1024 count=some_size
| losetup /dev/loop0 crypto
| cp /dev/loop0 /dev/null
| #ok, no oops

You have something else going on here (hardware?), I do this on a
regular basis, although I call it mke2fs when I make the f/s. No
problem yet, using aes, and doing it to create a nice device I can save
and use without overmuch worry.

| Sometimes it writes 10KB sometimes 10MB before it oopses. It may be just
| coincidence but without HT enabled it lived longer. As it locks hard 
| after oops I don't have oops messages in log. I have written down some:
| 
| 1.
| init: panic: Segmentation violation at 0x40126A83! Sleeping for 30 sec...
| 
| 2.
| Unable to handle kernel paging request at virtual address 87550c8a
| EIP is at cleanup_bitmap_list +0x48/0x68
| ...
| 
| 3.
| Unable to handle kernel paging request at virtual address
| EIP IS AT get_cnode +0x61/0x94
| ...
| 
| 4.
| Unable to handle kernel paging request at virtual address faad7260
| EIP is at journal_mark_dirty +0x1b5
| Calltrace:
| flush_old_commits +0x113/0x16f
| reiserfs_write_super +0x98/0x9a
| sync_supers +0xd0/0xea
| do_sync
| sys_sync
| syscall_call
| 
| 5.
| syncing...(after mkfs so it was almost done)
| Unable to handle kernel paging request at virtual address 9756a996
| EIP is at cleanup_bitmap_list +0xb/0xd4
| Calltrace:
| autoremove_wake_function
| cleanup_freed_for_journal_list
| ...
| 
| 6.
| attempted to kill init
| bad: schedulling while atomic
| EIP is at add_wait_queue
| 
| And much more (mostly in FS code)
| 
| Tested ciphers: aes, blowfish (both as module and compiled in)
| 
| Filesystems with crypto file: ReiserFS, FAT
| 
| Tested sizes of crypto file: 50MB, 10GB
| 
| Tested disk drives and controllers:
| ICH5 with WD120JB (pata), external
| CMD649 (Kouwell 671A) with 80GB Seagate barracuda IV
| 
| Tested chipsets:
| I865 (Asus P4P800), I875 (Abit IC7 G)
| 
| Other hardware: P4 2.6 (HT, SMP kernel), 1GB RAM (High memory support 
| 4GB). Thoroughly tested with memtest and mprime95.
| 
| See lspci and config in attachment.
| 
| Kernel is not tainted.
| 
| Write me please if additional information is need.
| 
| miho
| 
| PS. Excuse my poor english.
| 
| --------------000303030500070207010703
| Content-Type: text/plain;
|  name="lspci.txt"
| Content-Transfer-Encoding: 7bit
| Content-Disposition: inline;
|  filename="lspci.txt"
| 
| 0000:00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02)
| 0000:00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02)
| 0000:00:1d.0 USB Controller: Intel Corp. 82801EB USB (rev 02)
| 0000:00:1d.1 USB Controller: Intel Corp. 82801EB USB (rev 02)
| 0000:00:1d.2 USB Controller: Intel Corp. 82801EB USB (rev 02)
| 0000:00:1d.3 USB Controller: Intel Corp. 82801EB USB (rev 02)
| 0000:00:1d.7 USB Controller: Intel Corp. 82801EB USB2 (rev 02)
| 0000:00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI Bridge (rev c2)
| 0000:00:1f.0 ISA bridge: Intel Corp. 82801EB LPC Interface Controller (rev 02)
| 0000:00:1f.1 IDE interface: Intel Corp. 82801EB Ultra ATA Storage Controller (rev 02)
| 0000:00:1f.3 SMBus: Intel Corp. 82801EB SMBus Controller (rev 02)
| 0000:01:00.0 VGA compatible controller: nVidia Corporation NV35 [GeForce FX 5900] (rev a1)
| 0000:02:05.0 RAID bus controller: CMD Technology Inc PCI0649 (rev 02)
| 0000:02:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
| 0000:02:07.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
| 0000:02:07.1 Input device controller: Creative Labs SB Audigy MIDI/Game port (rev 03)
| 0000:02:07.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port
| 
| --------------000303030500070207010703
| Content-Type: text/plain;
|  name="config.txt"
| Content-Transfer-Encoding: 7bit
| Content-Disposition: inline;
|  filename="config.txt"
| 
| #
| # Automatically generated make config: don't edit
| #
| CONFIG_X86=y
| CONFIG_MMU=y
| CONFIG_UID16=y
| CONFIG_GENERIC_ISA_DMA=y
| 
| #
| # Code maturity level options
| #
| CONFIG_EXPERIMENTAL=y
| CONFIG_CLEAN_COMPILE=y
| CONFIG_STANDALONE=y
| 
| #
| # General setup
| #
| CONFIG_SWAP=y
| CONFIG_SYSVIPC=y
| CONFIG_BSD_PROCESS_ACCT=y
| CONFIG_SYSCTL=y
| CONFIG_LOG_BUF_SHIFT=15
| # CONFIG_IKCONFIG is not set
| # CONFIG_EMBEDDED is not set
| CONFIG_KALLSYMS=y
| CONFIG_FUTEX=y
| CONFIG_EPOLL=y
| CONFIG_IOSCHED_NOOP=y
| CONFIG_IOSCHED_AS=y
| CONFIG_IOSCHED_DEADLINE=y
| # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
| 
| #
| # Loadable module support
| #
| CONFIG_MODULES=y
| # CONFIG_MODULE_UNLOAD is not set
| CONFIG_OBSOLETE_MODPARM=y
| # CONFIG_MODVERSIONS is not set
| CONFIG_KMOD=y
| 
| #
| # Processor type and features
| #
| CONFIG_X86_PC=y
| # CONFIG_X86_VOYAGER is not set
| # CONFIG_X86_NUMAQ is not set
| # CONFIG_X86_SUMMIT is not set
| # CONFIG_X86_BIGSMP is not set
| # CONFIG_X86_VISWS is not set
| # CONFIG_X86_GENERICARCH is not set
| # CONFIG_X86_ES7000 is not set
| # CONFIG_M386 is not set
| # CONFIG_M486 is not set
| # CONFIG_M586 is not set
| # CONFIG_M586TSC is not set
| # CONFIG_M586MMX is not set
| # CONFIG_M686 is not set
| # CONFIG_MPENTIUMII is not set
| # CONFIG_MPENTIUMIII is not set
| CONFIG_MPENTIUM4=y
| # CONFIG_MK6 is not set
| # CONFIG_MK7 is not set
| # CONFIG_MK8 is not set
| # CONFIG_MELAN is not set
| # CONFIG_MCRUSOE is not set
| # CONFIG_MWINCHIPC6 is not set
| # CONFIG_MWINCHIP2 is not set
| # CONFIG_MWINCHIP3D is not set
| # CONFIG_MCYRIXIII is not set
| # CONFIG_MVIAC3_2 is not set
| # CONFIG_X86_GENERIC is not set
| CONFIG_X86_CMPXCHG=y
| CONFIG_X86_XADD=y
| CONFIG_X86_L1_CACHE_SHIFT=7
| CONFIG_RWSEM_XCHGADD_ALGORITHM=y
| CONFIG_X86_WP_WORKS_OK=y
| CONFIG_X86_INVLPG=y
| CONFIG_X86_BSWAP=y
| CONFIG_X86_POPAD_OK=y
| CONFIG_X86_GOOD_APIC=y
| CONFIG_X86_INTEL_USERCOPY=y
| CONFIG_X86_USE_PPRO_CHECKSUM=y
| # CONFIG_HPET_TIMER is not set
| # CONFIG_HPET_EMULATE_RTC is not set
| CONFIG_SMP=y
| CONFIG_NR_CPUS=2
| CONFIG_PREEMPT=y
| CONFIG_X86_LOCAL_APIC=y
| CONFIG_X86_IO_APIC=y
| CONFIG_X86_TSC=y
| # CONFIG_X86_MCE is not set
| # CONFIG_TOSHIBA is not set
| # CONFIG_I8K is not set
| # CONFIG_MICROCODE is not set
| # CONFIG_X86_MSR is not set
| # CONFIG_X86_CPUID is not set
| # CONFIG_EDD is not set
| # CONFIG_NOHIGHMEM is not set
| CONFIG_HIGHMEM4G=y
| # CONFIG_HIGHMEM64G is not set
| CONFIG_HIGHMEM=y
| # CONFIG_HIGHPTE is not set
| # CONFIG_MATH_EMULATION is not set
| CONFIG_MTRR=y
| CONFIG_HAVE_DEC_LOCK=y
| 
| #
| # Power management options (ACPI, APM)
| #
| CONFIG_PM=y
| # CONFIG_SOFTWARE_SUSPEND is not set
| # CONFIG_PM_DISK is not set
| 
| #
| # ACPI (Advanced Configuration and Power Interface) Support
| #
| # CONFIG_ACPI is not set
| CONFIG_ACPI_BOOT=y
| 
| #
| # APM (Advanced Power Management) BIOS Support
| #
| CONFIG_APM=y
| # CONFIG_APM_IGNORE_USER_SUSPEND is not set
| # CONFIG_APM_DO_ENABLE is not set
| # CONFIG_APM_CPU_IDLE is not set
| # CONFIG_APM_DISPLAY_BLANK is not set
| # CONFIG_APM_RTC_IS_GMT is not set
| # CONFIG_APM_ALLOW_INTS is not set
| CONFIG_APM_REAL_MODE_POWER_OFF=y
| 
| #
| # CPU Frequency scaling
| #
| # CONFIG_CPU_FREQ is not set
| 
| #
| # Bus options (PCI, PCMCIA, EISA, MCA, ISA)
| #
| CONFIG_PCI=y
| # CONFIG_PCI_GOBIOS is not set
| # CONFIG_PCI_GODIRECT is not set
| CONFIG_PCI_GOANY=y
| CONFIG_PCI_BIOS=y
| CONFIG_PCI_DIRECT=y
| # CONFIG_PCI_USE_VECTOR is not set
| # CONFIG_PCI_LEGACY_PROC is not set
| CONFIG_PCI_NAMES=y
| # CONFIG_ISA is not set
| # CONFIG_MCA is not set
| # CONFIG_SCx200 is not set
| # CONFIG_HOTPLUG is not set
| 
| #
| # Executable file formats
| #
| CONFIG_BINFMT_ELF=y
| CONFIG_BINFMT_AOUT=m
| CONFIG_BINFMT_MISC=m
| 
| #
| # Device Drivers
| #
| 
| #
| # Generic Driver Options
| #
| 
| #
| # Memory Technology Devices (MTD)
| #
| # CONFIG_MTD is not set
| 
| #
| # Parallel port support
| #
| # CONFIG_PARPORT is not set
| 
| #
| # Plug and Play support
| #
| 
| #
| # Block devices
| #
| # CONFIG_BLK_DEV_FD is not set
| # CONFIG_BLK_CPQ_DA is not set
| # CONFIG_BLK_CPQ_CISS_DA is not set
| # CONFIG_BLK_DEV_DAC960 is not set
| # CONFIG_BLK_DEV_UMEM is not set
| CONFIG_BLK_DEV_LOOP=y
| CONFIG_BLK_DEV_CRYPTOLOOP=y
| CONFIG_BLK_DEV_NBD=m
| # CONFIG_BLK_DEV_RAM is not set
| # CONFIG_BLK_DEV_INITRD is not set
| # CONFIG_LBD is not set
| 
| #
| # ATA/ATAPI/MFM/RLL support
| #
| CONFIG_IDE=y
| CONFIG_BLK_DEV_IDE=y
| 
| #
| # Please see Documentation/ide.txt for help/info on IDE drives
| #
| # CONFIG_BLK_DEV_HD_IDE is not set
| CONFIG_BLK_DEV_IDEDISK=y
| CONFIG_IDEDISK_MULTI_MODE=y
| # CONFIG_IDEDISK_STROKE is not set
| CONFIG_BLK_DEV_IDECD=y
| # CONFIG_BLK_DEV_IDETAPE is not set
| # CONFIG_BLK_DEV_IDEFLOPPY is not set
| # CONFIG_BLK_DEV_IDESCSI is not set
| # CONFIG_IDE_TASK_IOCTL is not set
| CONFIG_IDE_TASKFILE_IO=y
| 
| #
| # IDE chipset support/bugfixes
| #
| CONFIG_IDE_GENERIC=y
| # CONFIG_BLK_DEV_CMD640 is not set
| CONFIG_BLK_DEV_IDEPCI=y
| CONFIG_IDEPCI_SHARE_IRQ=y
| # CONFIG_BLK_DEV_OFFBOARD is not set
| CONFIG_BLK_DEV_GENERIC=y
| # CONFIG_BLK_DEV_OPTI621 is not set
| # CONFIG_BLK_DEV_RZ1000 is not set
| CONFIG_BLK_DEV_IDEDMA_PCI=y
| # CONFIG_BLK_DEV_IDEDMA_FORCED is not set
| CONFIG_IDEDMA_PCI_AUTO=y
| # CONFIG_IDEDMA_ONLYDISK is not set
| # CONFIG_IDEDMA_PCI_WIP is not set
| CONFIG_BLK_DEV_ADMA=y
| # CONFIG_BLK_DEV_AEC62XX is not set
| # CONFIG_BLK_DEV_ALI15X3 is not set
| # CONFIG_BLK_DEV_AMD74XX is not set
| CONFIG_BLK_DEV_CMD64X=y
| # CONFIG_BLK_DEV_TRIFLEX is not set
| # CONFIG_BLK_DEV_CY82C693 is not set
| # CONFIG_BLK_DEV_CS5520 is not set
| # CONFIG_BLK_DEV_CS5530 is not set
| # CONFIG_BLK_DEV_HPT34X is not set
| # CONFIG_BLK_DEV_HPT366 is not set
| # CONFIG_BLK_DEV_SC1200 is not set
| CONFIG_BLK_DEV_PIIX=y
| # CONFIG_BLK_DEV_NS87415 is not set
| # CONFIG_BLK_DEV_PDC202XX_OLD is not set
| # CONFIG_BLK_DEV_PDC202XX_NEW is not set
| # CONFIG_BLK_DEV_SVWKS is not set
| # CONFIG_BLK_DEV_SIIMAGE is not set
| # CONFIG_BLK_DEV_SIS5513 is not set
| # CONFIG_BLK_DEV_SLC90E66 is not set
| # CONFIG_BLK_DEV_TRM290 is not set
| # CONFIG_BLK_DEV_VIA82CXXX is not set
| CONFIG_BLK_DEV_IDEDMA=y
| # CONFIG_IDEDMA_IVB is not set
| CONFIG_IDEDMA_AUTO=y
| # CONFIG_DMA_NONPCI is not set
| # CONFIG_BLK_DEV_HD is not set
| 
| #
| # SCSI device support
| #
| CONFIG_SCSI=y
| # CONFIG_SCSI_PROC_FS is not set
| 
| #
| # SCSI support type (disk, tape, CD-ROM)
| #
| # CONFIG_BLK_DEV_SD is not set
| # CONFIG_CHR_DEV_ST is not set
| # CONFIG_CHR_DEV_OSST is not set
| # CONFIG_BLK_DEV_SR is not set
| # CONFIG_CHR_DEV_SG is not set
| 
| #
| # Some SCSI devices (e.g. CD jukebox) support multiple LUNs
| #
| # CONFIG_SCSI_MULTI_LUN is not set
| # CONFIG_SCSI_REPORT_LUNS is not set
| # CONFIG_SCSI_CONSTANTS is not set
| # CONFIG_SCSI_LOGGING is not set
| 
| #
| # SCSI low-level drivers
| #
| # CONFIG_BLK_DEV_3W_XXXX_RAID is not set
| # CONFIG_SCSI_ACARD is not set
| # CONFIG_SCSI_AACRAID is not set
| # CONFIG_SCSI_AIC7XXX is not set
| # CONFIG_SCSI_AIC7XXX_OLD is not set
| # CONFIG_SCSI_AIC79XX is not set
| # CONFIG_SCSI_ADVANSYS is not set
| # CONFIG_SCSI_MEGARAID is not set
| # CONFIG_SCSI_SATA is not set
| # CONFIG_SCSI_BUSLOGIC is not set
| # CONFIG_SCSI_CPQFCTS is not set
| # CONFIG_SCSI_DMX3191D is not set
| # CONFIG_SCSI_EATA is not set
| # CONFIG_SCSI_EATA_PIO is not set
| # CONFIG_SCSI_FUTURE_DOMAIN is not set
| # CONFIG_SCSI_GDTH is not set
| # CONFIG_SCSI_IPS is not set
| # CONFIG_SCSI_INIA100 is not set
| # CONFIG_SCSI_SYM53C8XX_2 is not set
| # CONFIG_SCSI_QLOGIC_ISP is not set
| # CONFIG_SCSI_QLOGIC_FC is not set
| # CONFIG_SCSI_QLOGIC_1280 is not set
| CONFIG_SCSI_QLA2XXX_CONFIG=y
| # CONFIG_SCSI_QLA21XX is not set
| # CONFIG_SCSI_QLA22XX is not set
| # CONFIG_SCSI_QLA23XX is not set
| # CONFIG_SCSI_DC395x is not set
| # CONFIG_SCSI_DC390T is not set
| # CONFIG_SCSI_NSP32 is not set
| # CONFIG_SCSI_DEBUG is not set
| 
| #
| # Multi-device support (RAID and LVM)
| #
| # CONFIG_MD is not set
| 
| #
| # Fusion MPT device support
| #
| 
| #
| # IEEE 1394 (FireWire) support (EXPERIMENTAL)
| #
| # CONFIG_IEEE1394 is not set
| 
| #
| # I2O device support
| #
| # CONFIG_I2O is not set
| 
| #
| # Networking support
| #
| CONFIG_NET=y
| 
| #
| # Networking options
| #
| CONFIG_PACKET=y
| # CONFIG_PACKET_MMAP is not set
| # CONFIG_NETLINK_DEV is not set
| CONFIG_UNIX=y
| # CONFIG_NET_KEY is not set
| CONFIG_INET=y
| CONFIG_IP_MULTICAST=y
| # CONFIG_IP_ADVANCED_ROUTER is not set
| # CONFIG_IP_PNP is not set
| # CONFIG_NET_IPIP is not set
| # CONFIG_NET_IPGRE is not set
| # CONFIG_IP_MROUTE is not set
| # CONFIG_ARPD is not set
| # CONFIG_INET_ECN is not set
| # CONFIG_SYN_COOKIES is not set
| # CONFIG_INET_AH is not set
| # CONFIG_INET_ESP is not set
| # CONFIG_INET_IPCOMP is not set
| 
| #
| # IP: Virtual Server Configuration
| #
| # CONFIG_IP_VS is not set
| # CONFIG_IPV6 is not set
| # CONFIG_DECNET is not set
| # CONFIG_BRIDGE is not set
| CONFIG_NETFILTER=y
| # CONFIG_NETFILTER_DEBUG is not set
| 
| #
| # IP: Netfilter Configuration
| #
| CONFIG_IP_NF_CONNTRACK=y
| CONFIG_IP_NF_FTP=y
| # CONFIG_IP_NF_IRC is not set
| # CONFIG_IP_NF_TFTP is not set
| # CONFIG_IP_NF_AMANDA is not set
| # CONFIG_IP_NF_QUEUE is not set
| CONFIG_IP_NF_IPTABLES=y
| CONFIG_IP_NF_MATCH_LIMIT=y
| CONFIG_IP_NF_MATCH_IPRANGE=y
| CONFIG_IP_NF_MATCH_MAC=y
| CONFIG_IP_NF_MATCH_PKTTYPE=y
| CONFIG_IP_NF_MATCH_MARK=y
| CONFIG_IP_NF_MATCH_MULTIPORT=y
| CONFIG_IP_NF_MATCH_TOS=y
| CONFIG_IP_NF_MATCH_RECENT=y
| CONFIG_IP_NF_MATCH_ECN=y
| CONFIG_IP_NF_MATCH_DSCP=y
| CONFIG_IP_NF_MATCH_AH_ESP=y
| CONFIG_IP_NF_MATCH_LENGTH=y
| CONFIG_IP_NF_MATCH_TTL=y
| CONFIG_IP_NF_MATCH_TCPMSS=y
| CONFIG_IP_NF_MATCH_HELPER=y
| CONFIG_IP_NF_MATCH_STATE=y
| CONFIG_IP_NF_MATCH_CONNTRACK=y
| CONFIG_IP_NF_MATCH_OWNER=y
| CONFIG_IP_NF_FILTER=y
| CONFIG_IP_NF_TARGET_REJECT=y
| # CONFIG_IP_NF_NAT is not set
| # CONFIG_IP_NF_MANGLE is not set
| CONFIG_IP_NF_TARGET_LOG=y
| # CONFIG_IP_NF_TARGET_ULOG is not set
| # CONFIG_IP_NF_TARGET_TCPMSS is not set
| # CONFIG_IP_NF_ARPTABLES is not set
| 
| #
| # SCTP Configuration (EXPERIMENTAL)
| #
| CONFIG_IPV6_SCTP__=y
| # CONFIG_IP_SCTP is not set
| # CONFIG_ATM is not set
| # CONFIG_VLAN_8021Q is not set
| # CONFIG_LLC2 is not set
| # CONFIG_IPX is not set
| # CONFIG_ATALK is not set
| # CONFIG_X25 is not set
| # CONFIG_LAPB is not set
| # CONFIG_NET_DIVERT is not set
| # CONFIG_ECONET is not set
| # CONFIG_WAN_ROUTER is not set
| # CONFIG_NET_FASTROUTE is not set
| # CONFIG_NET_HW_FLOWCONTROL is not set
| 
| #
| # QoS and/or fair queueing
| #
| # CONFIG_NET_SCHED is not set
| 
| #
| # Network testing
| #
| # CONFIG_NET_PKTGEN is not set
| CONFIG_NETDEVICES=y
| 
| #
| # ARCnet devices
| #
| # CONFIG_ARCNET is not set
| CONFIG_DUMMY=m
| # CONFIG_BONDING is not set
| # CONFIG_EQUALIZER is not set
| # CONFIG_TUN is not set
| 
| #
| # Ethernet (10 or 100Mbit)
| #
| CONFIG_NET_ETHERNET=y
| CONFIG_MII=y
| # CONFIG_HAPPYMEAL is not set
| # CONFIG_SUNGEM is not set
| # CONFIG_NET_VENDOR_3COM is not set
| 
| #
| # Tulip family network device support
| #
| # CONFIG_NET_TULIP is not set
| # CONFIG_HP100 is not set
| CONFIG_NET_PCI=y
| # CONFIG_PCNET32 is not set
| # CONFIG_AMD8111_ETH is not set
| # CONFIG_ADAPTEC_STARFIRE is not set
| # CONFIG_B44 is not set
| # CONFIG_FORCEDETH is not set
| # CONFIG_DGRS is not set
| # CONFIG_EEPRO100 is not set
| # CONFIG_E100 is not set
| # CONFIG_FEALNX is not set
| # CONFIG_NATSEMI is not set
| # CONFIG_NE2K_PCI is not set
| # CONFIG_8139CP is not set
| CONFIG_8139TOO=y
| # CONFIG_8139TOO_PIO is not set
| # CONFIG_8139TOO_TUNE_TWISTER is not set
| # CONFIG_8139TOO_8129 is not set
| # CONFIG_8139_OLD_RX_RESET is not set
| # CONFIG_SIS900 is not set
| # CONFIG_EPIC100 is not set
| # CONFIG_SUNDANCE is not set
| # CONFIG_TLAN is not set
| # CONFIG_VIA_RHINE is not set
| 
| #
| # Ethernet (1000 Mbit)
| #
| # CONFIG_ACENIC is not set
| # CONFIG_DL2K is not set
| # CONFIG_E1000 is not set
| # CONFIG_NS83820 is not set
| # CONFIG_HAMACHI is not set
| # CONFIG_YELLOWFIN is not set
| # CONFIG_R8169 is not set
| # CONFIG_SIS190 is not set
| # CONFIG_SK98LIN is not set
| # CONFIG_TIGON3 is not set
| 
| #
| # Ethernet (10000 Mbit)
| #
| # CONFIG_IXGB is not set
| # CONFIG_FDDI is not set
| # CONFIG_HIPPI is not set
| CONFIG_PPP=y
| # CONFIG_PPP_MULTILINK is not set
| CONFIG_PPP_FILTER=y
| CONFIG_PPP_ASYNC=y
| CONFIG_PPP_SYNC_TTY=y
| CONFIG_PPP_DEFLATE=y
| CONFIG_PPP_BSDCOMP=y
| # CONFIG_PPPOE is not set
| # CONFIG_SLIP is not set
| 
| #
| # Wireless LAN (non-hamradio)
| #
| # CONFIG_NET_RADIO is not set
| 
| #
| # Token Ring devices
| #
| # CONFIG_TR is not set
| # CONFIG_NET_FC is not set
| # CONFIG_RCPCI is not set
| # CONFIG_SHAPER is not set
| 
| #
| # Wan interfaces
| #
| # CONFIG_WAN is not set
| 
| #
| # Amateur Radio support
| #
| # CONFIG_HAMRADIO is not set
| 
| #
| # IrDA (infrared) support
| #
| # CONFIG_IRDA is not set
| 
| #
| # Bluetooth support
| #
| # CONFIG_BT is not set
| 
| #
| # ISDN subsystem
| #
| # CONFIG_ISDN_BOOL is not set
| 
| #
| # Telephony Support
| #
| # CONFIG_PHONE is not set
| 
| #
| # Input device support
| #
| CONFIG_INPUT=y
| 
| #
| # Userland interfaces
| #
| CONFIG_INPUT_MOUSEDEV=y
| CONFIG_INPUT_MOUSEDEV_PSAUX=y
| CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
| CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
| # CONFIG_INPUT_JOYDEV is not set
| # CONFIG_INPUT_TSDEV is not set
| # CONFIG_INPUT_EVDEV is not set
| # CONFIG_INPUT_EVBUG is not set
| 
| #
| # Input I/O drivers
| #
| # CONFIG_GAMEPORT is not set
| CONFIG_SOUND_GAMEPORT=y
| CONFIG_SERIO=y
| CONFIG_SERIO_I8042=y
| # CONFIG_SERIO_SERPORT is not set
| # CONFIG_SERIO_CT82C710 is not set
| # CONFIG_SERIO_PCIPS2 is not set
| 
| #
| # Input Device Drivers
| #
| CONFIG_INPUT_KEYBOARD=y
| CONFIG_KEYBOARD_ATKBD=y
| # CONFIG_KEYBOARD_SUNKBD is not set
| # CONFIG_KEYBOARD_XTKBD is not set
| # CONFIG_KEYBOARD_NEWTON is not set
| CONFIG_INPUT_MOUSE=y
| CONFIG_MOUSE_PS2=y
| # CONFIG_MOUSE_SERIAL is not set
| # CONFIG_INPUT_JOYSTICK is not set
| # CONFIG_INPUT_TOUCHSCREEN is not set
| # CONFIG_INPUT_MISC is not set
| 
| #
| # Character devices
| #
| CONFIG_VT=y
| CONFIG_VT_CONSOLE=y
| CONFIG_HW_CONSOLE=y
| # CONFIG_SERIAL_NONSTANDARD is not set
| 
| #
| # Serial drivers
| #
| CONFIG_SERIAL_8250=y
| # CONFIG_SERIAL_8250_CONSOLE is not set
| CONFIG_SERIAL_8250_NR_UARTS=4
| # CONFIG_SERIAL_8250_EXTENDED is not set
| 
| #
| # Non-8250 serial port support
| #
| CONFIG_SERIAL_CORE=y
| CONFIG_UNIX98_PTYS=y
| CONFIG_UNIX98_PTY_COUNT=256
| 
| #
| # Mice
| #
| # CONFIG_BUSMOUSE is not set
| # CONFIG_QIC02_TAPE is not set
| 
| #
| # IPMI
| #
| # CONFIG_IPMI_HANDLER is not set
| 
| #
| # Watchdog Cards
| #
| # CONFIG_WATCHDOG is not set
| # CONFIG_HW_RANDOM is not set
| # CONFIG_NVRAM is not set
| CONFIG_RTC=y
| # CONFIG_DTLK is not set
| # CONFIG_R3964 is not set
| # CONFIG_APPLICOM is not set
| # CONFIG_SONYPI is not set
| 
| #
| # Ftape, the floppy tape device driver
| #
| # CONFIG_AGP is not set
| # CONFIG_DRM is not set
| # CONFIG_MWAVE is not set
| # CONFIG_RAW_DRIVER is not set
| # CONFIG_HANGCHECK_TIMER is not set
| 
| #
| # I2C support
| #
| CONFIG_I2C=m
| CONFIG_I2C_CHARDEV=m
| 
| #
| # I2C Algorithms
| #
| CONFIG_I2C_ALGOBIT=m
| CONFIG_I2C_ALGOPCF=m
| 
| #
| # I2C Hardware Bus support
| #
| CONFIG_I2C_ALI1535=m
| CONFIG_I2C_ALI15X3=m
| CONFIG_I2C_AMD756=m
| CONFIG_I2C_AMD8111=m
| # CONFIG_I2C_ELV is not set
| CONFIG_I2C_I801=m
| CONFIG_I2C_I810=m
| CONFIG_I2C_ISA=m
| CONFIG_I2C_NFORCE2=m
| # CONFIG_I2C_PARPORT_LIGHT is not set
| CONFIG_I2C_PIIX4=m
| CONFIG_I2C_PROSAVAGE=m
| CONFIG_I2C_SAVAGE4=m
| CONFIG_SCx200_ACB=m
| CONFIG_I2C_SIS5595=m
| CONFIG_I2C_SIS630=m
| CONFIG_I2C_SIS96X=m
| # CONFIG_I2C_VELLEMAN is not set
| CONFIG_I2C_VIA=m
| CONFIG_I2C_VIAPRO=m
| CONFIG_I2C_VOODOO3=m
| 
| #
| # I2C Hardware Sensors Chip support
| #
| CONFIG_I2C_SENSOR=m
| CONFIG_SENSORS_ADM1021=m
| # CONFIG_SENSORS_ASB100 is not set
| CONFIG_SENSORS_EEPROM=m
| CONFIG_SENSORS_IT87=m
| CONFIG_SENSORS_LM75=m
| CONFIG_SENSORS_LM78=m
| CONFIG_SENSORS_LM83=m
| CONFIG_SENSORS_LM85=m
| CONFIG_SENSORS_LM90=m
| CONFIG_SENSORS_VIA686A=m
| CONFIG_SENSORS_W83781D=m
| CONFIG_SENSORS_W83L785TS=m
| # CONFIG_I2C_DEBUG_CORE is not set
| # CONFIG_I2C_DEBUG_BUS is not set
| # CONFIG_I2C_DEBUG_CHIP is not set
| 
| #
| # Multimedia devices
| #
| # CONFIG_VIDEO_DEV is not set
| 
| #
| # Digital Video Broadcasting Devices
| #
| # CONFIG_DVB is not set
| 
| #
| # Graphics support
| #
| # CONFIG_FB is not set
| # CONFIG_VIDEO_SELECT is not set
| 
| #
| # Console display driver support
| #
| CONFIG_VGA_CONSOLE=y
| # CONFIG_MDA_CONSOLE is not set
| CONFIG_DUMMY_CONSOLE=y
| 
| #
| # Sound
| #
| CONFIG_SOUND=y
| 
| #
| # Advanced Linux Sound Architecture
| #
| CONFIG_SND=y
| # CONFIG_SND_SEQUENCER is not set
| CONFIG_SND_OSSEMUL=y
| CONFIG_SND_MIXER_OSS=y
| CONFIG_SND_PCM_OSS=y
| # CONFIG_SND_RTCTIMER is not set
| # CONFIG_SND_VERBOSE_PRINTK is not set
| # CONFIG_SND_DEBUG is not set
| 
| #
| # Generic devices
| #
| # CONFIG_SND_DUMMY is not set
| # CONFIG_SND_MTPAV is not set
| # CONFIG_SND_SERIAL_U16550 is not set
| # CONFIG_SND_MPU401 is not set
| 
| #
| # PCI devices
| #
| # CONFIG_SND_ALI5451 is not set
| # CONFIG_SND_AZT3328 is not set
| # CONFIG_SND_CS46XX is not set
| # CONFIG_SND_CS4281 is not set
| CONFIG_SND_EMU10K1=y
| # CONFIG_SND_KORG1212 is not set
| # CONFIG_SND_NM256 is not set
| # CONFIG_SND_RME32 is not set
| # CONFIG_SND_RME96 is not set
| # CONFIG_SND_RME9652 is not set
| # CONFIG_SND_HDSP is not set
| # CONFIG_SND_TRIDENT is not set
| # CONFIG_SND_YMFPCI is not set
| # CONFIG_SND_ALS4000 is not set
| # CONFIG_SND_CMIPCI is not set
| # CONFIG_SND_ENS1370 is not set
| # CONFIG_SND_ENS1371 is not set
| # CONFIG_SND_ES1938 is not set
| # CONFIG_SND_ES1968 is not set
| # CONFIG_SND_MAESTRO3 is not set
| # CONFIG_SND_FM801 is not set
| # CONFIG_SND_ICE1712 is not set
| # CONFIG_SND_ICE1724 is not set
| # CONFIG_SND_INTEL8X0 is not set
| # CONFIG_SND_SONICVIBES is not set
| # CONFIG_SND_VIA82XX is not set
| # CONFIG_SND_VX222 is not set
| 
| #
| # ALSA USB devices
| #
| # CONFIG_SND_USB_AUDIO is not set
| 
| #
| # Open Sound System
| #
| # CONFIG_SOUND_PRIME is not set
| 
| #
| # USB support
| #
| CONFIG_USB=y
| # CONFIG_USB_DEBUG is not set
| 
| #
| # Miscellaneous USB options
| #
| CONFIG_USB_DEVICEFS=y
| # CONFIG_USB_BANDWIDTH is not set
| # CONFIG_USB_DYNAMIC_MINORS is not set
| 
| #
| # USB Host Controller Drivers
| #
| CONFIG_USB_EHCI_HCD=y
| # CONFIG_USB_OHCI_HCD is not set
| CONFIG_USB_UHCI_HCD=y
| 
| #
| # USB Device Class drivers
| #
| # CONFIG_USB_AUDIO is not set
| # CONFIG_USB_BLUETOOTH_TTY is not set
| # CONFIG_USB_MIDI is not set
| # CONFIG_USB_ACM is not set
| CONFIG_USB_PRINTER=y
| CONFIG_USB_STORAGE=y
| # CONFIG_USB_STORAGE_DEBUG is not set
| # CONFIG_USB_STORAGE_DATAFAB is not set
| # CONFIG_USB_STORAGE_FREECOM is not set
| # CONFIG_USB_STORAGE_ISD200 is not set
| # CONFIG_USB_STORAGE_DPCM is not set
| # CONFIG_USB_STORAGE_HP8200e is not set
| # CONFIG_USB_STORAGE_SDDR09 is not set
| # CONFIG_USB_STORAGE_SDDR55 is not set
| # CONFIG_USB_STORAGE_JUMPSHOT is not set
| 
| #
| # USB Human Interface Devices (HID)
| #
| CONFIG_USB_HID=y
| CONFIG_USB_HIDINPUT=y
| # CONFIG_HID_FF is not set
| # CONFIG_USB_HIDDEV is not set
| # CONFIG_USB_AIPTEK is not set
| # CONFIG_USB_WACOM is not set
| # CONFIG_USB_KBTAB is not set
| # CONFIG_USB_POWERMATE is not set
| # CONFIG_USB_XPAD is not set
| 
| #
| # USB Imaging devices
| #
| # CONFIG_USB_MDC800 is not set
| # CONFIG_USB_SCANNER is not set
| # CONFIG_USB_MICROTEK is not set
| # CONFIG_USB_HPUSBSCSI is not set
| 
| #
| # USB Multimedia devices
| #
| # CONFIG_USB_DABUSB is not set
| 
| #
| # Video4Linux support is needed for USB Multimedia device support
| #
| 
| #
| # USB Network adaptors
| #
| # CONFIG_USB_CATC is not set
| # CONFIG_USB_KAWETH is not set
| # CONFIG_USB_PEGASUS is not set
| # CONFIG_USB_RTL8150 is not set
| # CONFIG_USB_USBNET is not set
| 
| #
| # USB port drivers
| #
| 
| #
| # USB Serial Converter support
| #
| # CONFIG_USB_SERIAL is not set
| 
| #
| # USB Miscellaneous drivers
| #
| # CONFIG_USB_EMI62 is not set
| # CONFIG_USB_EMI26 is not set
| # CONFIG_USB_TIGL is not set
| # CONFIG_USB_AUERSWALD is not set
| # CONFIG_USB_RIO500 is not set
| # CONFIG_USB_LEGOTOWER is not set
| # CONFIG_USB_BRLVGER is not set
| # CONFIG_USB_LCD is not set
| # CONFIG_USB_LED is not set
| # CONFIG_USB_TEST is not set
| 
| #
| # USB Gadget Support
| #
| # CONFIG_USB_GADGET is not set
| 
| #
| # File systems
| #
| # CONFIG_EXT2_FS is not set
| # CONFIG_EXT3_FS is not set
| # CONFIG_JBD is not set
| CONFIG_REISERFS_FS=y
| # CONFIG_REISERFS_CHECK is not set
| # CONFIG_REISERFS_PROC_INFO is not set
| # CONFIG_JFS_FS is not set
| # CONFIG_XFS_FS is not set
| # CONFIG_MINIX_FS is not set
| # CONFIG_ROMFS_FS is not set
| # CONFIG_QUOTA is not set
| # CONFIG_AUTOFS_FS is not set
| # CONFIG_AUTOFS4_FS is not set
| 
| #
| # CD-ROM/DVD Filesystems
| #
| CONFIG_ISO9660_FS=y
| CONFIG_JOLIET=y
| # CONFIG_ZISOFS is not set
| CONFIG_UDF_FS=y
| 
| #
| # DOS/FAT/NT Filesystems
| #
| CONFIG_FAT_FS=y
| CONFIG_MSDOS_FS=y
| CONFIG_VFAT_FS=y
| CONFIG_NTFS_FS=y
| # CONFIG_NTFS_DEBUG is not set
| # CONFIG_NTFS_RW is not set
| 
| #
| # Pseudo filesystems
| #
| CONFIG_PROC_FS=y
| CONFIG_PROC_KCORE=y
| CONFIG_DEVFS_FS=y
| CONFIG_DEVFS_MOUNT=y
| # CONFIG_DEVFS_DEBUG is not set
| CONFIG_DEVPTS_FS=y
| CONFIG_DEVPTS_FS_XATTR=y
| # CONFIG_DEVPTS_FS_SECURITY is not set
| CONFIG_TMPFS=y
| # CONFIG_HUGETLBFS is not set
| # CONFIG_HUGETLB_PAGE is not set
| CONFIG_RAMFS=y
| 
| #
| # Miscellaneous filesystems
| #
| # CONFIG_ADFS_FS is not set
| # CONFIG_AFFS_FS is not set
| # CONFIG_HFS_FS is not set
| # CONFIG_BEFS_FS is not set
| # CONFIG_BFS_FS is not set
| # CONFIG_EFS_FS is not set
| # CONFIG_CRAMFS is not set
| # CONFIG_VXFS_FS is not set
| # CONFIG_HPFS_FS is not set
| # CONFIG_QNX4FS_FS is not set
| # CONFIG_SYSV_FS is not set
| # CONFIG_UFS_FS is not set
| 
| #
| # Network File Systems
| #
| # CONFIG_NFS_FS is not set
| # CONFIG_NFSD is not set
| # CONFIG_EXPORTFS is not set
| # CONFIG_SMB_FS is not set
| # CONFIG_CIFS is not set
| # CONFIG_NCP_FS is not set
| # CONFIG_CODA_FS is not set
| # CONFIG_INTERMEZZO_FS is not set
| # CONFIG_AFS_FS is not set
| 
| #
| # Partition Types
| #
| # CONFIG_PARTITION_ADVANCED is not set
| CONFIG_MSDOS_PARTITION=y
| 
| #
| # Native Language Support
| #
| CONFIG_NLS=y
| CONFIG_NLS_DEFAULT="iso8859-2"
| CONFIG_NLS_CODEPAGE_437=y
| # CONFIG_NLS_CODEPAGE_737 is not set
| # CONFIG_NLS_CODEPAGE_775 is not set
| # CONFIG_NLS_CODEPAGE_850 is not set
| CONFIG_NLS_CODEPAGE_852=m
| # CONFIG_NLS_CODEPAGE_855 is not set
| # CONFIG_NLS_CODEPAGE_857 is not set
| # CONFIG_NLS_CODEPAGE_860 is not set
| # CONFIG_NLS_CODEPAGE_861 is not set
| # CONFIG_NLS_CODEPAGE_862 is not set
| # CONFIG_NLS_CODEPAGE_863 is not set
| # CONFIG_NLS_CODEPAGE_864 is not set
| # CONFIG_NLS_CODEPAGE_865 is not set
| # CONFIG_NLS_CODEPAGE_866 is not set
| # CONFIG_NLS_CODEPAGE_869 is not set
| # CONFIG_NLS_CODEPAGE_936 is not set
| # CONFIG_NLS_CODEPAGE_950 is not set
| # CONFIG_NLS_CODEPAGE_932 is not set
| # CONFIG_NLS_CODEPAGE_949 is not set
| # CONFIG_NLS_CODEPAGE_874 is not set
| # CONFIG_NLS_ISO8859_8 is not set
| CONFIG_NLS_CODEPAGE_1250=m
| # CONFIG_NLS_CODEPAGE_1251 is not set
| CONFIG_NLS_ISO8859_1=y
| CONFIG_NLS_ISO8859_2=y
| # CONFIG_NLS_ISO8859_3 is not set
| # CONFIG_NLS_ISO8859_4 is not set
| # CONFIG_NLS_ISO8859_5 is not set
| # CONFIG_NLS_ISO8859_6 is not set
| # CONFIG_NLS_ISO8859_7 is not set
| # CONFIG_NLS_ISO8859_9 is not set
| # CONFIG_NLS_ISO8859_13 is not set
| # CONFIG_NLS_ISO8859_14 is not set
| # CONFIG_NLS_ISO8859_15 is not set
| # CONFIG_NLS_KOI8_R is not set
| # CONFIG_NLS_KOI8_U is not set
| CONFIG_NLS_UTF8=m
| 
| #
| # Profiling support
| #
| # CONFIG_PROFILING is not set
| 
| #
| # Kernel hacking
| #
| # CONFIG_DEBUG_KERNEL is not set
| # CONFIG_DEBUG_SPINLOCK_SLEEP is not set
| CONFIG_FRAME_POINTER=y
| CONFIG_X86_FIND_SMP_CONFIG=y
| CONFIG_X86_MPPARSE=y
| 
| #
| # Security options
| #
| # CONFIG_SECURITY is not set
| 
| #
| # Cryptographic options
| #
| CONFIG_CRYPTO=y
| # CONFIG_CRYPTO_HMAC is not set
| CONFIG_CRYPTO_NULL=m
| CONFIG_CRYPTO_MD4=m
| CONFIG_CRYPTO_MD5=m
| CONFIG_CRYPTO_SHA1=m
| CONFIG_CRYPTO_SHA256=m
| CONFIG_CRYPTO_SHA512=m
| CONFIG_CRYPTO_DES=m
| CONFIG_CRYPTO_BLOWFISH=y
| CONFIG_CRYPTO_TWOFISH=m
| CONFIG_CRYPTO_SERPENT=m
| CONFIG_CRYPTO_AES=y
| CONFIG_CRYPTO_CAST5=m
| CONFIG_CRYPTO_CAST6=m
| CONFIG_CRYPTO_DEFLATE=m
| # CONFIG_CRYPTO_TEST is not set
| 
| #
| # Library routines
| #
| CONFIG_CRC32=y
| CONFIG_ZLIB_INFLATE=y
| CONFIG_ZLIB_DEFLATE=y
| CONFIG_X86_SMP=y
| CONFIG_X86_HT=y
| CONFIG_X86_BIOS_REBOOT=y
| CONFIG_X86_TRAMPOLINE=y
| CONFIG_PC=y
| 
| --------------000303030500070207010703--
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at  http://www.tux.org/lkml/
| 


-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jan Rychter]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

>>>>> "Jari" == Jari Ruusu <jariruusu@users.sourceforge.net> writes:
 Jari> Michal Kwolek wrote:
 >> I've got a reproducible oops when using cryptoloop on vanilla 2.6.0,
 >> 2.6.1 and 2.6.2 (2.4.* works fine).
 >>
 >> Way to reproduce: dd if=/dev/urandom of=crypto bs=1024
 >> count=some_size losetup -e some_cipher /dev/loop0 crypto
 >> #Any of those commands causes oops and hard lockup:
 >> cp /dev/loop0 /dev/null mkreiserfs /dev/loop0 mkfs.ext2 /dev/loop0
 >>
 >> Loop without cryptoapi works fine: dd if=/dev/urandom of=crypto
 >> bs=1024 count=some_size losetup /dev/loop0 crypto cp /dev/loop0
 >> /dev/null
 >> #ok, no oops

 Jari> Can you try again using loop-AES? loop-AES does not fall apart
 Jari> like the mainline implementation does. loop-AES is here:

FWIW, I've just tried loop-AES with 2.4.24, after using cryptoapi for a
number of years. My machine froze dead in the midst of copying 2.8GB of
data onto my file-backed reiserfs encrypted loopback mount.

Since the system didn't ever freeze on me before and since I've had zero
problems with cryptoapi, I attribute the freeze to loop-AES.

Yes, I know this isn't a good bugreport...

--J.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jari Ruusu]

Jan Rychter wrote:
> FWIW, I've just tried loop-AES with 2.4.24, after using cryptoapi for a
> number of years. My machine froze dead in the midst of copying 2.8GB of
> data onto my file-backed reiserfs encrypted loopback mount.
> 
> Since the system didn't ever freeze on me before and since I've had zero
> problems with cryptoapi, I attribute the freeze to loop-AES.
> 
> Yes, I know this isn't a good bugreport...

Is there any particular reason why you insist on using file backed loops?

File backed loops have hard to fix re-entry problem: GFP_NOFS memory
allocations that cause dirty pages to written out to file backed loop, will
have to re-enter the file system anyway to complete the write. This causes
deadlocks. Same deadlocks are there in mainline loop+cryptoloop combo.

This is one of the reasons why this is in loop-AES README: "If you can
choose between device backed and file backed, choose device backed even if
it means that you have to re-partition your disks."

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jari Ruusu]

Jari Ruusu wrote:
> Jan Rychter wrote:
> > FWIW, I've just tried loop-AES with 2.4.24, after using cryptoapi for a
> > number of years. My machine froze dead in the midst of copying 2.8GB of
> > data onto my file-backed reiserfs encrypted loopback mount.
> >
> > Since the system didn't ever freeze on me before and since I've had zero
> > problems with cryptoapi, I attribute the freeze to loop-AES.
> >
> > Yes, I know this isn't a good bugreport...
> 
> Is there any particular reason why you insist on using file backed loops?
> 
> File backed loops have hard to fix re-entry problem: GFP_NOFS memory
> allocations that cause dirty pages to written out to file backed loop, will
> have to re-enter the file system anyway to complete the write. This causes
> deadlocks. Same deadlocks are there in mainline loop+cryptoloop combo.
> 
> This is one of the reasons why this is in loop-AES README: "If you can
> choose between device backed and file backed, choose device backed even if
> it means that you have to re-partition your disks."

A quick grep of potential deadlock points:

armas:/usr/src/linux-2.4.24/fs/reiserfs # grep -r GFP_NOFS *
dir.c:              local_buf = reiserfs_kmalloc(d_reclen, GFP_NOFS, inode->i_sb) ;
fix_node.c:         buf = reiserfs_kmalloc(size, GFP_NOFS, tb->tb_sb);
journal.c:  bn = reiserfs_kmalloc(sizeof(struct reiserfs_bitmap_node), GFP_NOFS, p_s_sb) ;
journal.c:  bn->data = reiserfs_kmalloc(p_s_sb->s_blocksize, GFP_NOFS, p_s_sb) ;
journal.c:  log_blocks = reiserfs_kmalloc(le32_to_cpu(desc->j_len) * sizeof(struct buffer_head *), GFP_NOFS, p_s_sb) ;
journal.c:  real_blocks = reiserfs_kmalloc(le32_to_cpu(desc->j_len) * sizeof(struct buffer_head *), GFP_NOFS, p_s_sb) ;
journal.c:  /* using GFP_NOFS, GFP_KERNEL could try to flush inodes, which will try
journal.c:  ct = reiserfs_kmalloc(sizeof(struct reiserfs_journal_commit_task), GFP_NOFS, p_s_sb) ;
namei.c:        buffer = reiserfs_kmalloc (buflen, GFP_NOFS, dir->i_sb);
namei.c:    name = reiserfs_kmalloc (item_len, GFP_NOFS, parent_dir->i_sb);
armas:/usr/src/linux-2.4.24/fs/reiserfs #

Many potential deadlock points there in reiserfs.

armas:/usr/src/linux-2.4.24/fs/ext2 # grep -r GFP_NOFS *
armas:/usr/src/linux-2.4.24/fs/ext2 #

File backed loop to a file on ext2 may work.

armas:/usr/src/linux-2.4.24/fs/ext3 # grep -r GFP_NOFS *
inode.c:        page = find_or_create_page(mapping, index, GFP_NOFS);
armas:/usr/src/linux-2.4.24/fs/ext3 #

Potential deadlock point there in ext3.

armas:/usr/src/linux-2.4.24/fs/nfs # grep -r GFP_NOFS *
armas:/usr/src/linux-2.4.24/fs/nfs # 

File backed loop to a file on nfs may work.

armas:/usr/src/linux-2.4.24/fs/smbfs # grep -r GFP_NOFS *
armas:/usr/src/linux-2.4.24/fs/smbfs #

File backed loop to a file on smbfs may work.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Christophe Saout]

Hi,

> I've got a reproducible oops when using cryptoloop on vanilla 2.6.0,
> 2.6.1 and 2.6.2 (2.4.* works fine).
> [also reported a deadlock while trying loop-aes]

could you try dm-crypt? It uses the device-mapper instead of the loop
device but should be compatible (uses cryptoapi too). It's going to be
added to the kernel soon I hope.

You can find a patch on http://www.saout.de/misc/ against the vanilla
kernel (dm-crypt.diff), I just rediffed it against linux 2.6.2.

You need the dmsetup tool from the device-mapper package to set up
encryption. There's also a shell script called cryptsetup on the page
that wraps around dmsetup. It requires the hashalot program.

It shouldn't oops. But if the deadlock you were seeing didn't come from
loop-aes it might also show up here. If you're willing to test - let me
know. :)

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Christoph Hellwig]

On Sun, Feb 15, 2004 at 06:34:31PM +0100, Christophe Saout wrote:
> could you try dm-crypt? It uses the device-mapper instead of the loop
> device but should be compatible (uses cryptoapi too). It's going to be
> added to the kernel soon I hope.

What's holding it back?  I'd rather get rid of all the cryptoloop crap
sooner or later.

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Christophe Saout]

Am So, den 15.02.2004 schrieb Christoph Hellwig um 19:02:

> On Sun, Feb 15, 2004 at 06:34:31PM +0100, Christophe Saout wrote:
> > could you try dm-crypt? It uses the device-mapper instead of the loop
> > device but should be compatible (uses cryptoapi too). It's going to be
> > added to the kernel soon I hope.
> 
> What's holding it back?  I'd rather get rid of all the cryptoloop crap
> sooner or later.

Well, nothing. It's in the dm-unstable tree for some time now. It
depends on when Joe plans to submit it. His last words were "in the next
couple of months". I don't know what that means exactly.

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Christoph Hellwig]

On Sun, Feb 15, 2004 at 07:42:53PM +0100, Christophe Saout wrote:
> > What's holding it back?  I'd rather get rid of all the cryptoloop crap
> > sooner or later.
> 
> Well, nothing. It's in the dm-unstable tree for some time now. It
> depends on when Joe plans to submit it. His last words were "in the next
> couple of months". I don't know what that means exactly.

Is there a technical reason holding it back, e.g. a depency on core DM
changes?  If not please submit it instead of waiting any longer.

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Christophe Saout]

Am So, den 15.02.2004 schrieb Christoph Hellwig um 19:53:

> > > What's holding it back?  I'd rather get rid of all the cryptoloop crap
> > > sooner or later.
> > 
> > Well, nothing. It's in the dm-unstable tree for some time now. It
> > depends on when Joe plans to submit it. His last words were "in the next
> > couple of months". I don't know what that means exactly.
> 
> Is there a technical reason holding it back, e.g. a depency on core DM
> changes?  If not please submit it instead of waiting any longer.

The only reason, I guess, is that it depends on this very small
dm-daemon thing:
http://people.sistina.com/~thornber/dm/patches/2.6-unstable/2.6.2/2.6.2-udm1/00016.patch

Some other dm targets in the unstable tree use this too, it's just to
have very simple bottom-half processing in a separate thread with
synchronous start and stop functions.

Especially since dm-crypt was announced in a german linux magazine two
weeks ago people keep asking me when to expect it in the kernel. And to
delay it for some months just because there might be changes to
dm-daemon, which would be almost trivial, is a stupid reason to hold it
back if you ask me. :(

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Christoph Hellwig]

On Sun, Feb 15, 2004 at 08:36:00PM +0100, Christophe Saout wrote:
> The only reason, I guess, is that it depends on this very small
> dm-daemon thing:
> http://people.sistina.com/~thornber/dm/patches/2.6-unstable/2.6.2/2.6.2-udm1/00016.patch
> 
> Some other dm targets in the unstable tree use this too, it's just to
> have very simple bottom-half processing in a separate thread with
> synchronous start and stop functions.
> 
> Especially since dm-crypt was announced in a german linux magazine two
> weeks ago people keep asking me when to expect it in the kernel. And to
> delay it for some months just because there might be changes to
> dm-daemon, which would be almost trivial, is a stupid reason to hold it
> back if you ask me. :(

Well, actually the above code should not enter the kernel tree at all.
Care to rewrite dm-crypt to use Rusty's kthread code in -mm instead and
submit a patch to Andrew?  Whenever he merges the kthread stuff to mainline
he could just include dm-crypt then.

kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout]

Am So, den 15.02.2004 schrieb Christoph Hellwig um 20:46:

> > The only reason, I guess, is that it depends on this very small
> > dm-daemon thing:
> > http://people.sistina.com/~thornber/dm/patches/2.6-unstable/2.6.2/2.6.2-udm1/00016.patch
>
> Well, actually the above code should not enter the kernel tree at all.
> Care to rewrite dm-crypt to use Rusty's kthread code in -mm instead and
> submit a patch to Andrew?  Whenever he merges the kthread stuff to mainline
> he could just include dm-crypt then.

Sure I could.

But kthread is currently not a full replacement for dm-daemon. kthread
provides thread creation and destruction functions. But dm-daemon
additionaly does mainloop handling.

Usually, the dm-daemon client adds some work to a list under a spinlock
and calls dm_daemon_wake. The next time the thread runs it calls the
client work function which usually just grabs the whole list and
processes it.
The client work function can also indicate it wants periodic wakeup
using a return value which is currently used in the multipath target but
it's not sure whether this will be moved to a userspace daemon.

There seems to beg a small race conditition that can appear when using
only wake_up for notifies so dm-daemon uses an additional atomic_t
variable to make sure nothing gets missed. Just see the function
``daemon'' in dm-daemon.c.

Making dm-daemon use the kthread primitives would make dm-daemon a very
small and stupid wrapper. Changing all dm targets to handle worker
thread notification themselves would result in unnecessary code
duplication.

It seems to me that this functionality could perhaps be somehow added to
kthread without changing it too much... ?

I would like to double-check with Joe rushing forward on my own.

Re: kthread vs. dm-daemon

[Mike Christie]

Christophe Saout wrote:
> Am So, den 15.02.2004 schrieb Christoph Hellwig um 20:46:
> 
> 
>>>The only reason, I guess, is that it depends on this very small
>>>dm-daemon thing:
>>>http://people.sistina.com/~thornber/dm/patches/2.6-unstable/2.6.2/2.6.2-udm1/00016.patch
>>
>>Well, actually the above code should not enter the kernel tree at all.
>>Care to rewrite dm-crypt to use Rusty's kthread code in -mm instead and
>>submit a patch to Andrew?  Whenever he merges the kthread stuff to mainline
>>he could just include dm-crypt then.
> 
> 
> Sure I could.
> 
> But kthread is currently not a full replacement for dm-daemon. kthread
> provides thread creation and destruction functions. But dm-daemon
> additionaly does mainloop handling.
> 
> Usually, the dm-daemon client adds some work to a list under a spinlock
> and calls dm_daemon_wake. The next time the thread runs it calls the
> client work function which usually just grabs the whole list and
> processes it.
> The client work function can also indicate it wants periodic wakeup
> using a return value which is currently used in the multipath target but
> it's not sure whether this will be moved to a userspace daemon.
>
> There seems to beg a small race conditition that can appear when using
> only wake_up for notifies so dm-daemon uses an additional atomic_t
> variable to make sure nothing gets missed. Just see the function
> ``daemon'' in dm-daemon.c.
> 
> Making dm-daemon use the kthread primitives would make dm-daemon a very
> small and stupid wrapper. Changing all dm targets to handle worker
> thread notification themselves would result in unnecessary code
> duplication.
> 

When dm-multipath is more stable it could be using a work queue (my 
patch was prematurely sent). Imagine a large number of dm-mp devices 
multipathing across two fabrics and one switch failing. Every dm-mp 
device could be resubmitting io at the same time. That leaves dm-raid1, 
dm-snap and your target. The raid1 code looks like it could also benefit 
from swithing. If every write for every dm-raid1 device is going through 
a single dm-daemon, it could become a bottleneck. This is all assuming 
the number of processors and DM devices on your machine makes sense.

I guess you could also just do a thread per target instance, but maybe 
this was ruled as excessive for thousands of DM devices?

Mike Christie
mikenc@us.ibm.com

Re: kthread vs. dm-daemon

[Christophe Saout]

Am So, den 15.02.2004 schrieb Mike Christie um 23:13:

> > Making dm-daemon use the kthread primitives would make dm-daemon a very
> > small and stupid wrapper. Changing all dm targets to handle worker
> > thread notification themselves would result in unnecessary code
> > duplication.
> 
> When dm-multipath is more stable it could be using a work queue (my 
> patch was prematurely sent). Imagine a large number of dm-mp devices 
> multipathing across two fabrics and one switch failing. Every dm-mp 
> device could be resubmitting io at the same time.

I've thought of workqueues but at least for the snapshot and crypt
target they're overkill. I've switched dm-crypt to kthread and the
overhead is minimal. I hope I got it right though but it seems to work
just fine.

> If every write for every dm-raid1 device is going through 
> a single dm-daemon, it could become a bottleneck.

Hmm. The read decryption in dm-crypt is also a only-one-cpu-at-a-time
thing. Didn't anybody notice that? Cryptoloop has the same limitation.
I don't know how that could be handled differently. Every successful
read gets dispatched to the next free cpu and decrypted? What about
writes? They are currently running in the caller context (usually
pdflush).

> I guess you could also just do a thread per target instance, but maybe 
> this was ruled as excessive for thousands of DM devices?

Probably. I originally had one thread per device too for dm-crypt
because I didn't think about it but Joe changed it a single dm-daemon
thread (after porting the dm-daemon code to 2.6). He was right because
the different requests can't depend on each other and deadlock because
the daemon will never wait for io.

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[James Morris]

On Sun, 15 Feb 2004, Jari Ruusu wrote:

> Jan Rychter wrote:
> > FWIW, I've just tried loop-AES with 2.4.24, after using cryptoapi for a
> > number of years. My machine froze dead in the midst of copying 2.8GB of
> > data onto my file-backed reiserfs encrypted loopback mount.
> > 
> > Since the system didn't ever freeze on me before and since I've had zero
> > problems with cryptoapi, I attribute the freeze to loop-AES.
> > 
> > Yes, I know this isn't a good bugreport...
> 
> Is there any particular reason why you insist on using file backed loops?
> 
> File backed loops have hard to fix re-entry problem: GFP_NOFS memory
> allocations that cause dirty pages to written out to file backed loop, will
> have to re-enter the file system anyway to complete the write. This causes
> deadlocks. Same deadlocks are there in mainline loop+cryptoloop combo.

Given the security issues, and the above problems, we should probably just
remove cryptoloop from the kernel and wait for something with a better
design.



- James
-- 
James Morris
<jmorris@redhat.com>

Re: kthread vs. dm-daemon

[Mike Christie]

Christophe Saout wrote:
> Am So, den 15.02.2004 schrieb Mike Christie um 23:13:
> 
> 
>>>Making dm-daemon use the kthread primitives would make dm-daemon a very
>>>small and stupid wrapper. Changing all dm targets to handle worker
>>>thread notification themselves would result in unnecessary code
>>>duplication.
>>
>>When dm-multipath is more stable it could be using a work queue (my 
>>patch was prematurely sent). Imagine a large number of dm-mp devices 
>>multipathing across two fabrics and one switch failing. Every dm-mp 
>>device could be resubmitting io at the same time.
> 
> 
> I've thought of workqueues but at least for the snapshot and crypt
> target they're overkill. 

It is a bigger problem for targets submitting io becuase the underlying 
device's queue could hit nr_requests.

> 
>>If every write for every dm-raid1 device is going through 
>>a single dm-daemon, it could become a bottleneck.
> 
> 
> Hmm. The read decryption in dm-crypt is also a only-one-cpu-at-a-time
> thing. Didn't anybody notice that? Cryptoloop has the same limitation.
> I don't know how that could be handled differently. Every successful
> read gets dispatched to the next free cpu and decrypted? 

You do not have to create a work_struct for every read. Why not just 
have a bio-successful-reads-queue and a workstruct per device? That way 
you can at least have num cpu devices running in parallel.

Re: kthread vs. dm-daemon

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb Mike Christie um 02:04:

> > I've thought of workqueues but at least for the snapshot and crypt
> > target they're overkill. 
> 
> It is a bigger problem for targets submitting io becuase the underlying 
> device's queue could hit nr_requests.

You mean beacause the caller can block and this affects other devices
with free requests too. Hmm.

> > Hmm. The read decryption in dm-crypt is also a only-one-cpu-at-a-time
> > thing. Didn't anybody notice that? Cryptoloop has the same limitation.
> > I don't know how that could be handled differently. Every successful
> > read gets dispatched to the next free cpu and decrypted? 
> 
> You do not have to create a work_struct for every read. Why not just 
> have a bio-successful-reads-queue and a workstruct per device?

I have to call queue_work with a work_struct. queue_work will most
likely be called from interrupt context. The bio will be decrypted on
the same cpu as the interrupt occurs. If the driver returns a bunch of
bio's at once they would all be decrypted on the same cpu sequentally.
So it depends on the irq balancing.

What could be done (probably not with work queues) is: If there is a bio
to decrypt the end_io handler finds a free cpu (empty queue) and puts
the bio there. Another possibility: If there is work it gets just added
to a global list and all threads on all cpu's get fired. The fastest one
will pick a bio, the next one the second... monster cache trashing? I
don't know.

dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout]

On Sun, Feb 15, 2004 at 07:46:33PM +0000, Christoph Hellwig wrote:

> Well, actually the above code should not enter the kernel tree at all.
> Care to rewrite dm-crypt to use Rusty's kthread code in -mm instead and
> submit a patch to Andrew?  Whenever he merges the kthread stuff to mainline
> he could just include dm-crypt then.

In spite of the objections I've decided to give it a try.

It's working fine this way and it seems to work fine. The overhead is
very small.


diff -Nur linux-2.6.3-rc3-mm1.orig/drivers/md/dm-crypt.c linux-2.6.3-rc3-mm1/drivers/md/dm-crypt.c
--- linux-2.6.3-rc3-mm1.orig/drivers/md/dm-crypt.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.3-rc3-mm1/drivers/md/dm-crypt.c	2004-02-16 01:47:37.000000000 +0100
@@ -0,0 +1,815 @@
+/*
+ * Copyright (C) 2003 Christophe Saout <christophe@saout.de>
+ *
+ * This file is released under the GPL.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/bio.h>
+#include <linux/mempool.h>
+#include <linux/slab.h>
+#include <linux/crypto.h>
+#include <linux/spinlock.h>
+#include <linux/kthread.h>
+#include <asm/scatterlist.h>
+
+#include "dm.h"
+#include "dm-bio-list.h"
+
+/*
+ * per bio private data
+ */
+struct crypt_io {
+	struct dm_target *target;
+	struct bio *bio;
+	struct bio *first_clone;
+	atomic_t pending;
+	int error;
+};
+
+/*
+ * context holding the current state of a multi-part conversion
+ */
+struct convert_context {
+	struct bio *bio_in;
+	struct bio *bio_out;
+	unsigned int offset_in;
+	unsigned int offset_out;
+	int idx_in;
+	int idx_out;
+	sector_t sector;
+	int write;
+};
+
+/*
+ * Crypt: maps a linear range of a block device
+ * and encrypts / decrypts at the same time.
+ */
+struct crypt_config {
+	struct dm_dev *dev;
+	sector_t start;
+
+	/*
+	 * pool for per bio private data and
+	 * for encryption buffer pages
+	 */
+	mempool_t *io_pool;
+	mempool_t *page_pool;
+
+	/*
+	 * crypto related data
+	 */
+	struct crypto_tfm *tfm;
+	sector_t iv_offset;
+	int (*iv_generator)(struct crypt_config *cc, u8 *iv, sector_t sector);
+	int iv_size;
+	int key_size;
+	u8 key[0];
+};
+
+#define MIN_IOS        256
+#define MIN_POOL_PAGES 32
+#define MIN_BIO_PAGES  8
+
+static kmem_cache_t *_crypt_io_pool;
+
+/*
+ * Mempool alloc and free functions for the page
+ */
+static void *mempool_alloc_page(int gfp_mask, void *data)
+{
+	return alloc_page(gfp_mask);
+}
+
+static void mempool_free_page(void *page, void *data)
+{
+	__free_page(page);
+}
+
+
+/*
+ * Different IV generation algorithms
+ */
+static int crypt_iv_plain(struct crypt_config *cc, u8 *iv, sector_t sector)
+{
+	*(u32 *)iv = cpu_to_le32(sector & 0xffffffff);
+	if (cc->iv_size > sizeof(u32) / sizeof(u8))
+		memset(iv + (sizeof(u32) / sizeof(u8)), 0,
+		       cc->iv_size - (sizeof(u32) / sizeof(u8)));
+
+	return 0;
+}
+
+static inline int
+crypt_convert_scatterlist(struct crypt_config *cc, struct scatterlist *out,
+                          struct scatterlist *in, unsigned int length,
+                          int write, sector_t sector)
+{
+	u8 iv[cc->iv_size];
+	int r;
+
+	if (cc->iv_generator) {
+		r = cc->iv_generator(cc, iv, sector);
+		if (r < 0)
+			return r;
+
+		if (write)
+			r = crypto_cipher_encrypt_iv(cc->tfm, out, in, length, iv);
+		else
+			r = crypto_cipher_decrypt_iv(cc->tfm, out, in, length, iv);
+	} else {
+		if (write)
+			r = crypto_cipher_encrypt(cc->tfm, out, in, length);
+		else
+			r = crypto_cipher_decrypt(cc->tfm, out, in, length);
+	}
+
+	return r;
+}
+
+static void
+crypt_convert_init(struct crypt_config *cc, struct convert_context *ctx,
+                   struct bio *bio_out, struct bio *bio_in,
+                   sector_t sector, int write)
+{
+	ctx->bio_in = bio_in;
+	ctx->bio_out = bio_out;
+	ctx->offset_in = 0;
+	ctx->offset_out = 0;
+	ctx->idx_in = bio_in ? bio_in->bi_idx : 0;
+	ctx->idx_out = bio_out ? bio_out->bi_idx : 0;
+	ctx->sector = sector + cc->iv_offset;
+	ctx->write = write;
+}
+
+/*
+ * Encrypt / decrypt data from one bio to another one (can be the same one)
+ */
+static int crypt_convert(struct crypt_config *cc,
+                         struct convert_context *ctx)
+{
+	int r = 0;
+
+	while(ctx->idx_in < ctx->bio_in->bi_vcnt &&
+	      ctx->idx_out < ctx->bio_out->bi_vcnt) {
+		struct bio_vec *bv_in = bio_iovec_idx(ctx->bio_in, ctx->idx_in);
+		struct bio_vec *bv_out = bio_iovec_idx(ctx->bio_out, ctx->idx_out);
+		struct scatterlist sg_in = {
+			.page = bv_in->bv_page,
+			.offset = bv_in->bv_offset + ctx->offset_in,
+			.length = 1 << SECTOR_SHIFT
+		};
+		struct scatterlist sg_out = {
+			.page = bv_out->bv_page,
+			.offset = bv_out->bv_offset + ctx->offset_out,
+			.length = 1 << SECTOR_SHIFT
+		};
+
+		ctx->offset_in += sg_in.length;
+		if (ctx->offset_in >= bv_in->bv_len) {
+			ctx->offset_in = 0;
+			ctx->idx_in++;
+		}
+
+		ctx->offset_out += sg_out.length;
+		if (ctx->offset_out >= bv_out->bv_len) {
+			ctx->offset_out = 0;
+			ctx->idx_out++;
+		}
+
+		r = crypt_convert_scatterlist(cc, &sg_out, &sg_in, sg_in.length,
+		                              ctx->write, ctx->sector);
+		if (r < 0)
+			break;
+
+		ctx->sector++;
+	}
+
+	return r;
+}
+
+/*
+ * Generate a new unfragmented bio with the given size
+ * This should never violate the device limitations
+ * May return a smaller bio when running out of pages
+ */
+static struct bio *
+crypt_alloc_buffer(struct crypt_config *cc, unsigned int size,
+                   struct bio *base_bio, int *bio_vec_idx)
+{
+	struct bio *bio;
+	int nr_iovecs = dm_div_up(size, PAGE_SIZE);
+	int gfp_mask = GFP_NOIO | __GFP_HIGHMEM;
+	int flags = current->flags;
+	int i;
+
+	/*
+	 * Tell VM to act less aggressively and fail earlier.
+	 * This is not necessary but increases throughput.
+	 * FIXME: Is this really intelligent?
+	 */
+	current->flags &= ~PF_MEMALLOC;
+
+	if (base_bio)
+		bio = bio_clone(base_bio, GFP_NOIO);
+	else
+		bio = bio_alloc(GFP_NOIO, nr_iovecs);
+	if (!bio)
+		return NULL;
+
+	/* if the last bio was not complete, continue where that one ended */
+	bio->bi_idx = *bio_vec_idx;
+	bio->bi_vcnt = *bio_vec_idx;
+	bio->bi_size = 0;
+	bio->bi_flags &= ~(1 << BIO_SEG_VALID);
+
+	/* bio->bi_idx pages have already been allocated */
+	size -= bio->bi_idx * PAGE_SIZE;
+
+	for(i = bio->bi_idx; i < nr_iovecs; i++) {
+		struct bio_vec *bv = bio_iovec_idx(bio, i);
+
+		bv->bv_page = mempool_alloc(cc->page_pool, gfp_mask);
+		if (!bv->bv_page)
+			break;
+
+		/*
+		 * if additional pages cannot be allocated without waiting,
+		 * return a partially allocated bio, the caller will then try
+		 * to allocate additional bios while submitting this partial bio
+		 */
+		if ((i - bio->bi_idx) == (MIN_BIO_PAGES - 1))
+			gfp_mask = (gfp_mask | __GFP_NOWARN) & ~__GFP_WAIT;
+
+		bv->bv_offset = 0;
+		if (size > PAGE_SIZE)
+			bv->bv_len = PAGE_SIZE;
+		else
+			bv->bv_len = size;
+
+		bio->bi_size += bv->bv_len;
+		bio->bi_vcnt++;
+		size -= bv->bv_len;
+	}
+
+	if (flags & PF_MEMALLOC)
+		current->flags |= PF_MEMALLOC;
+
+	if (!bio->bi_size) {
+		bio_put(bio);
+		return NULL;
+	}
+
+	/*
+	 * Remember the last bio_vec allocated to be able
+	 * to correctly continue after the splitting.
+	 */
+	*bio_vec_idx = bio->bi_vcnt;
+
+	return bio;
+}
+
+static void crypt_free_buffer_pages(struct crypt_config *cc,
+                                    struct bio *bio, unsigned int bytes)
+{
+	unsigned int start, end;
+	struct bio_vec *bv;
+	int i;
+
+	/*
+	 * This is ugly, but Jens Axboe thinks that using bi_idx in the
+	 * endio function is too dangerous at the moment, so I calculate the
+	 * correct position using bi_vcnt and bi_size.
+	 * The bv_offset and bv_len fields might already be modified but we
+	 * know that we always allocated whole pages.
+	 * A fix to the bi_idx issue in the kernel is in the works, so
+	 * we will hopefully be able to revert to the cleaner solution soon.
+	 */
+	i = bio->bi_vcnt - 1;
+	bv = bio_iovec_idx(bio, i);
+	end = (i << PAGE_SHIFT) + (bv->bv_offset + bv->bv_len) - bio->bi_size;
+	start = end - bytes;
+
+	start >>= PAGE_SHIFT;
+	if (!bio->bi_size)
+		end = bio->bi_vcnt;
+	else
+		end >>= PAGE_SHIFT;
+
+	for(i = start; i < end; i++) {
+		bv = bio_iovec_idx(bio, i);
+		BUG_ON(!bv->bv_page);
+		mempool_free(bv->bv_page, cc->page_pool);
+		bv->bv_page = NULL;
+	}
+}
+
+/*
+ * One of the bios was finished. Check for completion of
+ * the whole request and correctly clean up the buffer.
+ */
+static void dec_pending(struct crypt_io *io, int error)
+{
+	struct crypt_config *cc = (struct crypt_config *) io->target->private;
+
+	if (error < 0)
+		io->error = error;
+
+	if (!atomic_dec_and_test(&io->pending))
+		return;
+
+	if (io->first_clone)
+		bio_put(io->first_clone);
+
+	if (io->bio)
+		bio_endio(io->bio, io->bio->bi_size, io->error);
+
+	mempool_free(io, cc->io_pool);
+}
+
+/*
+ * kcryptd:
+ *
+ * Needed because it would be very unwise to do decryption in an
+ * interrupt context, so bios returning from read requests get
+ * queued here.
+ */
+static spinlock_t _kcryptd_lock = SPIN_LOCK_UNLOCKED;
+static struct bio_list _kcryptd_bios;
+
+static struct task_struct *_kcryptd;
+
+/*
+ * Fetch a list of the complete bios.
+ */
+static struct bio *kcryptd_get_bios(void)
+{
+	struct bio *bio;
+
+	spin_lock_irq(&_kcryptd_lock);
+	bio = bio_list_get(&_kcryptd_bios);
+	spin_unlock_irq(&_kcryptd_lock);
+
+	return bio;
+}
+
+/*
+ * Append bio to work queue
+ */
+static void kcryptd_queue_bio(struct bio *bio)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&_kcryptd_lock, flags);
+	bio_list_add(&_kcryptd_bios, bio);
+	spin_unlock_irqrestore(&_kcryptd_lock, flags);
+}
+
+static int kcryptd_do_work(void *data)
+{
+	current->flags |= PF_IOTHREAD;
+
+	for(;;) {
+		struct bio *bio;
+
+		set_task_state(current, TASK_INTERRUPTIBLE);
+		while (!(bio = kcryptd_get_bios())) {
+			schedule();
+			if (signal_pending(current))
+				return 0;
+		}
+		set_task_state(current, TASK_RUNNING);
+
+		while (bio) {
+			struct crypt_io *io;
+			struct crypt_config *cc;
+			struct convert_context ctx;
+			struct bio *next_bio;
+			int r;
+
+			io = (struct crypt_io *) bio->bi_private;
+			cc = (struct crypt_config *) io->target->private;
+
+			crypt_convert_init(cc, &ctx, io->bio, io->bio,
+				io->bio->bi_sector - io->target->begin, 0);
+			r = crypt_convert(cc, &ctx);
+
+			next_bio = bio->bi_next;
+			bio->bi_next = NULL;
+
+			bio_put(bio);
+			dec_pending(io, r);
+
+			bio = next_bio;
+		}
+	}
+}
+
+/*
+ * Decode key from its hex representation
+ */
+static int crypt_decode_key(u8 *key, char *hex, int size)
+{
+	char buffer[3];
+	char *endp;
+	int i;
+
+	buffer[2] = '\0';
+
+	for(i = 0; i < size; i++) {
+		buffer[0] = *hex++;
+		buffer[1] = *hex++;
+
+		key[i] = (u8)simple_strtoul(buffer, &endp, 16);
+
+		if (endp != &buffer[2])
+			return -EINVAL;
+	}
+
+	if (*hex != '\0')
+		return -EINVAL;
+
+	return 0;
+}
+
+/*
+ * Encode key into its hex representation
+ */
+static void crypt_encode_key(char *hex, u8 *key, int size)
+{
+	static char hex_digits[] = "0123456789abcdef";
+	int i;
+
+	for(i = 0; i < size; i++) {
+		*hex++ = hex_digits[*key >> 4];
+		*hex++ = hex_digits[*key & 0x0f];
+		key++;
+	}
+
+	*hex++ = '\0';
+}
+
+/*
+ * Construct an encryption mapping:
+ * <cipher> <key> <iv_offset> <dev_path> <start>
+ */
+static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
+{
+	struct crypt_config *cc;
+	struct crypto_tfm *tfm;
+	char *tmp;
+	char *cipher;
+	char *mode;
+	int crypto_flags;
+	int key_size;
+
+	if (argc != 5) {
+		ti->error = "dm-crypt: Not enough arguments";
+		return -EINVAL;
+	}
+
+	tmp = argv[0];
+	cipher = strsep(&tmp, "-");
+	mode = strsep(&tmp, "-");
+
+	if (tmp)
+		DMWARN("dm-crypt: Unexpected additional cipher options");
+
+	key_size = strlen(argv[1]) >> 1;
+
+	cc = kmalloc(sizeof(*cc) + key_size * sizeof(u8), GFP_KERNEL);
+	if (cc == NULL) {
+		ti->error =
+			"dm-crypt: Cannot allocate transparent encryption context";
+		return -ENOMEM;
+	}
+
+	if (!mode || strcmp(mode, "plain") == 0)
+		cc->iv_generator = crypt_iv_plain;
+	else if (strcmp(mode, "ecb") == 0)
+		cc->iv_generator = NULL;
+	else {
+		ti->error = "dm-crypt: Invalid chaining mode";
+		return -EINVAL;
+	}
+
+	if (cc->iv_generator)
+		crypto_flags = CRYPTO_TFM_MODE_CBC;
+	else
+		crypto_flags = CRYPTO_TFM_MODE_ECB;
+
+	tfm = crypto_alloc_tfm(cipher, crypto_flags);
+	if (!tfm) {
+		ti->error = "dm-crypt: Error allocating crypto tfm";
+		goto bad1;
+	}
+
+	if (tfm->crt_u.cipher.cit_decrypt_iv && tfm->crt_u.cipher.cit_encrypt_iv)
+		/* at least a 32 bit sector number should fit in our buffer */
+		cc->iv_size = max(crypto_tfm_alg_ivsize(tfm), 
+		                  (unsigned int)(sizeof(u32) / sizeof(u8)));
+	else {
+		cc->iv_size = 0;
+		if (cc->iv_generator) {
+			DMWARN("dm-crypt: Selected cipher does not support IVs");
+			cc->iv_generator = NULL;
+		}
+	}
+
+	cc->io_pool = mempool_create(MIN_IOS, mempool_alloc_slab,
+				     mempool_free_slab, _crypt_io_pool);
+	if (!cc->io_pool) {
+		ti->error = "dm-crypt: Cannot allocate crypt io mempool";
+		goto bad2;
+	}
+
+	cc->page_pool = mempool_create(MIN_POOL_PAGES, mempool_alloc_page,
+				       mempool_free_page, NULL);
+	if (!cc->page_pool) {
+		ti->error = "dm-crypt: Cannot allocate page mempool";
+		goto bad3;
+	}
+
+	cc->tfm = tfm;
+	cc->key_size = key_size;
+	if ((key_size == 0 && strcmp(argv[1], "-") != 0)
+	    || crypt_decode_key(cc->key, argv[1], key_size) < 0) {
+		ti->error = "dm-crypt: Error decoding key";
+		goto bad4;
+	}
+
+	if (tfm->crt_u.cipher.cit_setkey(tfm, cc->key, key_size) < 0) {
+		ti->error = "dm-crypt: Error setting key";
+		goto bad4;
+	}
+
+	if (sscanf(argv[2], SECTOR_FORMAT, &cc->iv_offset) != 1) {
+		ti->error = "dm-crypt: Invalid iv_offset sector";
+		goto bad4;
+	}
+
+	if (sscanf(argv[4], SECTOR_FORMAT, &cc->start) != 1) {
+		ti->error = "dm-crypt: Invalid device sector";
+		goto bad4;
+	}
+
+	if (dm_get_device(ti, argv[3], cc->start, ti->len,
+	                  dm_table_get_mode(ti->table), &cc->dev)) {
+		ti->error = "dm-crypt: Device lookup failed";
+		goto bad4;
+	}
+
+	ti->private = cc;
+	return 0;
+
+bad4:
+	mempool_destroy(cc->page_pool);
+bad3:
+	mempool_destroy(cc->io_pool);
+bad2:
+	crypto_free_tfm(tfm);
+bad1:
+	kfree(cc);
+	return -EINVAL;
+}
+
+static void crypt_dtr(struct dm_target *ti)
+{
+	struct crypt_config *cc = (struct crypt_config *) ti->private;
+
+	mempool_destroy(cc->page_pool);
+	mempool_destroy(cc->io_pool);
+
+	crypto_free_tfm(cc->tfm);
+	dm_put_device(ti, cc->dev);
+	kfree(cc);
+}
+
+static int crypt_endio(struct bio *bio, unsigned int done, int error)
+{
+	struct crypt_io *io = (struct crypt_io *) bio->bi_private;
+	struct crypt_config *cc = (struct crypt_config *) io->target->private;
+
+	if (bio_rw(bio) == WRITE) {
+		/*
+		 * free the processed pages, even if
+		 * it's only a partially completed write
+		 */
+		crypt_free_buffer_pages(cc, bio, done);
+	}
+
+	if (bio->bi_size)
+		return 1;
+
+	/*
+	 * successful reads are decrypted by the worker thread
+	 */
+	if ((bio_rw(bio) == READ || bio_rw(bio) == READA)
+	    && bio_flagged(bio, BIO_UPTODATE)) {
+		kcryptd_queue_bio(bio);
+		wake_up_process(_kcryptd);
+		return 0;
+	}
+
+	bio_put(bio);
+	dec_pending(io, error);
+
+	return error;
+}
+
+static int crypt_map(struct dm_target *ti, struct bio *bio,
+                     union map_info *map_context)
+{
+	struct crypt_config *cc = (struct crypt_config *) ti->private;
+	struct crypt_io *io = mempool_alloc(cc->io_pool, GFP_NOIO);
+	struct bio *clone = NULL;
+	struct convert_context ctx;
+	unsigned int remaining = bio->bi_size;
+	sector_t sector = bio->bi_sector - ti->begin;
+	int bio_vec_idx = 0;
+	int r = 0;
+
+	io->target = ti;
+	io->bio = bio;
+	io->first_clone = NULL;
+	io->error = 0;
+	atomic_set(&io->pending, 1); /* hold a reference */
+
+	if (bio_rw(bio) == WRITE)
+		crypt_convert_init(cc, &ctx, NULL, bio, sector, 1);
+
+	/*
+	 * The allocated buffers can be smaller than the whole bio,
+	 * so repeat the whole process until all the data can be handled.
+	 */
+	while (remaining) {
+		if (bio_rw(bio) == WRITE) {
+			clone = crypt_alloc_buffer(cc, bio->bi_size,
+			                           io->first_clone,
+			                           &bio_vec_idx);
+			if (clone) {
+				ctx.bio_out = clone;
+				r = crypt_convert(cc, &ctx);
+				if (r < 0) {
+					crypt_free_buffer_pages(cc, clone,
+					                        clone->bi_size);
+					bio_put(clone);
+					goto cleanup;
+				}
+			}
+		} else
+			clone = bio_clone(bio, GFP_NOIO);
+
+		if (!clone) {
+			r = -ENOMEM;
+			goto cleanup;
+		}
+
+		if (!io->first_clone) {
+			/*
+			 * hold a reference to the first clone, because it
+			 * holds the bio_vec array and that can't be freed
+			 * before all other clones are released
+			 */
+			bio_get(clone);
+			io->first_clone = clone;
+		}
+		atomic_inc(&io->pending);
+
+		clone->bi_private = io;
+		clone->bi_end_io = crypt_endio;
+		clone->bi_bdev = cc->dev->bdev;
+		clone->bi_sector = cc->start + sector;
+		clone->bi_rw = bio->bi_rw;
+
+		remaining -= clone->bi_size;
+		sector += bio_sectors(clone);
+
+		generic_make_request(clone);
+	}
+
+	/* drop reference, clones could have returned before we reach this */
+	dec_pending(io, 0);
+	return 0;
+
+cleanup:
+	if (io->first_clone) {
+		dec_pending(io, r);
+		return 0;
+	}
+
+	/* if no bio has been dispatched yet, we can directly return the error */
+	mempool_free(io, cc->io_pool);
+	return r;
+}
+
+static int crypt_status(struct dm_target *ti, status_type_t type,
+			char *result, unsigned int maxlen)
+{
+	struct crypt_config *cc = (struct crypt_config *) ti->private;
+	char buffer[32];
+	const char *cipher;
+	const char *mode = NULL;
+	int offset;
+
+	switch (type) {
+	case STATUSTYPE_INFO:
+		result[0] = '\0';
+		break;
+
+	case STATUSTYPE_TABLE:
+		cipher = crypto_tfm_alg_name(cc->tfm);
+
+		switch(cc->tfm->crt_u.cipher.cit_mode) {
+		case CRYPTO_TFM_MODE_CBC:
+			mode = "plain";
+			break;
+		case CRYPTO_TFM_MODE_ECB:
+			mode = "ecb";
+			break;
+		default:
+			BUG();
+		}
+
+		snprintf(result, maxlen, "%s-%s ", cipher, mode);
+		offset = strlen(result);
+
+		if (cc->key_size > 0) {
+			if ((maxlen - offset) < ((cc->key_size << 1) + 1))
+				return -ENOMEM;
+
+			crypt_encode_key(result + offset, cc->key, cc->key_size);
+			offset += cc->key_size << 1;
+		} else {
+			if (offset >= maxlen)
+				return -ENOMEM;
+			result[offset++] = '-';
+		}
+
+		format_dev_t(buffer, cc->dev->bdev->bd_dev);
+		snprintf(result + offset, maxlen - offset, " " SECTOR_FORMAT
+		         " %s " SECTOR_FORMAT, cc->iv_offset,
+		         buffer, cc->start);
+		break;
+	}
+	return 0;
+}
+
+static struct target_type crypt_target = {
+	.name   = "crypt",
+	.module = THIS_MODULE,
+	.ctr    = crypt_ctr,
+	.dtr    = crypt_dtr,
+	.map    = crypt_map,
+	.status = crypt_status,
+};
+
+static int __init dm_crypt_init(void)
+{
+	int r;
+
+	_crypt_io_pool = kmem_cache_create("dm-crypt_io",
+	                                   sizeof(struct crypt_io),
+	                                   0, 0, NULL, NULL);
+	if (!_crypt_io_pool)
+		return -ENOMEM;
+
+	_kcryptd = kthread_create(kcryptd_do_work, NULL, "kcryptd");
+	if (IS_ERR(_kcryptd)) {
+		r = PTR_ERR(_kcryptd);
+		DMERR("couldn't create kcryptd: %d", r);
+		kmem_cache_destroy(_crypt_io_pool);
+		return r;
+	}
+
+	r = dm_register_target(&crypt_target);
+	if (r < 0) {
+		DMERR("crypt: register failed %d", r);
+		kthread_stop(_kcryptd);
+		kmem_cache_destroy(_crypt_io_pool);
+		return r;
+	}
+
+	wake_up_process(_kcryptd);
+	return 0;
+}
+
+static void __exit dm_crypt_exit(void)
+{
+	int r = dm_unregister_target(&crypt_target);
+
+	if (r < 0)
+		DMERR("crypt: unregister failed %d", r);
+
+	kthread_stop(_kcryptd);
+	kmem_cache_destroy(_crypt_io_pool);
+}
+
+module_init(dm_crypt_init);
+module_exit(dm_crypt_exit);
+
+MODULE_AUTHOR("Christophe Saout <christophe@saout.de>");
+MODULE_DESCRIPTION(DM_NAME " target for transparent encryption / decryption");
+MODULE_LICENSE("GPL");
diff -Nur linux-2.6.3-rc3-mm1.orig/drivers/md/Kconfig linux-2.6.3-rc3-mm1/drivers/md/Kconfig
--- linux-2.6.3-rc3-mm1.orig/drivers/md/Kconfig	2004-02-10 18:06:13.000000000 +0100
+++ linux-2.6.3-rc3-mm1/drivers/md/Kconfig	2004-02-16 01:30:51.000000000 +0100
@@ -170,5 +170,17 @@
 	  Recent tools use a new version of the ioctl interface, only
           select this option if you intend using such tools.
 
+config DM_CRYPT
+	tristate "Crypt target support"
+	depends on BLK_DEV_DM && EXPERIMENTAL
+	select CRYPTO
+	---help---
+	  This device-mapper target allows you to create a device that
+	  transparently encrypts the data on it. You'll need to activate
+	  the required ciphers in the cryptoapi configuration in order to
+	  be able to use it.
+
+	  If unsure, say N.
+
 endmenu
 
diff -Nur linux-2.6.3-rc3-mm1.orig/drivers/md/Makefile linux-2.6.3-rc3-mm1/drivers/md/Makefile
--- linux-2.6.3-rc3-mm1.orig/drivers/md/Makefile	2004-02-16 01:24:17.000000000 +0100
+++ linux-2.6.3-rc3-mm1/drivers/md/Makefile	2004-02-16 01:30:51.000000000 +0100
@@ -23,6 +23,7 @@
 obj-$(CONFIG_MD_MULTIPATH)	+= multipath.o
 obj-$(CONFIG_BLK_DEV_MD)	+= md.o
 obj-$(CONFIG_BLK_DEV_DM)	+= dm-mod.o
+obj-$(CONFIG_DM_CRYPT)		+= dm-crypt.o
 
 quiet_cmd_unroll = UNROLL  $@
       cmd_unroll = $(PERL) $(srctree)/$(src)/unroll.pl $(UNROLL) \

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Andrew Morton]

Christophe Saout <christophe@saout.de> wrote:
>
> +	  This device-mapper target allows you to create a device that
>  +	  transparently encrypts the data on it. You'll need to activate
>  +	  the required ciphers in the cryptoapi configuration in order to
>  +	  be able to use it.

Is there more documentation that this?  I'd imagine a lot of crypto-loop
users wouldn't have a clue how to get started on dm-crypt, especially if
they have not used device mapper before.

And how do they migrate existing encrypted filesytems?

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Grzegorz Kulewski]

On Sun, 15 Feb 2004, Andrew Morton wrote:

> Is there more documentation that this?  I'd imagine a lot of crypto-loop
> users wouldn't have a clue how to get started on dm-crypt, especially if
> they have not used device mapper before.
> 
> And how do they migrate existing encrypted filesytems?

And is the format considered "stable"?
(= if I will create fs on it, will I have problems with future kernels?)


Grzegorz Kulewski

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Andrew Morton]

Christophe Saout <christophe@saout.de> wrote:
>
> +static struct bio *
> +crypt_alloc_buffer(struct crypt_config *cc, unsigned int size,
> +                   struct bio *base_bio, int *bio_vec_idx)
> +{
> ...
> +	/*
> +	 * Tell VM to act less aggressively and fail earlier.
> +	 * This is not necessary but increases throughput.
> +	 * FIXME: Is this really intelligent?
> +	 */
> +	current->flags &= ~PF_MEMALLOC;

This is a bit peculiar.  Is it still the case that it increases throughput?
 How come?

> +	if (base_bio)
> +		bio = bio_clone(base_bio, GFP_NOIO);
> +	else
> +		bio = bio_alloc(GFP_NOIO, nr_iovecs);
> +	if (!bio)
> +		return NULL;

Should restore PF_MEMALLOC here.

> +static int kcryptd_do_work(void *data)
> +{
> +	current->flags |= PF_IOTHREAD;
> +
> +	for(;;) {
> +		struct bio *bio;
> +
> +		set_task_state(current, TASK_INTERRUPTIBLE);
> +		while (!(bio = kcryptd_get_bios())) {
> +			schedule();
> +			if (signal_pending(current))
> +				return 0;
> +		}

This will turn into a busy-loop, because schedule() sets current->state to
TASK_RUNNING.  You need to move the set_task_state(current,
TASK_INTERRUPTIBLE); inside the loop.

Why is this code mucking with signals?

Perhaps a call to blk_congestion_wait() would be appropriate here.

> +/*
> + * Encode key into its hex representation
> + */
> +static void crypt_encode_key(char *hex, u8 *key, int size)
> +{
> +	static char hex_digits[] = "0123456789abcdef";
> +	int i;
> +
> +	for(i = 0; i < size; i++) {
> +		*hex++ = hex_digits[*key >> 4];
> +		*hex++ = hex_digits[*key & 0x0f];
> +		key++;
> +	}
> +
> +	*hex++ = '\0';
> +}

sprintf("%02x")?

Re: dm-crypt using kthread

[Jeff Garzik]

Christophe Saout wrote:
> diff -Nur linux-2.6.3-rc3-mm1.orig/drivers/md/dm-crypt.c linux-2.6.3-rc3-mm1/drivers/md/dm-crypt.c
> --- linux-2.6.3-rc3-mm1.orig/drivers/md/dm-crypt.c	1970-01-01 01:00:00.000000000 +0100
> +++ linux-2.6.3-rc3-mm1/drivers/md/dm-crypt.c	2004-02-16 01:47:37.000000000 +0100

Overall it looks pretty nice and clean, but some issues...



> +#define MIN_IOS        256
> +#define MIN_POOL_PAGES 32
> +#define MIN_BIO_PAGES  8

> +static kmem_cache_t *_crypt_io_pool;

> +static struct bio *
> +crypt_alloc_buffer(struct crypt_config *cc, unsigned int size,
> +                   struct bio *base_bio, int *bio_vec_idx)
> +{
> +	struct bio *bio;
> +	int nr_iovecs = dm_div_up(size, PAGE_SIZE);
> +	int gfp_mask = GFP_NOIO | __GFP_HIGHMEM;
> +	int flags = current->flags;
> +	int i;
> +
> +	/*
> +	 * Tell VM to act less aggressively and fail earlier.
> +	 * This is not necessary but increases throughput.
> +	 * FIXME: Is this really intelligent?
> +	 */
> +	current->flags &= ~PF_MEMALLOC;
> +
> +	if (base_bio)
> +		bio = bio_clone(base_bio, GFP_NOIO);
> +	else
> +		bio = bio_alloc(GFP_NOIO, nr_iovecs);

Ewww.  Somebody (not you) should be thwapped for the ordering of the 
gfp_mask argument in each bio_xxx function.



> +		/*
> +		 * if additional pages cannot be allocated without waiting,
> +		 * return a partially allocated bio, the caller will then try
> +		 * to allocate additional bios while submitting this partial bio
> +		 */
> +		if ((i - bio->bi_idx) == (MIN_BIO_PAGES - 1))
> +			gfp_mask = (gfp_mask | __GFP_NOWARN) & ~__GFP_WAIT;

If the caller said they can wait, why not wait?



> +static void dec_pending(struct crypt_io *io, int error)
> +{
> +	struct crypt_config *cc = (struct crypt_config *) io->target->private;
> +
> +	if (error < 0)
> +		io->error = error;
> +
> +	if (!atomic_dec_and_test(&io->pending))
> +		return;
> +
> +	if (io->first_clone)
> +		bio_put(io->first_clone);

> +	if (io->bio)
> +		bio_endio(io->bio, io->bio->bi_size, io->error);

when does io->bio==NULL ?



> +static spinlock_t _kcryptd_lock = SPIN_LOCK_UNLOCKED;
> +static struct bio_list _kcryptd_bios;
> +
> +static struct task_struct *_kcryptd;
> +
> +/*
> + * Fetch a list of the complete bios.
> + */
> +static struct bio *kcryptd_get_bios(void)
> +{
> +	struct bio *bio;
> +
> +	spin_lock_irq(&_kcryptd_lock);
> +	bio = bio_list_get(&_kcryptd_bios);
> +	spin_unlock_irq(&_kcryptd_lock);
> +
> +	return bio;
> +}
> +
> +/*
> + * Append bio to work queue
> + */
> +static void kcryptd_queue_bio(struct bio *bio)
> +{
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&_kcryptd_lock, flags);
> +	bio_list_add(&_kcryptd_bios, bio);
> +	spin_unlock_irqrestore(&_kcryptd_lock, flags);
> +}
> +
> +static int kcryptd_do_work(void *data)
> +{
> +	current->flags |= PF_IOTHREAD;
> +
> +	for(;;) {
> +		struct bio *bio;
> +
> +		set_task_state(current, TASK_INTERRUPTIBLE);
> +		while (!(bio = kcryptd_get_bios())) {
> +			schedule();
> +			if (signal_pending(current))
> +				return 0;
> +		}
> +		set_task_state(current, TASK_RUNNING);

You just keep calling schedule() rapid-fire until you get a bio?  That's 
a bit sub-optimal.

This seems like a semaphore is needed.


> +		while (bio) {
> +			struct crypt_io *io;
> +			struct crypt_config *cc;
> +			struct convert_context ctx;
> +			struct bio *next_bio;
> +			int r;
> +
> +			io = (struct crypt_io *) bio->bi_private;
> +			cc = (struct crypt_config *) io->target->private;
> +
> +			crypt_convert_init(cc, &ctx, io->bio, io->bio,
> +				io->bio->bi_sector - io->target->begin, 0);
> +			r = crypt_convert(cc, &ctx);
> +
> +			next_bio = bio->bi_next;
> +			bio->bi_next = NULL;
> +
> +			bio_put(bio);
> +			dec_pending(io, r);
> +
> +			bio = next_bio;
> +		}
> +	}
> +}
> +
> +/*
> + * Encode key into its hex representation
> + */
> +static void crypt_encode_key(char *hex, u8 *key, int size)
> +{
> +	static char hex_digits[] = "0123456789abcdef";

static const


> +/*
> + * Construct an encryption mapping:
> + * <cipher> <key> <iv_offset> <dev_path> <start>
> + */
> +static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
> +{
> +	struct crypt_config *cc;
> +	struct crypto_tfm *tfm;
> +	char *tmp;
> +	char *cipher;
> +	char *mode;
> +	int crypto_flags;
> +	int key_size;
> +
> +	if (argc != 5) {
> +		ti->error = "dm-crypt: Not enough arguments";
> +		return -EINVAL;
> +	}
> +
> +	tmp = argv[0];
> +	cipher = strsep(&tmp, "-");
> +	mode = strsep(&tmp, "-");
> +
> +	if (tmp)
> +		DMWARN("dm-crypt: Unexpected additional cipher options");
> +
> +	key_size = strlen(argv[1]) >> 1;
> +
> +	cc = kmalloc(sizeof(*cc) + key_size * sizeof(u8), GFP_KERNEL);
> +	if (cc == NULL) {
> +		ti->error =
> +			"dm-crypt: Cannot allocate transparent encryption context";
> +		return -ENOMEM;
> +	}
> +
> +	if (!mode || strcmp(mode, "plain") == 0)
> +		cc->iv_generator = crypt_iv_plain;
> +	else if (strcmp(mode, "ecb") == 0)
> +		cc->iv_generator = NULL;
> +	else {
> +		ti->error = "dm-crypt: Invalid chaining mode";
> +		return -EINVAL;
> +	}

memory leak on error


> +	if (cc->iv_generator)
> +		crypto_flags = CRYPTO_TFM_MODE_CBC;
> +	else
> +		crypto_flags = CRYPTO_TFM_MODE_ECB;
> +
> +	tfm = crypto_alloc_tfm(cipher, crypto_flags);
> +	if (!tfm) {
> +		ti->error = "dm-crypt: Error allocating crypto tfm";
> +		goto bad1;
> +	}
> +
> +	if (tfm->crt_u.cipher.cit_decrypt_iv && tfm->crt_u.cipher.cit_encrypt_iv)
> +		/* at least a 32 bit sector number should fit in our buffer */
> +		cc->iv_size = max(crypto_tfm_alg_ivsize(tfm), 
> +		                  (unsigned int)(sizeof(u32) / sizeof(u8)));
> +	else {
> +		cc->iv_size = 0;
> +		if (cc->iv_generator) {
> +			DMWARN("dm-crypt: Selected cipher does not support IVs");
> +			cc->iv_generator = NULL;
> +		}
> +	}
> +
> +	cc->io_pool = mempool_create(MIN_IOS, mempool_alloc_slab,
> +				     mempool_free_slab, _crypt_io_pool);
> +	if (!cc->io_pool) {
> +		ti->error = "dm-crypt: Cannot allocate crypt io mempool";
> +		goto bad2;
> +	}
> +
> +	cc->page_pool = mempool_create(MIN_POOL_PAGES, mempool_alloc_page,
> +				       mempool_free_page, NULL);
> +	if (!cc->page_pool) {
> +		ti->error = "dm-crypt: Cannot allocate page mempool";
> +		goto bad3;
> +	}
> +
> +	cc->tfm = tfm;
> +	cc->key_size = key_size;
> +	if ((key_size == 0 && strcmp(argv[1], "-") != 0)
> +	    || crypt_decode_key(cc->key, argv[1], key_size) < 0) {
> +		ti->error = "dm-crypt: Error decoding key";
> +		goto bad4;
> +	}
> +
> +	if (tfm->crt_u.cipher.cit_setkey(tfm, cc->key, key_size) < 0) {
> +		ti->error = "dm-crypt: Error setting key";
> +		goto bad4;
> +	}
> +
> +	if (sscanf(argv[2], SECTOR_FORMAT, &cc->iv_offset) != 1) {
> +		ti->error = "dm-crypt: Invalid iv_offset sector";
> +		goto bad4;
> +	}
> +
> +	if (sscanf(argv[4], SECTOR_FORMAT, &cc->start) != 1) {
> +		ti->error = "dm-crypt: Invalid device sector";
> +		goto bad4;
> +	}
> +
> +	if (dm_get_device(ti, argv[3], cc->start, ti->len,
> +	                  dm_table_get_mode(ti->table), &cc->dev)) {
> +		ti->error = "dm-crypt: Device lookup failed";
> +		goto bad4;
> +	}
> +
> +	ti->private = cc;
> +	return 0;
> +
> +bad4:
> +	mempool_destroy(cc->page_pool);
> +bad3:
> +	mempool_destroy(cc->io_pool);
> +bad2:
> +	crypto_free_tfm(tfm);
> +bad1:
> +	kfree(cc);
> +	return -EINVAL;
> +}
> +
> +static void crypt_dtr(struct dm_target *ti)
> +{
> +	struct crypt_config *cc = (struct crypt_config *) ti->private;
> +
> +	mempool_destroy(cc->page_pool);
> +	mempool_destroy(cc->io_pool);
> +
> +	crypto_free_tfm(cc->tfm);
> +	dm_put_device(ti, cc->dev);
> +	kfree(cc);
> +}
> +
> +static int crypt_endio(struct bio *bio, unsigned int done, int error)
> +{
> +	struct crypt_io *io = (struct crypt_io *) bio->bi_private;
> +	struct crypt_config *cc = (struct crypt_config *) io->target->private;
> +
> +	if (bio_rw(bio) == WRITE) {
> +		/*
> +		 * free the processed pages, even if
> +		 * it's only a partially completed write
> +		 */
> +		crypt_free_buffer_pages(cc, bio, done);
> +	}
> +
> +	if (bio->bi_size)
> +		return 1;

dumb question, for my own knowledge:  what does this 'if' test do?


> +static int crypt_map(struct dm_target *ti, struct bio *bio,
> +                     union map_info *map_context)
> +{
> +	struct crypt_config *cc = (struct crypt_config *) ti->private;
> +	struct crypt_io *io = mempool_alloc(cc->io_pool, GFP_NOIO);
> +	struct bio *clone = NULL;
> +	struct convert_context ctx;
> +	unsigned int remaining = bio->bi_size;
> +	sector_t sector = bio->bi_sector - ti->begin;
> +	int bio_vec_idx = 0;
> +	int r = 0;
> +
> +	io->target = ti;
> +	io->bio = bio;
> +	io->first_clone = NULL;
> +	io->error = 0;
> +	atomic_set(&io->pending, 1); /* hold a reference */
> +
> +	if (bio_rw(bio) == WRITE)
> +		crypt_convert_init(cc, &ctx, NULL, bio, sector, 1);
> +
> +	/*
> +	 * The allocated buffers can be smaller than the whole bio,
> +	 * so repeat the whole process until all the data can be handled.
> +	 */
> +	while (remaining) {
> +		if (bio_rw(bio) == WRITE) {
> +			clone = crypt_alloc_buffer(cc, bio->bi_size,
> +			                           io->first_clone,
> +			                           &bio_vec_idx);
> +			if (clone) {
> +				ctx.bio_out = clone;
> +				r = crypt_convert(cc, &ctx);
> +				if (r < 0) {
> +					crypt_free_buffer_pages(cc, clone,
> +					                        clone->bi_size);
> +					bio_put(clone);
> +					goto cleanup;
> +				}
> +			}
> +		} else
> +			clone = bio_clone(bio, GFP_NOIO);
> +
> +		if (!clone) {
> +			r = -ENOMEM;
> +			goto cleanup;
> +		}
> +
> +		if (!io->first_clone) {
> +			/*
> +			 * hold a reference to the first clone, because it
> +			 * holds the bio_vec array and that can't be freed
> +			 * before all other clones are released
> +			 */
> +			bio_get(clone);
> +			io->first_clone = clone;
> +		}
> +		atomic_inc(&io->pending);
> +
> +		clone->bi_private = io;
> +		clone->bi_end_io = crypt_endio;
> +		clone->bi_bdev = cc->dev->bdev;
> +		clone->bi_sector = cc->start + sector;
> +		clone->bi_rw = bio->bi_rw;
> +
> +		remaining -= clone->bi_size;
> +		sector += bio_sectors(clone);

would be nice to move this code into a separate "create and init my 
clone" function, simply to be ease review and make things a bit more 
clear...


> +		generic_make_request(clone);
> +	}
> +
> +	/* drop reference, clones could have returned before we reach this */
> +	dec_pending(io, 0);
> +	return 0;
> +
> +cleanup:
> +	if (io->first_clone) {
> +		dec_pending(io, r);
> +		return 0;
> +	}
> +
> +	/* if no bio has been dispatched yet, we can directly return the error */
> +	mempool_free(io, cc->io_pool);
> +	return r;
> +}
> +
> +static int crypt_status(struct dm_target *ti, status_type_t type,
> +			char *result, unsigned int maxlen)
> +{
> +	struct crypt_config *cc = (struct crypt_config *) ti->private;
> +	char buffer[32];
> +	const char *cipher;
> +	const char *mode = NULL;
> +	int offset;
> +
> +	switch (type) {
> +	case STATUSTYPE_INFO:
> +		result[0] = '\0';
> +		break;
> +
> +	case STATUSTYPE_TABLE:
> +		cipher = crypto_tfm_alg_name(cc->tfm);
> +
> +		switch(cc->tfm->crt_u.cipher.cit_mode) {
> +		case CRYPTO_TFM_MODE_CBC:
> +			mode = "plain";
> +			break;
> +		case CRYPTO_TFM_MODE_ECB:
> +			mode = "ecb";
> +			break;
> +		default:
> +			BUG();
> +		}
> +
> +		snprintf(result, maxlen, "%s-%s ", cipher, mode);
> +		offset = strlen(result);
> +
> +		if (cc->key_size > 0) {
> +			if ((maxlen - offset) < ((cc->key_size << 1) + 1))
> +				return -ENOMEM;
> +
> +			crypt_encode_key(result + offset, cc->key, cc->key_size);
> +			offset += cc->key_size << 1;
> +		} else {
> +			if (offset >= maxlen)
> +				return -ENOMEM;
> +			result[offset++] = '-';
> +		}
> +
> +		format_dev_t(buffer, cc->dev->bdev->bd_dev);
> +		snprintf(result + offset, maxlen - offset, " " SECTOR_FORMAT
> +		         " %s " SECTOR_FORMAT, cc->iv_offset,
> +		         buffer, cc->start);
> +		break;
> +	}
> +	return 0;
> +}
> +
> +static struct target_type crypt_target = {
> +	.name   = "crypt",
> +	.module = THIS_MODULE,
> +	.ctr    = crypt_ctr,
> +	.dtr    = crypt_dtr,
> +	.map    = crypt_map,
> +	.status = crypt_status,
> +};
> +
> +static int __init dm_crypt_init(void)
> +{
> +	int r;
> +
> +	_crypt_io_pool = kmem_cache_create("dm-crypt_io",
> +	                                   sizeof(struct crypt_io),
> +	                                   0, 0, NULL, NULL);
> +	if (!_crypt_io_pool)
> +		return -ENOMEM;
> +
> +	_kcryptd = kthread_create(kcryptd_do_work, NULL, "kcryptd");
> +	if (IS_ERR(_kcryptd)) {
> +		r = PTR_ERR(_kcryptd);
> +		DMERR("couldn't create kcryptd: %d", r);
> +		kmem_cache_destroy(_crypt_io_pool);
> +		return r;
> +	}

> +	r = dm_register_target(&crypt_target);
> +	if (r < 0) {
> +		DMERR("crypt: register failed %d", r);
> +		kthread_stop(_kcryptd);
> +		kmem_cache_destroy(_crypt_io_pool);
> +		return r;
> +	}

might want to use the standard 'goto' style exception handling here too, 
instead of duplicating the error unwind code.

Overall, needs a tiny bit of work, but I like it.

	Jeff

Re: dm-crypt using kthread

[Jeff Garzik]

Andrew Morton wrote:
>>+static void crypt_encode_key(char *hex, u8 *key, int size)
>>+{
>>+	static char hex_digits[] = "0123456789abcdef";
>>+	int i;
>>+
>>+	for(i = 0; i < size; i++) {
>>+		*hex++ = hex_digits[*key >> 4];
>>+		*hex++ = hex_digits[*key & 0x0f];
>>+		key++;
>>+	}
>>+
>>+	*hex++ = '\0';
>>+}
> 
> 
> sprintf("%02x")?


I was thinking that too.  How often do we encode the key?  If not often 
(and I would guess not), sprintf would be more than sufficient.

	Jeff

Re: dm-crypt using kthread

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb Jeff Garzik um 03:10:

> > +		/*
> > +		 * if additional pages cannot be allocated without waiting,
> > +		 * return a partially allocated bio, the caller will then try
> > +		 * to allocate additional bios while submitting this partial bio
> > +		 */
> > +		if ((i - bio->bi_idx) == (MIN_BIO_PAGES - 1))
> > +			gfp_mask = (gfp_mask | __GFP_NOWARN) & ~__GFP_WAIT;
> 
> If the caller said they can wait, why not wait?

How can the caller say this?

This is basically to avoid deadlocks. The kernel might decide to flush
data in order to free memory (or even swap out). dm-crypt needs to
allocate buffers for encryption. If we run out of memory we need to be
able to write something in order to get new memory. Successful writes
will return some pages to the pool and potentially wake up some threads
needing these.

> > +static void dec_pending(struct crypt_io *io, int error)
> > [...]
> > +	if (io->bio)
> > +		bio_endio(io->bio, io->bio->bi_size, io->error);
> 
> when does io->bio==NULL ?

Umm, right. Can't ever happen. Thanks.

> > +		set_task_state(current, TASK_INTERRUPTIBLE);
> > +		while (!(bio = kcryptd_get_bios())) {
> > +			schedule();
> > +			if (signal_pending(current))
> > +				return 0;
> > +		}
> > +		set_task_state(current, TASK_RUNNING);
> 
> You just keep calling schedule() rapid-fire until you get a bio?  That's 
> a bit sub-optimal.

That's wrong anyway. I was just making sure I was calling
kcryptd_get_bios after schedule. schedule() will sleep and woken after
someone added a bio to the list.

I've changed it to an if now and call kcryptd_get_bios after schedule.

I'm calling it twice because it is likely that someone started a new
list while the old list is being processed and I don't want to sleep in
this case, just fall through.

The kcryptd_get_bios needs to be after state = TASK_INTERRUPTIBLE to
avoid a race. If someone wakes the process after kcryptd_get_bios but
before schedule it resets the state to TASK_RUNNING so that the schedule
won't sleep.

> > +/*
> > + * Encode key into its hex representation
> > + */
> > +static void crypt_encode_key(char *hex, u8 *key, int size)
> > +{
> > +	static char hex_digits[] = "0123456789abcdef";
> 
> static const

Or sprintf... I doubt this would result in shorter code but it would be
more consistent.

> > +	if (!mode || strcmp(mode, "plain") == 0)
> > +		cc->iv_generator = crypt_iv_plain;
> > +	else if (strcmp(mode, "ecb") == 0)
> > +		cc->iv_generator = NULL;
> > +	else {
> > +		ti->error = "dm-crypt: Invalid chaining mode";
> > +		return -EINVAL;
> > +	}
> 
> memory leak on error

Ouch. Thanks.

> > +static int crypt_endio(struct bio *bio, unsigned int done, int error)
> > +{
> > +	struct crypt_io *io = (struct crypt_io *) bio->bi_private;
> > +	struct crypt_config *cc = (struct crypt_config *) io->target->private;
> > +
> > +	if (bio_rw(bio) == WRITE) {
> > +		/*
> > +		 * free the processed pages, even if
> > +		 * it's only a partially completed write
> > +		 */
> > +		crypt_free_buffer_pages(cc, bio, done);
> > +	}
> > +
> > +	if (bio->bi_size)
> > +		return 1;
> 
> dumb question, for my own knowledge:  what does this 'if' test do?

It checks whether has bio has been completed. The block layer may notify
us if parts of the bio has been finished.

> 
> > +static int crypt_map(struct dm_target *ti, struct bio *bio,
> > +                     union map_info *map_context)
> > [...]
>
> would be nice to move this code into a separate "create and init my 
> clone" function, simply to be ease review and make things a bit more 
> clear...

create and init would be the whole content of the loop. But if you think
so, I can do that.

> might want to use the standard 'goto' style exception handling here too, 
> instead of duplicating the error unwind code.

Yes, the function got larger over time.

> Overall, needs a tiny bit of work, but I like it.

Thanks.

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout]

Hi,

[shoot me, I forgot the Cc's the first time]

> > +	/*
> > +	 * Tell VM to act less aggressively and fail earlier.
> > +	 * This is not necessary but increases throughput.
> > +	 * FIXME: Is this really intelligent?
> > +	 */
> > +	current->flags &= ~PF_MEMALLOC;
> 
> This is a bit peculiar.  Is it still the case that it increases throughput?

Were there changes to the VM?

> How come?

I'm not exactly sure either. But this is what I suspected:

The VM wants to write out some pages. dm-crypt wants to allocate buffers
and starts digging into the reservers because PF_MEMALLOC is set which
causes some sort of low-memory condition.

If PF_MEMALLOC is dropped here the VM can just drop some cache pages in
order to allocate buffers.

If there wasn't a lot of free (unused) memory the machine often started
writing out data when I tried to write a lot of data using dd. The
seeking killed performance, just for the first seconds though.

It's not really important, I can drop that.

> Should restore PF_MEMALLOC here.

Right...

> > +		set_task_state(current, TASK_INTERRUPTIBLE);
> > +		while (!(bio = kcryptd_get_bios())) {
> > +			schedule();
> > +			if (signal_pending(current))
> > +				return 0;
> > +		}
> 
> This will turn into a busy-loop, because schedule() sets current->state to
> TASK_RUNNING.  You need to move the set_task_state(current,
> TASK_INTERRUPTIBLE); inside the loop.

Right again. I changed that several times. It shouldn't happen that
schedule returns but there's not data available, but ok. I changed the
while to an if and call kcryptd_get_bios after schedule().

> Why is this code mucking with signals?

For thread termination, that's what kthread does. The other kthread
users are doing this too. I changed the for(;;) back to a while
(!signal_pending(current)) since I killed the inner while loop.

> Perhaps a call to blk_congestion_wait() would be appropriate here.

Huh? Why that? This is the path for reads.

> sprintf("%02x")?

Ok. :)

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb Andrew Morton um 02:53:

> > +	  This device-mapper target allows you to create a device that
> >  +	  transparently encrypts the data on it. You'll need to activate
> >  +	  the required ciphers in the cryptoapi configuration in order to
> >  +	  be able to use it.
> 
> Is there more documentation that this?  I'd imagine a lot of crypto-loop
> users wouldn't have a clue how to get started on dm-crypt, especially if
> they have not used device mapper before.

Yes, there is. I'm going to collect it and put something together.

> And how do they migrate existing encrypted filesytems?

The current on-disk-layout is compatible with cryptoloop. The IV
generation mechanism is flexible though and will be extended to allow
for a more secure IV generation (like using a hash algorithm).

At the moment it supports no IC (ECB mode) or plain IV (sector number
truncated to 32 bit as IV).

Re: dm-crypt using kthread

[Jeff Garzik]

Christophe Saout wrote:
> Am Mo, den 16.02.2004 schrieb Jeff Garzik um 03:10:
> 
> 
>>>+		/*
>>>+		 * if additional pages cannot be allocated without waiting,
>>>+		 * return a partially allocated bio, the caller will then try
>>>+		 * to allocate additional bios while submitting this partial bio
>>>+		 */
>>>+		if ((i - bio->bi_idx) == (MIN_BIO_PAGES - 1))
>>>+			gfp_mask = (gfp_mask | __GFP_NOWARN) & ~__GFP_WAIT;
>>
>>If the caller said they can wait, why not wait?
> 
> 
> How can the caller say this?

There is a gfp_mask there :)


>>>+		set_task_state(current, TASK_INTERRUPTIBLE);
>>>+		while (!(bio = kcryptd_get_bios())) {
>>>+			schedule();
>>>+			if (signal_pending(current))
>>>+				return 0;
>>>+		}
>>>+		set_task_state(current, TASK_RUNNING);
>>
>>You just keep calling schedule() rapid-fire until you get a bio?  That's 
>>a bit sub-optimal.
> 
> 
> That's wrong anyway. I was just making sure I was calling
> kcryptd_get_bios after schedule. schedule() will sleep and woken after
> someone added a bio to the list.
> 
> I've changed it to an if now and call kcryptd_get_bios after schedule.
> 
> I'm calling it twice because it is likely that someone started a new
> list while the old list is being processed and I don't want to sleep in
> this case, just fall through.
> 
> The kcryptd_get_bios needs to be after state = TASK_INTERRUPTIBLE to
> avoid a race. If someone wakes the process after kcryptd_get_bios but
> before schedule it resets the state to TASK_RUNNING so that the schedule
> won't sleep.

This sounds like a lot of work, just to reimplement what a semaphore 
does for you :)

When you down(), you sleep, waiting for new work.  Each time new work 
occurs, on any cpu, you call up().  This is perfect for a kernel thread, 
which can sleep, just like a semaphore needs.  If you want to be 
interruptible by signals (such as sysadmin killing your thread, for some 
reason), then use down_interruptible().

There is typically one special case -- killing your thread on shutdown. 
  The typical solution is to set a flag thread_shutdown, and then up().

	Jeff

Re: kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Rusty Russell]

In message <1076876668.21968.22.camel@leto.cs.pocnet.net> you write:
> Am So, den 15.02.2004 schrieb Christoph Hellwig um 20:46:
> 
> > > The only reason, I guess, is that it depends on this very small
> > > dm-daemon thing:
> > > http://people.sistina.com/~thornber/dm/patches/2.6-unstable/2.6.2/2.6.2-u
dm1/00016.patch
> >
> > Well, actually the above code should not enter the kernel tree at all.
> > Care to rewrite dm-crypt to use Rusty's kthread code in -mm instead and
> > submit a patch to Andrew?  Whenever he merges the kthread stuff to mainline
> > he could just include dm-crypt then.
> 
> Sure I could.
> 
> But kthread is currently not a full replacement for dm-daemon. kthread
> provides thread creation and destruction functions. But dm-daemon
> additionaly does mainloop handling.

Yes, looks like dm-daemon is a workqueue.

> There seems to beg a small race conditition that can appear when using
> only wake_up for notifies so dm-daemon uses an additional atomic_t
> variable to make sure nothing gets missed. Just see the function
> ``daemon'' in dm-daemon.c.

This is why using a workqueue, rather than having everyone invent
their own methods, is a good idea.

> It seems to me that this functionality could perhaps be somehow added to
> kthread without changing it too much... ?

You could build it on top of kthread probably.  You could also change
workqueues to resize dynamically, rather than be one per cpu (but
that's some fairly tricky code).

Thanks for bringing this code to my attention...
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb Grzegorz Kulewski um 03:07:

> > Is there more documentation that this?  I'd imagine a lot of crypto-loop
> > users wouldn't have a clue how to get started on dm-crypt, especially if
> > they have not used device mapper before.
> > 
> > And how do they migrate existing encrypted filesytems?
> 
> And is the format considered "stable"?
> (= if I will create fs on it, will I have problems with future kernels?)

Yes. The cryptoloop compatible format will stay this way. The format
(basically the cipher used and the iv generation mode) can be specified.

I posted a small description some time ago:

http://marc.theaimsgroup.com/?l=linux-kernel&m=105967481007242&w=2

The -cbc was renamed to -plain in order to make more iv generation
methods possible which of course also use the CBC mode.

Re: dm-crypt using kthread

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb Jeff Garzik um 03:58:

> >>>+		if ((i - bio->bi_idx) == (MIN_BIO_PAGES - 1))
> >>>+			gfp_mask = (gfp_mask | __GFP_NOWARN) & ~__GFP_WAIT;
> >>
> >>If the caller said they can wait, why not wait?
> > 
> > How can the caller say this?
> 
> There is a gfp_mask there :)

I still don't get it. :(
The caller is the crypt_map function which is called by dm which is
called by generic_make_request. There are no gfp_masks there.

> This sounds like a lot of work, just to reimplement what a semaphore 
> does for you :)

It sounds more complicated than it is...

In my very first version I used semaphores. I'm turning in circles. ;)

> There is typically one special case -- killing your thread on shutdown. 
>   The typical solution is to set a flag thread_shutdown, and then up().

I'm using the kthread primitives, kthread_stop kills the thread using a
signal.

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Grzegorz Kulewski]

Thanks for your fast response!

On Mon, 16 Feb 2004, Christophe Saout wrote:

> Am Mo, den 16.02.2004 schrieb Grzegorz Kulewski um 03:07:
> 
> > > Is there more documentation that this?  I'd imagine a lot of crypto-loop
> > > users wouldn't have a clue how to get started on dm-crypt, especially if
> > > they have not used device mapper before.
> > > 
> > > And how do they migrate existing encrypted filesytems?
> > 
> > And is the format considered "stable"?
> > (= if I will create fs on it, will I have problems with future kernels?)
> 
> Yes. The cryptoloop compatible format will stay this way. The format
> (basically the cipher used and the iv generation mode) can be specified.
> 
> I posted a small description some time ago:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=105967481007242&w=2
> 
> The -cbc was renamed to -plain in order to make more iv generation
> methods possible which of course also use the CBC mode.

Did you heard / read about Herring?
I found .pdf somewhere (I think I still have it). It is better alternative 
to ECB or CBC algorithms used in cryptoloop (if I understand good). Could 
something like that be implemented in dm-crypt? Is it already?

Could somebody write dm-compress (compressing not encrypting)? Is it 
technically possible (can device mapper handle different data size at 
input, differet at output)? (I think there is compressing loop patch.)
Could dm first compress data (even with weak algorithm), then encrypt, to 
make statistical analysis harder?

And, to be sure, does dm-crypto add anything in the begining (ie. 
header) or in other places to the stored data? Or it is the same data 
(same size) but encrypted?  


Grzegorz Kulewski

Re: dm-crypt using kthread

[Jeff Garzik]

Grzegorz Kulewski wrote:
> Could somebody write dm-compress (compressing not encrypting)? Is it 
> technically possible (can device mapper handle different data size at 
> input, differet at output)? (I think there is compressing loop patch.)
> Could dm first compress data (even with weak algorithm), then encrypt, to 
> make statistical analysis harder?


It's certainly possible, but you have to consider that data transfer 
almost always should be considered in page-sized chunks.  For compress 
that would imply you would need to allocate/free blocks and similar 
duties that a filesystem must perform, simply because you do not have 
one-to-one correspondence with blocks being passed to you.

You also have to consider that the kernel may request one or more pages 
that are in the middle of a compressed run of pages.  For example, 
consider an algorithm that compresses 16 pages into a run of 4 pages. 
Later on, when the kernel requests (uncompressed) page 9, you likely 
need to read all 4 pages, and allocate 16 more pages for decompression. 
  So, reading 1 upper layer page required dm-compress tying up 20 pages.

	Jeff

Re: dm-crypt using kthread

[Grzegorz Kulewski]

On Sun, 15 Feb 2004, Jeff Garzik wrote:

> Grzegorz Kulewski wrote:
> > Could somebody write dm-compress (compressing not encrypting)? Is it 
> > technically possible (can device mapper handle different data size at 
> > input, differet at output)? (I think there is compressing loop patch.)
> > Could dm first compress data (even with weak algorithm), then encrypt, to 
> > make statistical analysis harder?
> 
> 
> It's certainly possible, but you have to consider that data transfer 
> almost always should be considered in page-sized chunks.  For compress 
> that would imply you would need to allocate/free blocks and similar 
> duties that a filesystem must perform, simply because you do not have 
> one-to-one correspondence with blocks being passed to you.
> 
> You also have to consider that the kernel may request one or more pages 
> that are in the middle of a compressed run of pages.  For example, 
> consider an algorithm that compresses 16 pages into a run of 4 pages. 
> Later on, when the kernel requests (uncompressed) page 9, you likely 
> need to read all 4 pages, and allocate 16 more pages for decompression. 
>   So, reading 1 upper layer page required dm-compress tying up 20 pages.
> 

Yes, I understand that (at least I think so...). But Knopix (and probably 
other distros) use 2.4 with compressing loop patch, and I think somebody 
at Gentoo is trying to port that patch to 2.6 for Gentoo's LiveCD... So it 
was done somehow... (I do not know how, however.)


Grzegorz Kulewski

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[David Wagner]

Christophe Saout  wrote:
>At the moment it supports no IC (ECB mode) or [...]

Probably I'm misunderstanding something, but: Do you really mean that
you are using ECB mode?  How is that secure?  (Everyone knows why ECB
mode should almost never be used, right?)

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb Grzegorz Kulewski um 04:22:

> Did you heard / read about Herring?

No, what is it?

> I found .pdf somewhere (I think I still have it). It is better alternative 
> to ECB or CBC algorithms used in cryptoloop (if I understand good). Could 
> something like that be implemented in dm-crypt? Is it already?

I can do whatever cryptoapi offers (and isn't too complicated).

> Could somebody write dm-compress (compressing not encrypting)? Is it 
> technically possible (can device mapper handle different data size at 
> input, differet at output)? (I think there is compressing loop patch.)
> Could dm first compress data (even with weak algorithm), then encrypt, to 
> make statistical analysis harder?

Compression is something that is fine in the loop driver but when done
read-only (because it can be backed by something that isn't limited to
do I/O on sector boundaries) but very hard to do in the block layer,
especially read-write. It should really be done in a filesystem because
you have to do dynamic allocation and such things and you can't even
guarantee a certain disk size.

> And, to be sure, does dm-crypto add anything in the begining (ie. 
> header) or in other places to the stored data? Or it is the same data 
> (same size) but encrypted?  

No, it doesn't do anything. These things should be done entirely in
userspace.

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb David Wagner um 08:28:

> Probably I'm misunderstanding something, but: Do you really mean that
> you are using ECB mode?  How is that secure?  (Everyone knows why ECB
> mode should almost never be used, right?)

Yes, it is how it sounds. It's only used if explicitly specified
assuming the user knows what he's doing. It's mainly for backwards
compatibility because cryptoloop can do the same (but it isn't used by
default either).

Re: dm-crypt using kthread

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb Grzegorz Kulewski um 05:14:

> Yes, I understand that (at least I think so...). But Knopix (and probably 
> other distros) use 2.4 with compressing loop patch, and I think somebody 
> at Gentoo is trying to port that patch to 2.6 for Gentoo's LiveCD... So it 
> was done somehow... (I do not know how, however.)

compressed loop is read-only. The filesystem is created on a normal
device, then encrypted into a big file with a static index.

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jan Rychter]

[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]

>>>>> "Jari" == Jari Ruusu <jariruusu@users.sourceforge.net>:
 Jari> Jan Rychter wrote:
 >> FWIW, I've just tried loop-AES with 2.4.24, after using cryptoapi
 >> for a number of years. My machine froze dead in the midst of copying
 >> 2.8GB of data onto my file-backed reiserfs encrypted loopback mount.
 >>
 >> Since the system didn't ever freeze on me before and since I've had
 >> zero problems with cryptoapi, I attribute the freeze to loop-AES.
 >>
 >> Yes, I know this isn't a good bugreport...

 Jari> Is there any particular reason why you insist on using file
 Jari> backed loops?

Yes. They are much easier to use from a practical standpoint. They do
not require repartitioning of your drives. They are easy to back up
using rsync. They are reasonably easy to resize (by creating another
file-backed loop side by side and copying the data).

Probably the biggest reason is that repartitioning laptop drives is a
difficult task. You can't just connect a second drive to a laptop, so
when you have a laptop that's full of data, there is no easy way to
repartition.

All in all, it's not a strict requirement, it's a convenience thing,
especially for those of us who do not sit in front of huge desktops,
where you can easily add and replace drives.

 Jari> File backed loops have hard to fix re-entry problem: GFP_NOFS
 Jari> memory allocations that cause dirty pages to written out to file
 Jari> backed loop, will have to re-enter the file system anyway to
 Jari> complete the write. This causes deadlocks. Same deadlocks are
 Jari> there in mainline loop+cryptoloop combo.

I have used cryptoapi (as modules) for the last 2 years (or so) now,
without encountering any problems whatsoever. I therefore beg to differ:
if the same deadlocks are there, then for some reason they are not
triggered on my machine. Two years versus an hour, that's a rather
significant difference in terms of reliability.

 Jari> This is one of the reasons why this is in loop-AES README: "If
 Jari> you can choose between device backed and file backed, choose
 Jari> device backed even if it means that you have to re-partition your
 Jari> disks."

I would humbly suggest that this annotation be made more explicit. Had
it said "DO NOT use file backed loop devices, as these do not work and
cause deadlocks", I would have never even tried loop-AES. As it stands,
I did, and it took about an hour to get a deadlock.

--J.  
PS: just as a clarification: my setup consists of reiserfs on top of an
encrypted file-backed loop device, the file sits on an ext3 fs mounted
with data=ordered.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: dm-crypt using kthread

[Christophe Saout]

On Sun, Feb 15, 2004 at 09:58:39PM -0500, Jeff Garzik wrote:

> This sounds like a lot of work, just to reimplement what a semaphore 
> does for you :)

I've fixed the small bugs you guys found and tried some more alternatives.
I've got three versions now:

- kthread and set_current_state/schedule/wake_up_process
- kthread and semaphores
- workqueue

The version using a workqueue is the shortest of all:

diff -Nur linux-2.6.3-rc3-mm1.orig/drivers/md/dm-crypt.c linux-2.6.3-rc3-mm1/drivers/md/dm-crypt.c
--- linux-2.6.3-rc3-mm1.orig/drivers/md/dm-crypt.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.3-rc3-mm1/drivers/md/dm-crypt.c	2004-02-16 01:47:37.000000000 +0100
@@ -0,0 +1,776 @@
+/*
+ * Copyright (C) 2003 Christophe Saout <christophe@saout.de>
+ *
+ * This file is released under the GPL.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/bio.h>
+#include <linux/mempool.h>
+#include <linux/slab.h>
+#include <linux/crypto.h>
+#include <linux/spinlock.h>
+#include <linux/workqueue.h>
+#include <asm/scatterlist.h>
+
+#include "dm.h"
+
+/*
+ * per bio private data
+ */
+struct crypt_io {
+	struct dm_target *target;
+	struct bio *bio;
+	struct bio *first_clone;
+	struct work_struct work;
+	atomic_t pending;
+	int error;
+};
+
+/*
+ * context holding the current state of a multi-part conversion
+ */
+struct convert_context {
+	struct bio *bio_in;
+	struct bio *bio_out;
+	unsigned int offset_in;
+	unsigned int offset_out;
+	int idx_in;
+	int idx_out;
+	sector_t sector;
+	int write;
+};
+
+/*
+ * Crypt: maps a linear range of a block device
+ * and encrypts / decrypts at the same time.
+ */
+struct crypt_config {
+	struct dm_dev *dev;
+	sector_t start;
+
+	/*
+	 * pool for per bio private data and
+	 * for encryption buffer pages
+	 */
+	mempool_t *io_pool;
+	mempool_t *page_pool;
+
+	/*
+	 * crypto related data
+	 */
+	struct crypto_tfm *tfm;
+	sector_t iv_offset;
+	int (*iv_generator)(struct crypt_config *cc, u8 *iv, sector_t sector);
+	int iv_size;
+	int key_size;
+	u8 key[0];
+};
+
+#define MIN_IOS        256
+#define MIN_POOL_PAGES 32
+#define MIN_BIO_PAGES  8
+
+static kmem_cache_t *_crypt_io_pool;
+
+/*
+ * Mempool alloc and free functions for the page
+ */
+static void *mempool_alloc_page(int gfp_mask, void *data)
+{
+	return alloc_page(gfp_mask);
+}
+
+static void mempool_free_page(void *page, void *data)
+{
+	__free_page(page);
+}
+
+
+/*
+ * Different IV generation algorithms
+ */
+static int crypt_iv_plain(struct crypt_config *cc, u8 *iv, sector_t sector)
+{
+	*(u32 *)iv = cpu_to_le32(sector & 0xffffffff);
+	if (cc->iv_size > sizeof(u32) / sizeof(u8))
+		memset(iv + (sizeof(u32) / sizeof(u8)), 0,
+		       cc->iv_size - (sizeof(u32) / sizeof(u8)));
+
+	return 0;
+}
+
+static inline int
+crypt_convert_scatterlist(struct crypt_config *cc, struct scatterlist *out,
+                          struct scatterlist *in, unsigned int length,
+                          int write, sector_t sector)
+{
+	u8 iv[cc->iv_size];
+	int r;
+
+	if (cc->iv_generator) {
+		r = cc->iv_generator(cc, iv, sector);
+		if (r < 0)
+			return r;
+
+		if (write)
+			r = crypto_cipher_encrypt_iv(cc->tfm, out, in, length, iv);
+		else
+			r = crypto_cipher_decrypt_iv(cc->tfm, out, in, length, iv);
+	} else {
+		if (write)
+			r = crypto_cipher_encrypt(cc->tfm, out, in, length);
+		else
+			r = crypto_cipher_decrypt(cc->tfm, out, in, length);
+	}
+
+	return r;
+}
+
+static void
+crypt_convert_init(struct crypt_config *cc, struct convert_context *ctx,
+                   struct bio *bio_out, struct bio *bio_in,
+                   sector_t sector, int write)
+{
+	ctx->bio_in = bio_in;
+	ctx->bio_out = bio_out;
+	ctx->offset_in = 0;
+	ctx->offset_out = 0;
+	ctx->idx_in = bio_in ? bio_in->bi_idx : 0;
+	ctx->idx_out = bio_out ? bio_out->bi_idx : 0;
+	ctx->sector = sector + cc->iv_offset;
+	ctx->write = write;
+}
+
+/*
+ * Encrypt / decrypt data from one bio to another one (can be the same one)
+ */
+static int crypt_convert(struct crypt_config *cc,
+                         struct convert_context *ctx)
+{
+	int r = 0;
+
+	while(ctx->idx_in < ctx->bio_in->bi_vcnt &&
+	      ctx->idx_out < ctx->bio_out->bi_vcnt) {
+		struct bio_vec *bv_in = bio_iovec_idx(ctx->bio_in, ctx->idx_in);
+		struct bio_vec *bv_out = bio_iovec_idx(ctx->bio_out, ctx->idx_out);
+		struct scatterlist sg_in = {
+			.page = bv_in->bv_page,
+			.offset = bv_in->bv_offset + ctx->offset_in,
+			.length = 1 << SECTOR_SHIFT
+		};
+		struct scatterlist sg_out = {
+			.page = bv_out->bv_page,
+			.offset = bv_out->bv_offset + ctx->offset_out,
+			.length = 1 << SECTOR_SHIFT
+		};
+
+		ctx->offset_in += sg_in.length;
+		if (ctx->offset_in >= bv_in->bv_len) {
+			ctx->offset_in = 0;
+			ctx->idx_in++;
+		}
+
+		ctx->offset_out += sg_out.length;
+		if (ctx->offset_out >= bv_out->bv_len) {
+			ctx->offset_out = 0;
+			ctx->idx_out++;
+		}
+
+		r = crypt_convert_scatterlist(cc, &sg_out, &sg_in, sg_in.length,
+		                              ctx->write, ctx->sector);
+		if (r < 0)
+			break;
+
+		ctx->sector++;
+	}
+
+	return r;
+}
+
+/*
+ * Generate a new unfragmented bio with the given size
+ * This should never violate the device limitations
+ * May return a smaller bio when running out of pages
+ */
+static struct bio *
+crypt_alloc_buffer(struct crypt_config *cc, unsigned int size,
+                   struct bio *base_bio, int *bio_vec_idx)
+{
+	struct bio *bio;
+	int nr_iovecs = dm_div_up(size, PAGE_SIZE);
+	int gfp_mask = GFP_NOIO | __GFP_HIGHMEM;
+	int flags = current->flags;
+	int i;
+
+	/*
+	 * Tell VM to act less aggressively and fail earlier.
+	 * This is not necessary but increases throughput.
+	 * FIXME: Is this really intelligent?
+	 */
+	current->flags &= ~PF_MEMALLOC;
+
+	if (base_bio)
+		bio = bio_clone(base_bio, GFP_NOIO);
+	else
+		bio = bio_alloc(GFP_NOIO, nr_iovecs);
+	if (!bio) {
+		if (flags & PF_MEMALLOC)
+			current->flags |= PF_MEMALLOC;
+		return NULL;
+	}
+
+	/* if the last bio was not complete, continue where that one ended */
+	bio->bi_idx = *bio_vec_idx;
+	bio->bi_vcnt = *bio_vec_idx;
+	bio->bi_size = 0;
+	bio->bi_flags &= ~(1 << BIO_SEG_VALID);
+
+	/* bio->bi_idx pages have already been allocated */
+	size -= bio->bi_idx * PAGE_SIZE;
+
+	for(i = bio->bi_idx; i < nr_iovecs; i++) {
+		struct bio_vec *bv = bio_iovec_idx(bio, i);
+
+		bv->bv_page = mempool_alloc(cc->page_pool, gfp_mask);
+		if (!bv->bv_page)
+			break;
+
+		/*
+		 * if additional pages cannot be allocated without waiting,
+		 * return a partially allocated bio, the caller will then try
+		 * to allocate additional bios while submitting this partial bio
+		 */
+		if ((i - bio->bi_idx) == (MIN_BIO_PAGES - 1))
+			gfp_mask = (gfp_mask | __GFP_NOWARN) & ~__GFP_WAIT;
+
+		bv->bv_offset = 0;
+		if (size > PAGE_SIZE)
+			bv->bv_len = PAGE_SIZE;
+		else
+			bv->bv_len = size;
+
+		bio->bi_size += bv->bv_len;
+		bio->bi_vcnt++;
+		size -= bv->bv_len;
+	}
+
+	if (flags & PF_MEMALLOC)
+		current->flags |= PF_MEMALLOC;
+
+	if (!bio->bi_size) {
+		bio_put(bio);
+		return NULL;
+	}
+
+	/*
+	 * Remember the last bio_vec allocated to be able
+	 * to correctly continue after the splitting.
+	 */
+	*bio_vec_idx = bio->bi_vcnt;
+
+	return bio;
+}
+
+static void crypt_free_buffer_pages(struct crypt_config *cc,
+                                    struct bio *bio, unsigned int bytes)
+{
+	unsigned int start, end;
+	struct bio_vec *bv;
+	int i;
+
+	/*
+	 * This is ugly, but Jens Axboe thinks that using bi_idx in the
+	 * endio function is too dangerous at the moment, so I calculate the
+	 * correct position using bi_vcnt and bi_size.
+	 * The bv_offset and bv_len fields might already be modified but we
+	 * know that we always allocated whole pages.
+	 * A fix to the bi_idx issue in the kernel is in the works, so
+	 * we will hopefully be able to revert to the cleaner solution soon.
+	 */
+	i = bio->bi_vcnt - 1;
+	bv = bio_iovec_idx(bio, i);
+	end = (i << PAGE_SHIFT) + (bv->bv_offset + bv->bv_len) - bio->bi_size;
+	start = end - bytes;
+
+	start >>= PAGE_SHIFT;
+	if (!bio->bi_size)
+		end = bio->bi_vcnt;
+	else
+		end >>= PAGE_SHIFT;
+
+	for(i = start; i < end; i++) {
+		bv = bio_iovec_idx(bio, i);
+		BUG_ON(!bv->bv_page);
+		mempool_free(bv->bv_page, cc->page_pool);
+		bv->bv_page = NULL;
+	}
+}
+
+/*
+ * One of the bios was finished. Check for completion of
+ * the whole request and correctly clean up the buffer.
+ */
+static void dec_pending(struct crypt_io *io, int error)
+{
+	struct crypt_config *cc = (struct crypt_config *) io->target->private;
+
+	if (error < 0)
+		io->error = error;
+
+	if (!atomic_dec_and_test(&io->pending))
+		return;
+
+	if (io->first_clone)
+		bio_put(io->first_clone);
+
+	bio_endio(io->bio, io->bio->bi_size, io->error);
+
+	mempool_free(io, cc->io_pool);
+}
+
+/*
+ * kcryptd:
+ *
+ * Needed because it would be very unwise to do decryption in an
+ * interrupt context, so bios returning from read requests get
+ * queued here.
+ */
+static struct workqueue_struct *_kcryptd_workqueue;
+
+static void kcryptd_do_work(void *data)
+{
+	struct crypt_io *io = (struct crypt_io *) data;
+	struct crypt_config *cc = (struct crypt_config *) io->target->private;
+	struct convert_context ctx;
+	int r;
+
+	crypt_convert_init(cc, &ctx, io->bio, io->bio,
+	                   io->bio->bi_sector - io->target->begin, 0);
+	r = crypt_convert(cc, &ctx);
+
+	dec_pending(io, r);
+}
+
+static void kcryptd_queue_io(struct crypt_io *io)
+{
+	/* with the work struct in crypt_io we can only queue whole io's */
+	BUG_ON(atomic_read(&io->pending) != 1);
+
+	INIT_WORK(&io->work, kcryptd_do_work, io);
+	queue_work(_kcryptd_workqueue, &io->work);
+}
+
+/*
+ * Decode key from its hex representation
+ */
+static int crypt_decode_key(u8 *key, char *hex, int size)
+{
+	char buffer[3];
+	char *endp;
+	int i;
+
+	buffer[2] = '\0';
+
+	for(i = 0; i < size; i++) {
+		buffer[0] = *hex++;
+		buffer[1] = *hex++;
+
+		key[i] = (u8)simple_strtoul(buffer, &endp, 16);
+
+		if (endp != &buffer[2])
+			return -EINVAL;
+	}
+
+	if (*hex != '\0')
+		return -EINVAL;
+
+	return 0;
+}
+
+/*
+ * Encode key into its hex representation
+ */
+static void crypt_encode_key(char *hex, u8 *key, int size)
+{
+	int i;
+
+	for(i = 0; i < size; i++) {
+		sprintf(hex, "%02x", *key);
+		hex += 2;
+		key++;
+	}
+}
+
+/*
+ * Construct an encryption mapping:
+ * <cipher> <key> <iv_offset> <dev_path> <start>
+ */
+static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
+{
+	struct crypt_config *cc;
+	struct crypto_tfm *tfm;
+	char *tmp;
+	char *cipher;
+	char *mode;
+	int crypto_flags;
+	int key_size;
+
+	if (argc != 5) {
+		ti->error = "dm-crypt: Not enough arguments";
+		return -EINVAL;
+	}
+
+	tmp = argv[0];
+	cipher = strsep(&tmp, "-");
+	mode = strsep(&tmp, "-");
+
+	if (tmp)
+		DMWARN("dm-crypt: Unexpected additional cipher options");
+
+	key_size = strlen(argv[1]) >> 1;
+
+	cc = kmalloc(sizeof(*cc) + key_size * sizeof(u8), GFP_KERNEL);
+	if (cc == NULL) {
+		ti->error =
+			"dm-crypt: Cannot allocate transparent encryption context";
+		return -ENOMEM;
+	}
+
+	if (!mode || strcmp(mode, "plain") == 0)
+		cc->iv_generator = crypt_iv_plain;
+	else if (strcmp(mode, "ecb") == 0)
+		cc->iv_generator = NULL;
+	else {
+		ti->error = "dm-crypt: Invalid chaining mode";
+		goto bad1;
+	}
+
+	if (cc->iv_generator)
+		crypto_flags = CRYPTO_TFM_MODE_CBC;
+	else
+		crypto_flags = CRYPTO_TFM_MODE_ECB;
+
+	tfm = crypto_alloc_tfm(cipher, crypto_flags);
+	if (!tfm) {
+		ti->error = "dm-crypt: Error allocating crypto tfm";
+		goto bad1;
+	}
+
+	if (tfm->crt_u.cipher.cit_decrypt_iv && tfm->crt_u.cipher.cit_encrypt_iv)
+		/* at least a 32 bit sector number should fit in our buffer */
+		cc->iv_size = max(crypto_tfm_alg_ivsize(tfm), 
+		                  (unsigned int)(sizeof(u32) / sizeof(u8)));
+	else {
+		cc->iv_size = 0;
+		if (cc->iv_generator) {
+			DMWARN("dm-crypt: Selected cipher does not support IVs");
+			cc->iv_generator = NULL;
+		}
+	}
+
+	cc->io_pool = mempool_create(MIN_IOS, mempool_alloc_slab,
+				     mempool_free_slab, _crypt_io_pool);
+	if (!cc->io_pool) {
+		ti->error = "dm-crypt: Cannot allocate crypt io mempool";
+		goto bad2;
+	}
+
+	cc->page_pool = mempool_create(MIN_POOL_PAGES, mempool_alloc_page,
+				       mempool_free_page, NULL);
+	if (!cc->page_pool) {
+		ti->error = "dm-crypt: Cannot allocate page mempool";
+		goto bad3;
+	}
+
+	cc->tfm = tfm;
+	cc->key_size = key_size;
+	if ((key_size == 0 && strcmp(argv[1], "-") != 0)
+	    || crypt_decode_key(cc->key, argv[1], key_size) < 0) {
+		ti->error = "dm-crypt: Error decoding key";
+		goto bad4;
+	}
+
+	if (tfm->crt_u.cipher.cit_setkey(tfm, cc->key, key_size) < 0) {
+		ti->error = "dm-crypt: Error setting key";
+		goto bad4;
+	}
+
+	if (sscanf(argv[2], SECTOR_FORMAT, &cc->iv_offset) != 1) {
+		ti->error = "dm-crypt: Invalid iv_offset sector";
+		goto bad4;
+	}
+
+	if (sscanf(argv[4], SECTOR_FORMAT, &cc->start) != 1) {
+		ti->error = "dm-crypt: Invalid device sector";
+		goto bad4;
+	}
+
+	if (dm_get_device(ti, argv[3], cc->start, ti->len,
+	                  dm_table_get_mode(ti->table), &cc->dev)) {
+		ti->error = "dm-crypt: Device lookup failed";
+		goto bad4;
+	}
+
+	ti->private = cc;
+	return 0;
+
+bad4:
+	mempool_destroy(cc->page_pool);
+bad3:
+	mempool_destroy(cc->io_pool);
+bad2:
+	crypto_free_tfm(tfm);
+bad1:
+	kfree(cc);
+	return -EINVAL;
+}
+
+static void crypt_dtr(struct dm_target *ti)
+{
+	struct crypt_config *cc = (struct crypt_config *) ti->private;
+
+	mempool_destroy(cc->page_pool);
+	mempool_destroy(cc->io_pool);
+
+	crypto_free_tfm(cc->tfm);
+	dm_put_device(ti, cc->dev);
+	kfree(cc);
+}
+
+static int crypt_endio(struct bio *bio, unsigned int done, int error)
+{
+	struct crypt_io *io = (struct crypt_io *) bio->bi_private;
+	struct crypt_config *cc = (struct crypt_config *) io->target->private;
+
+	if (bio_rw(bio) == WRITE) {
+		/*
+		 * free the processed pages, even if
+		 * it's only a partially completed write
+		 */
+		crypt_free_buffer_pages(cc, bio, done);
+	}
+
+	if (bio->bi_size)
+		return 1;
+
+	bio_put(bio);
+
+	/*
+	 * successful reads are decrypted by the worker thread
+	 */
+	if ((bio_rw(bio) == READ || bio_rw(bio) == READA)
+	    && bio_flagged(bio, BIO_UPTODATE)) {
+		kcryptd_queue_io(io);
+		return 0;
+	}
+
+	dec_pending(io, error);
+	return error;
+}
+
+static inline struct bio *
+crypt_clone(struct crypt_config *cc, struct crypt_io *io, struct bio *bio,
+            sector_t sector, int *bvec_idx, struct convert_context *ctx)
+{
+	struct bio *clone;
+
+	if (bio_rw(bio) == WRITE) {
+		clone = crypt_alloc_buffer(cc, bio->bi_size,
+                                 io->first_clone, bvec_idx);
+		if (clone) {
+			ctx->bio_out = clone;
+			if (crypt_convert(cc, ctx) < 0) {
+				crypt_free_buffer_pages(cc, clone,
+				                        clone->bi_size);
+				bio_put(clone);
+				return NULL;
+			}
+		}
+	} else
+		clone = bio_clone(bio, GFP_NOIO);
+
+	if (!clone)
+		return NULL;
+
+	clone->bi_private = io;
+	clone->bi_end_io = crypt_endio;
+	clone->bi_bdev = cc->dev->bdev;
+	clone->bi_sector = cc->start + sector;
+	clone->bi_rw = bio->bi_rw;
+
+	return clone;
+}
+
+static int crypt_map(struct dm_target *ti, struct bio *bio)
+{
+	struct crypt_config *cc = (struct crypt_config *) ti->private;
+	struct crypt_io *io = mempool_alloc(cc->io_pool, GFP_NOIO);
+	struct convert_context ctx;
+	struct bio *clone;
+	unsigned int remaining = bio->bi_size;
+	sector_t sector = bio->bi_sector - ti->begin;
+	int bvec_idx = 0;
+
+	io->target = ti;
+	io->bio = bio;
+	io->first_clone = NULL;
+	io->error = 0;
+	atomic_set(&io->pending, 1); /* hold a reference */
+
+	if (bio_rw(bio) == WRITE)
+		crypt_convert_init(cc, &ctx, NULL, bio, sector, 1);
+
+	/*
+	 * The allocated buffers can be smaller than the whole bio,
+	 * so repeat the whole process until all the data can be handled.
+	 */
+	while (remaining) {
+		clone = crypt_clone(cc, io, bio, sector, &bvec_idx, &ctx);
+		if (!clone)
+			goto cleanup;
+
+		if (!io->first_clone) {
+			/*
+			 * hold a reference to the first clone, because it
+			 * holds the bio_vec array and that can't be freed
+			 * before all other clones are released
+			 */
+			bio_get(clone);
+			io->first_clone = clone;
+		}
+		atomic_inc(&io->pending);
+
+		remaining -= clone->bi_size;
+		sector += bio_sectors(clone);
+
+		generic_make_request(clone);
+	}
+
+	/* drop reference, clones could have returned before we reach this */
+	dec_pending(io, 0);
+	return 0;
+
+cleanup:
+	if (io->first_clone) {
+		dec_pending(io, -ENOMEM);
+		return 0;
+	}
+
+	/* if no bio has been dispatched yet, we can directly return the error */
+	mempool_free(io, cc->io_pool);
+	return -ENOMEM;
+}
+
+static int crypt_status(struct dm_target *ti, status_type_t type,
+			char *result, unsigned int maxlen)
+{
+	struct crypt_config *cc = (struct crypt_config *) ti->private;
+	char buffer[32];
+	const char *cipher;
+	const char *mode = NULL;
+	int offset;
+
+	switch (type) {
+	case STATUSTYPE_INFO:
+		result[0] = '\0';
+		break;
+
+	case STATUSTYPE_TABLE:
+		cipher = crypto_tfm_alg_name(cc->tfm);
+
+		switch(cc->tfm->crt_u.cipher.cit_mode) {
+		case CRYPTO_TFM_MODE_CBC:
+			mode = "plain";
+			break;
+		case CRYPTO_TFM_MODE_ECB:
+			mode = "ecb";
+			break;
+		default:
+			BUG();
+		}
+
+		snprintf(result, maxlen, "%s-%s ", cipher, mode);
+		offset = strlen(result);
+
+		if (cc->key_size > 0) {
+			if ((maxlen - offset) < ((cc->key_size << 1) + 1))
+				return -ENOMEM;
+
+			crypt_encode_key(result + offset, cc->key, cc->key_size);
+			offset += cc->key_size << 1;
+		} else {
+			if (offset >= maxlen)
+				return -ENOMEM;
+			result[offset++] = '-';
+		}
+
+		format_dev_t(buffer, cc->dev->bdev->bd_dev);
+		snprintf(result + offset, maxlen - offset, " " SECTOR_FORMAT
+		         " %s " SECTOR_FORMAT, cc->iv_offset,
+		         buffer, cc->start);
+		break;
+	}
+	return 0;
+}
+
+static struct target_type crypt_target = {
+	.name   = "crypt",
+	.module = THIS_MODULE,
+	.ctr    = crypt_ctr,
+	.dtr    = crypt_dtr,
+	.map    = crypt_map,
+	.status = crypt_status,
+};
+
+static int __init dm_crypt_init(void)
+{
+	int r;
+
+	_crypt_io_pool = kmem_cache_create("dm-crypt_io",
+	                                   sizeof(struct crypt_io),
+	                                   0, 0, NULL, NULL);
+	if (!_crypt_io_pool)
+		return -ENOMEM;
+
+	_kcryptd_workqueue = create_workqueue("kcryptd");
+	if (!_kcryptd_workqueue) {
+		r = -ENOMEM;
+		DMERR("couldn't create kcryptd");
+		goto bad1;
+	}
+
+	r = dm_register_target(&crypt_target);
+	if (r < 0) {
+		DMERR("crypt: register failed %d", r);
+		goto bad2;
+	}
+
+	return 0;
+
+bad2:
+	destroy_workqueue(_kcryptd_workqueue);
+bad1:
+	kmem_cache_destroy(_crypt_io_pool);
+	return r;
+}
+
+static void __exit dm_crypt_exit(void)
+{
+	int r = dm_unregister_target(&crypt_target);
+
+	if (r < 0)
+		DMERR("crypt: unregister failed %d", r);
+
+	destroy_workqueue(_kcryptd_workqueue);
+	kmem_cache_destroy(_crypt_io_pool);
+}
+
+module_init(dm_crypt_init);
+module_exit(dm_crypt_exit);
+
+MODULE_AUTHOR("Christophe Saout <christophe@saout.de>");
+MODULE_DESCRIPTION(DM_NAME " target for transparent encryption / decryption");
+MODULE_LICENSE("GPL");
diff -Nur linux-2.6.3-rc3-mm1.orig/drivers/md/Kconfig linux-2.6.3-rc3-mm1/drivers/md/Kconfig
--- linux-2.6.3-rc3-mm1.orig/drivers/md/Kconfig	2004-02-10 18:06:13.000000000 +0100
+++ linux-2.6.3-rc3-mm1/drivers/md/Kconfig	2004-02-16 01:30:51.000000000 +0100
@@ -170,5 +170,17 @@
 	  Recent tools use a new version of the ioctl interface, only
           select this option if you intend using such tools.
 
+config DM_CRYPT
+	tristate "Crypt target support"
+	depends on BLK_DEV_DM && EXPERIMENTAL
+	select CRYPTO
+	---help---
+	  This device-mapper target allows you to create a device that
+	  transparently encrypts the data on it. You'll need to activate
+	  the required ciphers in the cryptoapi configuration in order to
+	  be able to use it.
+
+	  If unsure, say N.
+
 endmenu
 
diff -Nur linux-2.6.3-rc3-mm1.orig/drivers/md/Makefile linux-2.6.3-rc3-mm1/drivers/md/Makefile
--- linux-2.6.3-rc3-mm1.orig/drivers/md/Makefile	2004-02-16 01:24:17.000000000 +0100
+++ linux-2.6.3-rc3-mm1/drivers/md/Makefile	2004-02-16 01:30:51.000000000 +0100
@@ -23,6 +23,7 @@
 obj-$(CONFIG_MD_MULTIPATH)	+= multipath.o
 obj-$(CONFIG_BLK_DEV_MD)	+= md.o
 obj-$(CONFIG_BLK_DEV_DM)	+= dm-mod.o
+obj-$(CONFIG_DM_CRYPT)		+= dm-crypt.o
 
 quiet_cmd_unroll = UNROLL  $@
       cmd_unroll = $(PERL) $(srctree)/$(src)/unroll.pl $(UNROLL) \

Re: kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb Rusty Russell um 04:02:

> Yes, looks like dm-daemon is a workqueue.

The only small difference is that you don't need a work_struct and the
work function is only called once, if there is work. The work function
has process all the work that has been queued.

> > There seems to beg a small race conditition that can appear when using
> > only wake_up for notifies so dm-daemon uses an additional atomic_t
> > variable to make sure nothing gets missed. Just see the function
> > ``daemon'' in dm-daemon.c.
> 
> This is why using a workqueue, rather than having everyone invent
> their own methods, is a good idea.

The only downside on using a workqueue here is that you have to put the
work_struct somewhere. If you have just bio structures floating around
this means you need an additional mempool, etc... In my case I already
had a structure that I could use (I was using bio->bi_next
concatenation), it just means that I can't do per-clone-queueing only
per-original-bio-queueing but in my case this doesn't make a difference.

> > It seems to me that this functionality could perhaps be somehow added to
> > kthread without changing it too much... ?
> 
> You could build it on top of kthread probably.

dm-daemon? That would make it a really stupid 10-line-wrapper.

I moved my dm-crypt target from dm-daemon to kthread and used
set_current_state/schedule/wakeup_process and the
bio->bi_next-concatenation. Fine.

Switching to kthread+semaphores and removing only a single bio from the
queue at a time made the code simpler (but adds a very small overhead
because of the spinlock every time a bio gets popped).

And finally a workqueue instead of kthread made the code even more
simple.

> You could also change
> workqueues to resize dynamically, rather than be one per cpu (but
> that's some fairly tricky code).

I think that's overkill. The threads don't waste too much resources. And
things would get complicated if you want to make the work function run
on the same cpu but don't have enough threads for this. You would have
to always change the affinity...?

Another question:

The workqueue code currently always executes the work function on the
same cpu. Would it be a good idea to add the possibility to make it run
on the next free cpu?

Assuming dm-crypt gets a lot of reads returned and has to decrypt them.
Decrypting the buffers on all CPUs in parallel would probably be faster.
This was done in order to avoid cache trashing?

Re: kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Joe Thornber]

On Mon, Feb 16, 2004 at 02:02:04PM +1100, Rusty Russell wrote:
> Yes, looks like dm-daemon is a workqueue.

Agreed.  I think (hope) we can get rid of dm-daemon entirely.

- Joe

Re: kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout]

Am Mo, den 16.02.2004 schrieb Christophe Saout um 14:27:

> > Yes, looks like dm-daemon is a workqueue.
> 
> The only small difference is that you don't need a work_struct and the
> work function is only called once, if there is work. The work function
> has process all the work that has been queued.

Forget that. I'm justing seeing that you can do this when using a
work_struct as notifier. Cool. :)

Re: dm-crypt using kthread

[Jeff Garzik]

Christophe Saout wrote:
> +static void kcryptd_do_work(void *data)
> +{
> +	struct crypt_io *io = (struct crypt_io *) data;
> +	struct crypt_config *cc = (struct crypt_config *) io->target->private;
> +	struct convert_context ctx;
> +	int r;
> +
> +	crypt_convert_init(cc, &ctx, io->bio, io->bio,
> +	                   io->bio->bi_sector - io->target->begin, 0);
> +	r = crypt_convert(cc, &ctx);
> +
> +	dec_pending(io, r);
> +}


> +static void kcryptd_queue_io(struct crypt_io *io)
> +{
> +	/* with the work struct in crypt_io we can only queue whole io's */
> +	BUG_ON(atomic_read(&io->pending) != 1);
> +
> +	INIT_WORK(&io->work, kcryptd_do_work, io);
> +	queue_work(_kcryptd_workqueue, &io->work);
> +}

Yum, nice and small.

Me likee.



> +/*
> + * Construct an encryption mapping:
> + * <cipher> <key> <iv_offset> <dev_path> <start>
> + */
> +static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
> +{
> +	struct crypt_config *cc;
> +	struct crypto_tfm *tfm;
> +	char *tmp;
> +	char *cipher;
> +	char *mode;
> +	int crypto_flags;
> +	int key_size;
> +
> +	if (argc != 5) {
> +		ti->error = "dm-crypt: Not enough arguments";
> +		return -EINVAL;
> +	}
> +
> +	tmp = argv[0];
> +	cipher = strsep(&tmp, "-");
> +	mode = strsep(&tmp, "-");
> +
> +	if (tmp)
> +		DMWARN("dm-crypt: Unexpected additional cipher options");

Janitorial/cleanup:  I define a macro "PFX" in most of my drivers, which 
in this case would look like

#define MODNAME "dm-crypt"
#define PFX MODNAME ": "

This is IMO preferred over typing in the driver's name into bunches of 
strings.


Your code looks OK-to-merge to me, at this point.

	Jeff

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jari Ruusu]

Jan Rychter wrote:
> >>>>> "Jari" == Jari Ruusu <jariruusu@users.sourceforge.net>:
>  Jari> File backed loops have hard to fix re-entry problem: GFP_NOFS
>  Jari> memory allocations that cause dirty pages to written out to file
>  Jari> backed loop, will have to re-enter the file system anyway to
>  Jari> complete the write. This causes deadlocks. Same deadlocks are
>  Jari> there in mainline loop+cryptoloop combo.
> 
> I have used cryptoapi (as modules) for the last 2 years (or so) now,
> without encountering any problems whatsoever. I therefore beg to differ:
> if the same deadlocks are there, then for some reason they are not
> triggered on my machine. Two years versus an hour, that's a rather
> significant difference in terms of reliability.

Do you mind doing a a quick grep:

    cd /path/to/your/kernel/source
    grep "Jari Ruusu" drivers/block/loop.c

If you see my name there, your kerneli.org cryptoapi enabled kernel is
running same loop code I wrote years ago. Those loop-jari-something patches
that you find on the net, are just copies of old loop-AES code.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jan Rychter]

[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]

>>>>> "Jari" == Jari Ruusu <jariruusu@users.sourceforge.net> writes:
 Jari> Jan Rychter wrote:
 > "Jari" == Jari Ruusu <jariruusu@users.sourceforge.net>:
 Jari> File backed loops have hard to fix re-entry problem: GFP_NOFS
 Jari> memory allocations that cause dirty pages to written out to file
 Jari> backed loop, will have to re-enter the file system anyway to
 Jari> complete the write. This causes deadlocks. Same deadlocks are
 Jari> there in mainline loop+cryptoloop combo.
 >>
 >> I have used cryptoapi (as modules) for the last 2 years (or so) now,
 >> without encountering any problems whatsoever. I therefore beg to
 >> differ: if the same deadlocks are there, then for some reason they
 >> are not triggered on my machine. Two years versus an hour, that's a
 >> rather significant difference in terms of reliability.

 Jari> Do you mind doing a a quick grep:

 Jari> cd /path/to/your/kernel/source grep "Jari Ruusu"
 Jari> drivers/block/loop.c

 Jari> If you see my name there, your kerneli.org cryptoapi enabled
 Jari> kernel is running same loop code I wrote years ago. Those
 Jari> loop-jari-something patches that you find on the net, are just
 Jari> copies of old loop-AES code.

No, it is not running this code. The code that works well for me is the
external cryptoapi (as modules) with last update in Feb 2002.

Ok, now after spending some more time googling around and reading
documentation, I'm confused. It also seems I'm not the only one (see
http://www.linuxquestions.org/questions/archive/4/2004/01/3/136754).

How do you get a file-backed encrypted filesystem to work under Linux
2.4.24?

From what I understand, there are three options:

  1) cryptoapi-as-modules, which is what I'm using now and what has
     worked reliably (although perhaps not too fast),
  2) in-kernel cryptoapi, which seems to be missing cryptoloop support,
     so how do you actually use it? And what about the i586-optimized
     AES patches?
  3) Jari Ruusu's loop-AES, which from what I understood won't work on
     file-backed loops because of deadlock issues.

Now, I would be all happy with option (1) which I have been using,
except I started caring about speed a little. Also, it bothers me a
little bit that the cryptoapi project seems to have died, as I wasn't
able to find any up-to-date pages or documents about it.

So, what is the preferred way?

--J.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jari Ruusu]

Jan Rychter wrote:
>  Jari> Do you mind doing a a quick grep:
> 
>  Jari> cd /path/to/your/kernel/source grep "Jari Ruusu"
>  Jari> drivers/block/loop.c
> 
>  Jari> If you see my name there, your kerneli.org cryptoapi enabled
>  Jari> kernel is running same loop code I wrote years ago. Those
>  Jari> loop-jari-something patches that you find on the net, are just
>  Jari> copies of old loop-AES code.
> 
> No, it is not running this code. The code that works well for me is the
> external cryptoapi (as modules) with last update in Feb 2002.

Then you are running loop that fails in few seconds using my tests.

> How do you get a file-backed encrypted filesystem to work under Linux
> 2.4.24?

Writable file backed loops received death sentence when GFP_NOFS was
introduced to kernel, and they have been on death row since then. The best
way is to set up partition backed loop using loop-AES. Mainline loop is
still prone to deadlock, both file backed and device backed.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Bill Davidsen]

James Morris wrote:
> On Sun, 15 Feb 2004, Jari Ruusu wrote:
> 
> 
>>Jan Rychter wrote:
>>
>>>FWIW, I've just tried loop-AES with 2.4.24, after using cryptoapi for a
>>>number of years. My machine froze dead in the midst of copying 2.8GB of
>>>data onto my file-backed reiserfs encrypted loopback mount.
>>>
>>>Since the system didn't ever freeze on me before and since I've had zero
>>>problems with cryptoapi, I attribute the freeze to loop-AES.
>>>
>>>Yes, I know this isn't a good bugreport...
>>
>>Is there any particular reason why you insist on using file backed loops?
>>
>>File backed loops have hard to fix re-entry problem: GFP_NOFS memory
>>allocations that cause dirty pages to written out to file backed loop, will
>>have to re-enter the file system anyway to complete the write. This causes
>>deadlocks. Same deadlocks are there in mainline loop+cryptoloop combo.
> 
> 
> Given the security issues, and the above problems, we should probably just
> remove cryptoloop from the kernel and wait for something with a better
> design.

I hope you're kidding... one of the reasons for going to 2.6 is that you 
no longer have to patch your kernel to get cryptoloop. That is a real 
issue in some organizations, which only allow vendor or kernel.org kernels.

If you start dropping features which work for most people but aren't 
perfect, you will wind up with a microkernel indeed.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: dm-crypt using kthread

[Bill Davidsen]

Andrew Morton wrote:
> Christophe Saout <christophe@saout.de> wrote:
> 
>>+	  This device-mapper target allows you to create a device that
>> +	  transparently encrypts the data on it. You'll need to activate
>> +	  the required ciphers in the cryptoapi configuration in order to
>> +	  be able to use it.
> 
> 
> Is there more documentation that this?  I'd imagine a lot of crypto-loop
> users wouldn't have a clue how to get started on dm-crypt, especially if
> they have not used device mapper before.
> 
> And how do they migrate existing encrypted filesytems?

And there are a reasonable number of us who build kernels without dm, 
lvm, and actually run working servers on them.

Having not had problems with either file or device backed cryptoloop I'm 
not eager to go do some new gee-whiz thing which require training time, 
new bugs to be fixed (unless you think this is more perfect than 
anything else in the kernel), etc.

Taking features out of a stable kernel, particularly those which work 
for many people, doesn't sound right, somehow. New features don't break 
existing setups, but removal of a feature seems to be more appropriate 
for 2.7. Of course by them it's likely that bugs will be removed and 
there will be no justification to remove it.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jan Rychter]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

>>>>> "Jari" == Jari Ruusu <jariruusu@users.sourceforge.net>:
 Jari> Jan Rychter wrote: Do you mind doing a a quick grep:
 >>
 Jari> cd /path/to/your/kernel/source grep "Jari Ruusu"
 Jari> drivers/block/loop.c
 >>
 Jari> If you see my name there, your kerneli.org cryptoapi enabled
 Jari> kernel is running same loop code I wrote years ago. Those
 Jari> loop-jari-something patches that you find on the net, are just
 Jari> copies of old loop-AES code.
 >>
 >> No, it is not running this code. The code that works well for me is
 >> the external cryptoapi (as modules) with last update in Feb 2002.

 Jari> Then you are running loop that fails in few seconds using my
 Jari> tests.

I guess I am just lucky, because that hasn't failed me in years. I think
I can live with that for now.

 >> How do you get a file-backed encrypted filesystem to work under
 >> Linux 2.4.24?

Looking at the (lack of) answers to my question, I gather there is no
clear-cut answer, or rather that the answer is "you don't".

 Jari> Writable file backed loops received death sentence when GFP_NOFS
 Jari> was introduced to kernel, and they have been on death row since
 Jari> then. The best way is to set up partition backed loop using
 Jari> loop-AES. Mainline loop is still prone to deadlock, both file
 Jari> backed and device backed.

Is everyone aware of these issues?

And, just wondering -- if loop-AES works so much better, why hasn't it
been included in the kernel?

--J.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Oopsing cryptoapi (or loop device?) on 2.6.*

[Jari Ruusu]

[-- Attachment #1: Type: text/plain, Size: 2903 bytes --]

Jan Rychter wrote:
> And, just wondering -- if loop-AES works so much better, why hasn't it
> been included in the kernel?

Because I stopped wasting my time with mainline kernels long time ago, and
because mainline folks seemed to prefer the most vulnerable loop crypto
implementation they could find (i.e. cryptoloop).

Just look at mainline folks merging another equally vulnerable and exploitable
implementation (i.e. dm-crypt), with exactly same vulnerabilities that
cryptoloop has, just in different package.

In loop-AES, "bad key management" issues were fixed years ago, and more
stronger IV was merged last year. Mainline folks still seem to be
puzzled/clueless with these issues.

-

Markku-Juhani O. Saarinen discovered watermark attack against cryptoloop,
here is his paper:

    http://www.tcs.hut.fi/~mjos/doc/diskenc.pdf

[just before posting I tested above link and it returns "You don't have
permission to access /~mjos/doc/diskenc.pdf on this server", ugh]

This attack exploits weakness in IV computation and knowledge of how file
systems place files on disk. This attack works with file systems that have
soft block size of 1024 or greater. At least ext2, ext3, reiserfs and minix
have such property. Don't know about xfs. This attack makes it possible to
detect presense of specially crafted watermarked files, such as, unreleased
Hollywood movies, cruise missile service manuals, and other content that you
did not create yourself. Watermarked files contain special bit patterns that
can be detected without decryption.

I have attached source for two programs, one to create such watermarked
files, and one to detect watermarks from ciphertext.

For example, if I were to encode my first name Jari as a watermark, I would
use ASCII characters 74 97 114 105. This example uses encodings 10...13.

    # mount -t ext2 /dev/fd0 /mnt -o loop=/dev/loop0,encryption=AES128
    Password:
    # ./create-watermark-encodings 10:74 11:97 12:114 13:105 >/mnt/watermarks
    # umount /mnt

And then to detect these watermarks, I do:

    # dd if=/dev/fd0 bs=64k | ./detect-watermark-encodings
    22+1 records in
    22+1 records out
    1474560 bytes scanned
    watermark encoding 10, count 74
    watermark encoding 11, count 97
    watermark encoding 12, count 114
    watermark encoding 13, count 105
    
Summary:
- cryptoloop and dm-crypt on-disk formats are FUBAR. cryptoloop and
  dm-crypto developers and users don't have any choice here. The _have_ to
  start using stronger crypto.
- Used cipher or key kength or password does not matter.
- loop-AES single-key mode on-disk format is equally FUBAR.  
- loop-AES multi-key mode is not vulnerable.
- Anyone still setting up new encrypted file systems using cryptoloop or
  current dm-crypt or single-key loop-AES, is committing security
  malpractice.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

[-- Attachment #2: cryptoloop-exploit.tar.bz2 --]
[-- Type: application/octet-stream, Size: 1496 bytes --]

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Matthias Urlichs]

Hi, Christophe Saout wrote:

> I posted a small description some time ago:

Thanks.

How do I specify the encryption algorithm's bit size? AES can use 128,
196, or 256 bits. Gues who didn't use the default (128) when creating the
file system on his keychain's USB thing  :-/

-- 
Matthias Urlichs

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Christophe Saout]

Am Mo, den 01.03.2004 schrieb Matthias Urlichs um 23:18:

> > I posted a small description some time ago:
> 
> Thanks.
> 
> How do I specify the encryption algorithm's bit size? AES can use 128,
> 196, or 256 bits. Gues who didn't use the default (128) when creating the
> file system on his keychain's USB thing  :-/

Simply specify a key that is 192 bits long (24 bytes or 48 hex digits).

Re: dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*)

[Matthias Urlichs]

Hi,

Christophe Saout:
> Matthias Urlichs:
> > How do I specify the encryption algorithm's bit size? AES can use 128,
> > 196, or 256 bits. Gues who didn't use the default (128) when creating the
> > file system on his keychain's USB thing  :-/
> 
> Simply specify a key that is 192 bits long (24 bytes or 48 hex digits).
> 
In other words, that's the job of the front-end program which reads the
key from <wherever>.

If/when updating the documentation, please add a pointer to a frontend
program that can emulate losetup <encryption> <bits> -- assuming one 
has been written..?

-- 
Matthias Urlichs