suprothunderbolt has quit [Read error: Connection reset by peer]
suprothunderbolt has joined #linux-sunxi
nexgen has quit [Remote host closed the connection]
nexgen has joined #linux-sunxi
tdebrouw has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
yann has joined #linux-sunxi
suprothunderbolt has quit [Ping timeout: 245 seconds]
msevo has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
ldevulder has quit [Ping timeout: 245 seconds]
airwind has joined #linux-sunxi
kaspter has joined #linux-sunxi
chewitt has quit [Read error: Connection reset by peer]
florian has joined #linux-sunxi
jstefanop has joined #linux-sunxi
souther has quit [Ping timeout: 264 seconds]
souther has joined #linux-sunxi
jstefanop has quit [Ping timeout: 245 seconds]
suprothunderbolt has joined #linux-sunxi
florian has quit [Ping timeout: 245 seconds]
alexxy has quit [Ping timeout: 246 seconds]
<willmore>
montjoie, the encryption engine works like DMA in that it reads data and writes it out somewhere else (or back to the origin), right? Can it read/write from I/O devices like the SATA controller or SD controller? Or does it need to operate only on in-memory buffers?
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Client Quit]
AneoX has joined #linux-sunxi
alexxy has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
lurchi__ has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 240 seconds]
florian has joined #linux-sunxi
CC0422 has joined #linux-sunxi
dddddd has joined #linux-sunxi
marekbelisko has joined #linux-sunxi
marekbelisko has quit [Quit: This computer has gone to sleep]
megi has joined #linux-sunxi
CC0422 has quit [Quit: -a- IRC for Android 2.1.55]
<montjoie>
willmore: only from memory
<montjoie>
willmore: on H6 it exists a crypto device dedicated for MMC
<montjoie>
it is on my TODO driver queue
aalm has quit [Quit: xyz 2.3]
ldevulder_ is now known as ldevulder
kaspter has quit [Quit: kaspter]
jaganteki has quit [Remote host closed the connection]
airwind has quit [Quit: airwind]
florian has quit [Ping timeout: 245 seconds]
jstefanop has joined #linux-sunxi
msevo has quit [Quit: Leaving]
dgp has joined #linux-sunxi
selfbg has quit [Remote host closed the connection]
<dgp>
I don't suppose any of you guys has used the AXP192 before?
florian has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft1 has quit [Quit: cnxsoft1]
reinforce has quit [Quit: Leaving.]
matthias_bgg has quit [Ping timeout: 268 seconds]
tllim has joined #linux-sunxi
lkcl has quit [Ping timeout: 245 seconds]
netlynx has joined #linux-sunxi
reinforce has joined #linux-sunxi
sunshavi has quit [Remote host closed the connection]
jstefanop has quit [Ping timeout: 240 seconds]
jstefanop has joined #linux-sunxi
marekbelisko has joined #linux-sunxi
marekbelisko has quit [Client Quit]
tdebrouw has quit [Remote host closed the connection]
<wasutton3>
megi, im finally getting back into the module you helped me out with last week. Im getting a syntax error column 5-14 using this: http://paste.debian.net/plain/1104042
<megi>
I needed it for my own use-case, so I have a debugged version in my pb-5.4 branch
<megi>
it's in the "...eink display driver..." commit
<willmore>
montjoie, that's what I was afraid of. It makes it hard to use it for efficient disk or network encryption.
jstefanop has quit [Ping timeout: 268 seconds]
jstefanop has joined #linux-sunxi
lkcl has joined #linux-sunxi
marekbelisko has joined #linux-sunxi
<montjoie>
willmore: for network, I never tested ipsec (but I should to)
<montjoie>
willmore: for mmc the EMCE should be more effective, but who know, it is allwinner stuff...
<KotCzarny>
buy mmc is limited use, mostly for tablets/phones
<KotCzarny>
*but
marekbelisko has quit [Quit: This computer has gone to sleep]
<willmore>
montjoie, LOL, true. I'm sure that it won't work because of layering issues.
<willmore>
KotCzarny, isn't that the interface used for uSD cards?
<montjoie>
willmore: the more problem is that the documentation is SMALL
<KotCzarny>
willmore, yeah, but most people would want it for generic drive encryption
<willmore>
Oh, fully understood. My point is even if you get it working, the kernel likely can't use it as the block layer at that point probably doesn't have access to the crypto info it needs to do the transfer/crypto.
<willmore>
KotCzarny, that would be the other crypto unit.
<KotCzarny>
i wonder if it works as interface between mmc controller and system
<willmore>
There's two. One general memory/memory unit and one that is mmc/memory.
<KotCzarny>
so it would be transparent
<montjoie>
EMCE seems in middle of the mmc "bus" so transparent for the controller
<KotCzarny>
nice
<KotCzarny>
free cpu cycles
<KotCzarny>
and actually might make nice hardened iot nodes
<montjoie>
but how to set this nicely in linux
<montjoie>
and where to store the key ?
<willmore>
That's the catch.
<montjoie>
it seems that the encryption is for the whole sdcard or not
<willmore>
AES-XTS?
arete74 has quit [Ping timeout: 265 seconds]
<willmore>
And that's the challenge.
<montjoie>
it supports aes-xts
<montjoie>
so I have to add support for it to uboot
<willmore>
Linux will want to encrypt a partition, so the crypto engine has to support a starting block address or some kind of block offset because the '0' block of the crypto needs to be the '0' block of the parition, not the whole card.
arete74 has joined #linux-sunxi
<willmore>
And I don't know how the layering works in the luks/dmcrypt driver.
<montjoie>
another solution is to have sdcard only for starting and rootfs on encrypted NAND since EMCE support the NAND
<montjoie>
willmore: EMCE bypass dmcrypt/luks
aalm has joined #linux-sunxi
<willmore>
So you'd need your own drive crypto tool instead of using the existing infrastructure.
<montjoie>
it seems to intercept MMC/NAND "traffic"
<willmore>
That's not happy making.
<willmore>
montjoie, understood.
<montjoie>
If I understand well the limited documentation...
<willmore>
I wouldn't be surprised if it's always there in the data path, but defaults to transparent.
<montjoie>
but having to store the key somewhere readable is...
<KotCzarny>
sid for key?
<KotCzarny>
i mean efuse
<montjoie>
it is readable by anyone
<montjoie>
a possible way is protect the key by a password and ask it at boot
<KotCzarny>
not if you burn the boot order?
<willmore>
montjoie, yep, that's the normal way to do it. Ask at boot.
marekbelisko has joined #linux-sunxi
gsz has quit [Quit: Konversation terminated!]
marekbelisko has quit [Client Quit]
<montjoie>
ah there's more EMCE register directly in sdhc and ndfc controller
<montjoie>
wow it seems that we can choose to encrypt only some sector
<wasutton3>
megi, that new version has the same syntax error. Do i need to add that userspace-consumer-of.c somewhere to a makefile?