<checkpoint>
*** Your GCC is older than 6.0 and is not supported
<checkpoint>
what da schnitzel!
florian has quit [Ping timeout: 272 seconds]
Mangy_Dog has quit [Ping timeout: 268 seconds]
tmlind has joined #linux-sunxi
<tmlind>
hey all
tllim has quit [Read error: Connection reset by peer]
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
gnarface has quit [Read error: Connection reset by peer]
lurchi_ is now known as lurchi__
gnarface has joined #linux-sunxi
gnarface has quit [Quit: Leaving]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 265 seconds]
ChriChri_ is now known as ChriChri
diego71 has quit [Ping timeout: 258 seconds]
gnarface has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
pmp-p has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
pmp-p has quit [Ping timeout: 265 seconds]
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 240 seconds]
megi has quit [Ping timeout: 265 seconds]
tllim has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
tl_lim has joined #linux-sunxi
tl_lim has quit [Quit: Leaving]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
diego71 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
pmp-p has joined #linux-sunxi
pmp-p has quit [Ping timeout: 265 seconds]
craigo has joined #linux-sunxi
malestorm has joined #linux-sunxi
wasutton3_ has joined #linux-sunxi
wasutton3 has quit [Read error: Connection reset by peer]
selfbg has joined #linux-sunxi
<KotCzarny>
checkpoint: i would like one too, if you find it
<KotCzarny>
:)
jailbox has quit [Ping timeout: 268 seconds]
<wens>
montjoie: maybe trng on older chips is just the raw output, and needs some whitening?
* wens
does not understand crypto stuff
<montjoie>
wens: it seems that a83t TRNG burp zeros, so removing zero could produce something usable BUT how to make difference between good zeros and bad
<wens>
what about h3 sun8i-ce?
RichardG867 has quit [Quit: Keyboard not found, press F1 to continue]
RichardG867 has joined #linux-sunxi
bjne has joined #linux-sunxi
AneoX has joined #linux-sunxi
superprower has joined #linux-sunxi
yann has quit [Ping timeout: 258 seconds]
AneoX has quit [Ping timeout: 268 seconds]
AneoX has joined #linux-sunxi
tllim has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-sunxi
warpme_ has joined #linux-sunxi
florian_kc has joined #linux-sunxi
florian_kc is now known as florian
<montjoie>
wens: I have just restarted a job for it, lots of repetitions, seems to repeat some pattern
<willmore>
montjoie, seems different can be good, then. (H6)
Mangy_Dog has joined #linux-sunxi
<elecon>
Hello guys. I'm trying to build distro for orangepi3 with buildroot. U-Boot gives me "Error reading cluster" when I try to read from emmc. I'm using megous u-boot (opi-v2019.10). If you have any thoughts or things that I should test please let me know. Thanks in advance.
<willmore>
montjoie, that does not look very random.
<montjoie>
and now I know why the PRNG is bad... it is cyclic, so I get the seed from the output and the new seed is ... the same than the one used
<montjoie>
something is weird
pmp-p has joined #linux-sunxi
<tuxd3v>
Usually PRNGs tend to repeat after some time... I believe the one in A20 is 2^256, which for a smaller device is a lot, and could be considered safe
pmp-p has quit [Ping timeout: 258 seconds]
<willmore>
Yeah, that's not how a PRNG should be. :(
<willmore>
montjoie, how does it work? You feed the PRNG a seed, it feeds back data plus the new seed?
elecon has quit [Quit: Leaving]
elecon has joined #linux-sunxi
Asara has quit [Ping timeout: 240 seconds]
tllim has quit [Quit: Leaving]
<megi>
elecon: my u-boot doesn't support eMMC on H6
selfbg has quit [Remote host closed the connection]
<megi>
most probably H6 also needs smaller DMA transfers just like A64 on MMC2
<montjoie>
willmore: yes I give a seed, but unlike sun4i-ss, nothing give a new seed so I grab the new seed from extra output
<montjoie>
my CE tests grab 12bytes
ganbold has quit [Ping timeout: 265 seconds]
<montjoie>
but I found an example where the same seed appears after 128bytes
<montjoie>
so if, in a few time, I found a cycle of only 128bytes (which is very few), other probably can be found
bjne has quit [Ping timeout: 240 seconds]
<willmore>
montjoie, did you test that the seed works? By which I mean, did you repeat the same submission with the same seed to see that you got the same output? Then one-by-one, alter the seed bytes to ensure that they all effect the output.
<willmore>
I just worry that the structure you're passing the PRNG isn't aligned correctly or something. Probably an unfounded worry, but...
<montjoie>
yes I test with the seed "SEED" length of 32 64 128 256 511
<willmore>
bits?
<montjoie>
bytes
<willmore>
So it takes a variety of lengths as a seed? That's interesting.
<montjoie>
sun8i_ce_prng_seed PRNG slen=32 is when I got a new seed
<montjoie>
it appears twice since linux does it, and them it is my test which set a new seed
<montjoie>
dlen is the length asked and todo is the size I ask (dlen + seedsize + xx)
<montjoie>
I prend the initial SEED then the output and then the new SEED
<montjoie>
you can see that the initial seed (line 72 ) is the same than the new (line 87)
<megi>
'Supports 160-bit hardware PRNG with 175-bit seed'
<megi>
isn't loading more than 22B of seed value pointless?
<megi>
175 bits is also nicely not rounded, heh
<willmore>
megi, depends on how it makes that 175 bit seed. It could hash down the seed you give it.
<willmore>
montjoie, okay, I see some of the repitition. There is not context to the PRNG, is there? Its only state is what it receives in the request? (so the seed, and ask are all that should determine the output?)
<willmore>
megi, it's not uncommon in cryptography to start with a low quality 'random' source, hash that down to something smaller and use that as the seed for a PRNG.
<elecon>
megi: Thank you very much. I'll try this
<megi>
though for stateless crypto module if you have to preserve the state and send it again on next request this would be quite wasteful
<megi>
to rehash it on each request
<willmore>
megi, yes, that's true. You should be able to have two operations a seeding one where it makes a high quality seed from the low quality one and then a chainable (seed,len)->(new seed, data) transform.
<megi>
I tried googling for 175 bit seed, and all I get is allwinner references
<willmore>
That's why I'm confused when I see a (seed, len)->(data) type of PRNG
<megi>
yeah
<willmore>
It leads to a lot of issues. You can manipulate the output by picking different data lengths as that will determine what of the output will be used as the new seed.
<willmore>
Ideally, you have a way to start with a seed and then generate a long sequence of data. This type of generator could be adapted to that by asking for large, fixed sized chunks of data and buffering them. Once it's all consumed, generate a new chunk.
<willmore>
That avoids the ability of the consumer to alter the generated sequence--which could allow a malicious client to influence the state of another client.
<megi>
H6 pdf mentions "load new 15bits key into lfsr for PRNG"
<megi>
which gives a hint on what we're looking at
<willmore>
How montjoie made any sense out of that datasheet is beyond me. Well done.
<KotCzarny>
:>
<montjoie>
anyway linux always give a seed of 32bytes
<montjoie>
so I use the length given by linux for the dma mapping in case of
<willmore>
What does the datasheet mean by 'word', is that 16 or 32 bit?
<montjoie>
32bites
<willmore>
thanks.
<willmore>
Hmm, okay, the PRNG has a 160 bit (5 word) alignment...
<montjoie>
for sun8i-SS giving a length not multiple of 5*4 produce no output, sun8i-ce seems to doesnt care
<montjoie>
anyway I fear the copy/paste poblem on this part of doc
* KotCzarny
lols at bites
<willmore>
That's even more confusing, then.
<willmore>
montjoie, yes.
<montjoie>
since the datasheet speak about 15bit...
<montjoie>
175bit was the size for sun4i-ss
<willmore>
KotCzarny, I knew what was meant. English itsn't a language, it's a negotiation.
<KotCzarny>
but it's funny on more than one level
<willmore>
montjoie, then the question is did they cut and paste the silicon as well.
<karlp>
isn't an lfsr used after the random source for post processing? not as the source itself?
<willmore>
KotCzarny, you never got the bit/nybble/byte joke?
<KotCzarny>
willmore, ya, that's why it's funny (for one of the reasons)
<willmore>
karlp, there are tons of different PRNG types. Most easy ones are a series of LFSRs with their outputs xored.
<montjoie>
please I tried to shadow my typo
<KotCzarny>
montjoie, no shame, it was really good :)
<montjoie>
furthermore good in french
<karlp>
willmore: just thinking that a small lfsr soundsd like the rng in some of the stm32s for instance, that use some ring oscilators that then feed down into lfsrs,
<willmore>
montjoie, your English is vastly better than my French, so, please don't feel any criticism!
<montjoie>
anyway if the prng is bad, I could xor it with the bad trng and who knows...
<willmore>
karlp, could be. LFSRs suffer from the zero problem--they can't ever break out of an all zeros feed condition which means they can't produce one which means they have a slightly smaller keyspace than ideal and that can be exploited, so you use a bunch and combine the outputs.
<willmore>
montjoie, then you'd have an even worse RNG output. :)
<willmore>
I still think it's best to avoid PRNG and TRNG units on chips like that. At most use a TRNG to feed into the entropy pool for the TRNG in Linux and let it use its PRNG from there.
<willmore>
It's just so darn easy to get a PRNG wrong.
<megi>
if it's stateless and we don't know what part of the data is supposedly hidden internal state it's unsafe to use for cypto, since if hidden state leaks, your randomness is compromised and future values can be reconstructed
<MoeIcenowy>
mripard: excuse me, how can I make an environment for checking DT yaml schemas
<megi>
you need yaml-bindings repo
<willmore>
megi, exactly.
<megi>
and then run make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/...
<megi>
in linux tree
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
yann has quit [Ping timeout: 265 seconds]
ganbold has joined #linux-sunxi
florian has quit [Quit: Leaving]
popolon has joined #linux-sunxi
matthias_bgg has quit [Read error: Connection reset by peer]
<mripard>
and then you can run make dtbs_check as megi was suggesting
Xalius has joined #linux-sunxi
Xalius has quit [Client Quit]
Xalius has joined #linux-sunxi
Xalius has quit [Client Quit]
matthias_bgg has quit [Ping timeout: 268 seconds]
yann has joined #linux-sunxi
<montjoie>
willmore: note that 15bits could be a typo from 175...
<montjoie>
a typo copy/paster on all datasheets kr kr kr
mripard_ has joined #linux-sunxi
bbrezill1 has joined #linux-sunxi
bbrezillon has quit [Ping timeout: 260 seconds]
mripard has quit [Ping timeout: 258 seconds]
mripard has joined #linux-sunxi
bbrezillon has joined #linux-sunxi
bbrezill1 has quit [Ping timeout: 265 seconds]
mripard_ has quit [Ping timeout: 268 seconds]
aliosa27 has quit [Read error: Connection reset by peer]
steev has quit [Ping timeout: 252 seconds]
Benjojo has quit [Ping timeout: 245 seconds]
ullbeking has quit [Ping timeout: 258 seconds]
ccaione has quit [Ping timeout: 252 seconds]
warpme_ has quit [Ping timeout: 272 seconds]
anarsoul|c has quit [Ping timeout: 268 seconds]
aliosa27 has joined #linux-sunxi
anarsoul|c has joined #linux-sunxi
warpme_ has joined #linux-sunxi
Benjojo has joined #linux-sunxi
mripard has quit [Ping timeout: 240 seconds]
bbrezillon has quit [Ping timeout: 272 seconds]
mripard has joined #linux-sunxi
bbrezillon has joined #linux-sunxi
mripard has quit [Ping timeout: 260 seconds]
mripard has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
netlynx has quit [Quit: Ex-Chat]
craigo has quit [Ping timeout: 272 seconds]
indy has joined #linux-sunxi
tllim has joined #linux-sunxi
gsz has quit [Quit: Konversation terminated!]
florian has joined #linux-sunxi
ccaione has joined #linux-sunxi
<checkpoint>
mmc is bocken in 3.4.104 but works fine in 3.4.102, presumably caused by clock.c redesign
<KotCzarny>
afair im using 3.4.113 without any problems
<KotCzarny>
might be that armbian patched that long time ago
ccaione has quit [Read error: Connection reset by peer]
<checkpoint>
hmmm
<checkpoint>
is 3.4.113 available on github ?
<KotCzarny>
check armbian git for patches
<KotCzarny>
and armbian build system in general
* checkpoint
prefers devuan distro as the got rid of systemd
<checkpoint>
will check armbian anyways, thanks
<KotCzarny>
you can fix debian without much trouble
<KotCzarny>
i did on my boards.
<KotCzarny>
:)
popolon has quit [Quit: WeeChat 2.7]
florian has quit [Ping timeout: 258 seconds]
ccaione has joined #linux-sunxi
<montjoie>
I have lost all hope in sun8i-ce PRNG, even after "fixing" the new-seed mechanism (using an offset for taking it in middle of output), rngtest continue to say failure
<KotCzarny>
maybe ask some aw engineer ?
<KotCzarny>
or someone that can ask them a question