[acc, pqc] Part 2 rebase of PQC development work into expo#202
Closed
[acc, pqc] Part 2 rebase of PQC development work into expo#202
Conversation
…nvironment poly_add_dilithium was arbitrarily chosen for its innocuous-sounding name. Signed-off-by: bunnie <bunnie@kosagi.com>
This contains the test case and expected data as copied from the PQ working repo. Note that tag on the expected data case is 'dexp' for the current main branch, not 'exp'. Signed-off-by: bunnie <bunnie@kosagi.com>
Simple overwrite of what's in the expo main, no changes. Signed-off-by: bunnie <bunnie@kosagi.com>
these are also a direct copy from the PQ working repo Signed-off-by: bunnie <bunnie@kosagi.com>
This is a full copy of the HJSON file from the PQ working repo. This contains references to a kmac block which are not actually incorporated in this patch set (it is in the simulator but not in the hardware). But more importantly, it also expands the size of the IMEM/DMEM for OTBN, which is necessary in order for the "assert" to pass on the size check in the dmem compare. Signed-off-by: bunnie <bunnie@kosagi.com>
…ng repo Here, I think there may be some divergence between what's in expo and what's in the PQ working repo. The actual format of the dmem expected data takes the form of address ranges followed by hex numbers. What the original code seemed to expect is actually a single large hex block. The code from the working repo is pulled into expo in this commit, but this may not actually be the correct decision. Furthermore, there is a strange problem where parse_actual_dump() is handed an ASCII object, but the type is 'bytes'. There is a mismatch in the abstractions: what we get is ASCII data that looks like this: dmem: 04112345... So there is literally the six bytes b'dmem:\n' are in the stream, and the data being passed in is ASII characters representing the binary data. A converter which strips off the first 6 bytes, decodes the ASCII and turns it into the binary data is inserted into parse_actual_dmem(). This feels hacky and wrong; but I'll commit this here and leave it up for reviewers to comment on the correct method to fix this. Signed-off-by: bunnie <bunnie@kosagi.com>
More API divergence. it looks like what might be happening is some fairly fancy provision was baked into the expo main branch which can go into an ELF file and extract multiple disjoint regions of memory for comparison. This would imply that the data is labeled and tagged for such comparisons, but no such labels exist in the actual test data provided. This change *probably* breaks some other tests that depend on this feature, so while this allows us to run this one PQ test case, I have a strong feeling that this is the wrong approach. However, it's easy to pull out commits so let's drop this into a PR and see what reviewers have to say. Signed-off-by: bunnie <bunnie@kosagi.com>
…ng of dmem Signed-off-by: bunnie <bunnie@kosagi.com>
…ntitan Usage: 1. Copy the routine from pq-opentitan into the desired location and setup the BUILD template 2. Copy the test from pq-opentitan into the desired location, setup BUILD, *but* in this case, rename the '.exp' file with an extension of '.exp2'. The '.exp2' file serves as a reference to generate .exp/.dexp files. 3. Run the script using the test target you set up, e.g.: `convert_exp.py --test_target //sw/otbn/crypto/tests/mldsa:poly_add_dilithium_test` This will attempt to do the following: 1. Build the test, to create a .elf file by trying to run the test. It's OK if the test fails, but we do need a .elf file. 2. From the .elf file, dumps all the symbols with `nm` 3. Tries to match based on address in dmem any contiguous memory regions in the '.exp2' file, and assigns them to the label corresponding to that label in the code. The matched areas are written to a '.dexp' file that is consistent with the current format in expo. 4. Also checks to see if register values are specified, if the line pattern-matches against a register spec, it will also output a '.exp' file that contains the expceted register contents. Regions that can't be matched are printed as an error. Signed-off-by: bunnie <bunnie@kosagi.com>
This one I think extracts successfully, but the test doesn't pass because the computed value doesn't match the expected value. This might be more an indication that the port over of the OTBN extensions is not actually complete. Signed-off-by: bunnie <bunnie@kosagi.com>
…ng script Signed-off-by: bunnie <bunnie@kosagi.com>
somewhere along the way this output file got munged into an ascii text format which isn't actually the supported format used by the bazel tools to compare outputs. Signed-off-by: bunnie <bunnie@kosagi.com>
…exp file Signed-off-by: bunnie <bunnie@kosagi.com>
This seems to be necessary to select a variant of mlkem/mldsa for running a particular test. Signed-off-by: bunnie <bunnie@kosagi.com>
this is another blind-copy of artifacts from the pqc-opentitan repo, a lot of changes happened so probably the diff needs to be carefully reviewed Signed-off-by: bunnie <bunnie@kosagi.com>
I'm able to at least build the test, but running it fails. Some important notes: kyber768_mlkem_keypair_test is missing `const_tomont`. What I did was just blindly copy all the constants from what looks to be a more modern kyber_mlkem_keypair_test.s file back into this file in hopes that maybe it works. This is probably the wrong thing to do. kyber_mlkem_keypair_test.s does *not* have a .exp file associated with it in the PQC-opentitan repo, which makes me think that the testing methodology may have changed along the way. It also looks like a section of entropy that should be an input to the test is all 0's, which makes me think the test bench is expecting these data to be poked into the test bench dynamically. So, this commit serves as more of a checkpoint to see which series of mlkem tests are the correct ones to be focusing on and to check if the testing methodology is the same. Signed-off-by: bunnie <bunnie@kosagi.com>
not sure if this breaks running from bazel environment, but it fixed command line runs Signed-off-by: bunnie <bunnie@kosagi.com>
this passes using the manually run script Signed-off-by: bunnie <bunnie@kosagi.com>
this passes - next is to figure out how to integrate this into bazel? Signed-off-by: bunnie <bunnie@kosagi.com>
Signed-off-by: bunnie <bunnie@kosagi.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
- optionally allow specifying --copt parameters - optionally allow specifying a custom nm path - allow 'D' as well as 'd' labels - print errors if a command fails - stop after finding one label for a data region Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Also get dilithium2_keypair_test passing with exp -> dexp conversion Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
the false_dec tests currently still fail because they aren't working on the source repo. Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
These were accidentally omitted from a recent commit. Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
these tests were broken before, but now they work! Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
This is a helpful stepping stone for enabling random testing. Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Use test-generation infrastructure to create random tests for ML-DSA key generation. Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Use test-generation infrastructure to create random tests for ML-DSA signature verification. Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Use test-generation infrastructure to create random tests for ML-DSA signature generation. Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Create some benchmarking scripts to collect data from test logs and compare average/median cycle counts between versions. Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Previously, the randomly generated messages were sometimes slightly too big to fit in DMEM for verify. Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Kat Fox <kat@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Previously, the high bits were not getting properly rotated on every iteration of the loop. This bug was introduced (by me) in commit 50c83d/61aebd6 when w1 compression was introduced. It's very rare in practice, which is why it wasn't caught by random test runs before -- the coefficient needs to be exactly Q - gamma2, *and* the next (incorrect) high-nonzero bit needs to not match the coefficient's actual high-nonzero bit (in practice most of those bits are 1 so a mismatch is less likely than chance). For reference, the inputs that triggered the bug were (with empty ctx and deterministic signing): msg = 6c1ccf244058898aff1fb55d62dcf7d31c6c3dfb9a0393bd6f84bedd937bcc2e sk = 4af81176501ee26cae8a289ca0221106e7c4f5771ae14698362abeca0be51ac9 498245ae48dada299382ab557db2b20363fe26370416a0db27fc4126e1845ef1 fdc6c374ae20dc8e5036f16ec954c775c5e6a2166ed2cecdd426800668023168 637494ec3047babef07e88ff934234a809a101afdcda4fba1a6a755511b1b9c8 3728610403203722247461477061035106876517111802684731431386044446 1366000306365655026305108248860068262886505021221846403423455074 6806226782776242055723537780078557871674576814024035505236467616 5583243703420328858475283547335600587245402847734152547066683462 5017468035803785516350548055622278401421742126848378278272440671 3234385001334337221555516020536222750264383355331171467216026781 0806848617586842012848522057550288583028832768800118188038207161 1467708605514440671323068635340672018644134667443110478350701001 0361863472308176516614514644673324164685161188515545483317340382 6274761313617834386403062762331723773648008451207768838382085153 5184613636244446031653663424515337880514848538443203012773226765 8185308274267445631501567875888637464453235387742267744065522438 7352678412216413804107512662103568676743815156081785663772338468 6376451722336273823833302016642600423327061656384283827688644684 0582544344464803220356071461774344070030777504073550816700712428 7636755283766175041381231717810220781388188648384381374338644362 8460253784006267867311136751105146461254043241342502561614304885 6120148130307135875766565724023436621757738043087215843368108653 4157643133270425611601726462481357276408676103747444280400874345 3754483247601644161700083288786884535455468183527546836466004658 5232441827507044650384442888457016535814045327346436307651151826 5043868566735808654286684563284503714184377566618286613671688751 1840525508765577036455307055714472436665816522538743468582511753 1466465423148070806762107488828122878641853503731856723032731538 4670582642744463882055258574027074004361626468645152476183548471 7243231282586344702787184010860321373016630735781315024254434763 5057362086170162713710412124257032070161247676800282611385181703 0063662217750285218483854103127270677001463850141742311425071161 3840883825833712436715077777137441417840168245016627075806514174 8835238413672571102024214420614218441878170322068416746263713367 8636586787605082802186032386863260005167158261117553688362436307 3046320235807317643641538020400116722160667224286114474280541236 6774080611536045202783555606404606041172352455155384346036444377 0246768581080430746034174060470513435261476538306566883147758321 2001560684376054558350418032480063754881704836314350340052212410 4468351855658886146560416541554613216217610727588431668211425280 2010826716746288718266472158577772465573802122465423268673856537 7001010063525263587873862717341188674053132601473725323108766611 6005378305547868048288351261347140057621712825667356134157867587 8504451154807062822261630064513221668271074073634537364216457464 6361527363748218778282577606800186220250274765345516020603300088 7814683288782151664532860214230032133004743664383676604233025467 8863224011178437017388713426370420458842505283735047080263868736 5032755072874644763050111633188032306830032286557420166233381550 495543a0dd250dbf153ae38b6ab5b6007f8aaa3d679dc88a2e3b15bc9b7e4606 d7297978577940c08fcef32b8afce479dd4203249dc31c800eff4eaaaf926bc6 d405ff6d073a6d0d7444da9242da6063c8ce5a7b3e0bb9c5fc1722e951c08a20 7954416d46152ef29e6249940752e7bfca2e7c7d0d3ebfc9474cd103e689ea94 87588a5e85ac461b8bd39e6d50dc54c44ecdfd64e33d820e794bbd89bcfc927a 0b584e725c39694cd88f85d509f4674fbf2b24af717a8cf525df1ed9826d9bc9 d4827215397bb2cef3385bf7b8e8130599fbc54a945c43ba7bf2fefb7d118cf8 6534efa79af624907097b5ce86dae33ed5687a42fb1e77ad0dce6ca58b53f22e f8edcb1d0ef77c5b662013b36e93d7c63003a1146c0ca196ec38ba95e5d3b610 2d14822b649a436568fe14b429c37ad0a1af66e9b8792e27314c26c5ca4504c4 84a48dd1e2d515a21edee1f0b1819c31c39dac4bc59e5293ef01d2ebbec4aa3f e7dc4bfa7ab5c7ef717fca930a2b6183c7f8b0a4e8c37ce90c88b67a892a38ba 081fbbf5fde9eed647286f94490af24153933ffd7663095bda3e5241fe1cfa9f ce61cf8f82e2ff4ed01574c99cbd3eab6433269ba47de47aa2fb1c0ca99f3e17 9322b54f99ce4d8e95982b43cd140db85b7c1fad5f33f7f1e1f562e6e657422f 750aff0f1cbf37d1f123ef0c171a6c64dec571f03f1d995f11d6f851d2b818e5 694a4e0c54bdaeca6ce923db23833a53ef749b8aa7596aa40a5b9b8ff5d05aef be4cff5ac28c60908df7ba7249488cf3f8cedef7fc333dc32dc5b7a247ab1655 bbf443e2fed1bdd3418318da7fc99dff5af88be1ad0e10a1d196b1d549c40c8b 4becb12d0214adcf5a08351db4317e06330b8f5511713a10490f1171042e039a 7da2f19247c4b49a76474a9b9166e2ae2fb367a054a5fc2f267b541360cc940f 09405f25d8a445bb29ea10ae14bd81160ebb56cac6ff93c561a5b3de2b1176b7 fd88392fbfe57dd161888edad4f2f7d37b715978bef100ca2f5e46d5827a4bcf a63f90c63698cbf8dedd562e7e12db3c9dda345289937cd45a231b2b5209b3d6 77572d8b9306554407f4b9c3bf40a64d95deea4d9e1b36e34717eac6606675b9 cdb7d845133a43a40904c2e25cf049f5c59ef777057655a4309be0859668b9aa f03ec6ffaf49ee416c0619e3669c226e59127c07e4b18f01027e9a2f066e4659 71727d89aa1c4b83002164e447c7e675ff8655c1a50ea02c1df063c5d5fe10a8 5e5bcba2bcd0f65de1fe3d2dc25b723d0452f88dce20ac40c4342d50b58e4be7 b75edc2d6a267bbfb8517524efca25c5107add78a81318797a9e5c46cf636d11 c5a18e78054de085c8a6c463a3e7338790fa95912684c170df92071da9ea16dc 2e9584de47e6a95fbdc0a74c05657e738e72ad994dc017cb1252678775278f8d ebbf52bafc458853f94bfc71261669a2ab3642fb9d6842eaee35f9812728fb80 b336a51dd2d75ee56ff9bde4bf1642db6b7ebaaca4d4f6de9027bcde185d69ca 36a4dc998af8cd0fe339bd4973cdb496c161836963ea0ef459f8c93a98d9efc1 daf053dd49e2453ab911eeea0c99b1cd1bfa7f8f8c6662fd7b36fefd0f50f20c f8d2ff564ff5f84b3c077b0e46792e526aa923a7ec272118cc589d76df7992e2 5657d223f5afeb02ca70b8b61073d04f9e1dab705cec4304cf9a256ecfdaeae9 5bae5adf6b7fb69bd5bd1f3ad7c52cfe235bce15a0173d557279ebf9869c7b6b e1515a74ff85150b77f4bfe1ca3e6a7cf9e73a0f9b2b13e7f3ec1540d1bd931d ccd8329dccfe7598048fa1a6839909cbc41478dcca2dcf346c72ee62080d3388 5e4328156254424971c8ab9d2b8395265d5bd8177e753eea98ad6deb5826619d 9b6b708ea7d56a57ee9710a10757624f0927a463ccc8ae47e9a7eb7e236ffd7c 9b9d21958e9ee43b21f624f2a83620709be7936071518ed784a29ba94fcc6af1 4ea7cb1c1eaed5adb47df54e98ff955d1e5235ff290bf066e154b1c5871d5aa3 0dcbf051347b5ee7931767162d53a6da4a9b846b253f05b9d6603fee5cea5c59 e444ba8d72f153562572c8633fa7f7fcd5cef022e35b8f4d9bfe8e96d8114211 12b6dbf792aba5014836b2a673619b003fe7d4330ce7a1d6feb719278c7c9fef c4c9cde39ece836b19f0263f01efc81632d46985f7f5f06c5b1fa5aa39148b61 9b5193702cae7a172fa1bf3073e4c0839d598e7aaf88c0f50c62c52634d5ba25 1aaade5177670ca1da80ac5db9c15b1fcc5373041aafc426b2f0fa6f63790b7a 8d4e1873089dd4139234906539ccdc2eaeffba782f61ddf3628673aea3340f66 81bc6adf70d886eba8ac4536c0551eb16d308e90f9390e1c93198ad9d03a4b08 d768cf877d1c04f4a5bb327c0c7482f069f10ee4246a6c51347aac725f2b7b2a eda9503ffbdc593bda09666e30c9a4ad0ad3a009383e3e8eb563c699c1a1c9c5 ec84f0c443384fb7fa1a8fca6aab35dbeb577969c07a42725c686033105765d9 e24cd15c3b6232f9cdb24978e4a0de12bf77ab0c9df72be7456094634e852f18 97071e34311d544250b77e6bbe59d8927f699a498b1be161a852e5e2616c3997 3652d9f40ad62c7b15a10b97b4be3b350979a276e992029caf7e49ee6b598179 7c50dbdbd14f1b65fc55034d0a74cd72fd0235c4d0b3c3a6b366df28480c3c26 46af1f37358000bc0ea28ea55d7861167fb3025777e0c3b80ded8cad49adc244 0f197e782ea399094429667217ebec74a1ac08a6017a30ab84176ddfc7e97cc2 f1e2f37db27efc1ee91ed15a1fdf4300f36e03e85719033ab284fd4b8556e219 6185757d9ee38eeee9845f74346c2ee1fbc1ea05c6ffe1675c06e51291500974 daf45e84f454b635eb712c94216d5074d64e2e2573567029765fa5689c03fcaa 74c293e9c8f690a993b2dcddb7164a2f874e836440fc7a85cd77e918a4a87047 76281781a5f88925577e15e4556fd122c8041616063aa5f7dc8af16dc9aa60b2 d0083544abc77581a18b6363f8ebf66e297967a83171d6e18e958fb285a37635 e0298344ef4f20556f9fb891498306336695421d314da4d386346f554af008fb 5e38cca8d1dc86eec3ba52eff2d778ee96c15bf446c26452b0776ab614570ea7 1054c0342fb183255abcf6bf468147a1fb4f2d4d905e27c829d928ee28677c38 2a98d6f57db273cf9c414094cf0ab3eabaf34145da4c8cbe92d0d1591f0b2b0d 6393d670ee156c8d6fb5a978696d43799814fd0ec6ce0cc4abf7315f7231cd67 bff7f1944aa2f85a56a48bc20f91c9ecabe069b2de07f760a05f63b9bf7da28e ff84c140119398ebb996de33f29765ed0705ca336f172b3d3705f7fe9b004708 b49bdd13e7ebe431007388f7ce4748056517c1a2068801c654df71e654989049 f4e1d69baf1ddb93ad8616d2dc8cc949d0e293b63a5c4ba96b34b5690a74da10 e1875254015324dc610d184d596d9bd027a1a68478cbda53bb60b753cd0d7133 Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
…_hint. While debugging a failed test, I adjusted the comments to make it clearer to myself what was happening and found a tweak to the bugfix that makes it slightly more efficient. Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
This test has unrealistic inputs that are designed to exercise all logical cases in poly_make_hint equally, including the rare ones. I verified that the test catches a recent bug found in poly_make_hint on a rare code path. Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
Signed-off-by: Jade Philipoom <jadep@zerorisc.com>
…-DSA papers Signed-off-by: Evan Apinis <eapinis@zerorisc.com>
Changes to the otbn stat collect python file affected what stall cycles were accumulated. When you step the simulation during a wipe cycle the stall is no longer accumulated. Additionally fetch stalls were already accumulated, because they were caused by the previous instruction. These two changes reduced the number of stat collected stalls from 4 to 2. This commit updates the test to match the behavior up the script. Signed-off-by: Evan Apinis <eapinis@zerorisc.com>
Verilator otbn top sim was missing the kmac interface and fusesoc package to import the parameter value. Signed-off-by: Evan Apinis <eapinis@zerorisc.com>
Signed-off-by: Evan Apinis <eapinis@zerorisc.com>
Fixed lint warnings in KMAC and OTBN RTL and DV for earlgrey and darjeeling checks. Also fixed lint warnings for verilator. Signed-off-by: apinise <eapinis@zerorisc.com>
Signed-off-by: Evan Apinis <eapinis@zerorisc.com>
Signed-off-by: Evan Apinis <eapinis@zerorisc.com>
Signed-off-by: Evan Apinis <eapinis@zerorisc.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR commits the second half of changes from expo-otbn-pqc into expo. It has been separated into 2 parts due to the size of the rebase being > 100 commits.
See PR #201 for the first part and PR #197 for the entire rebase.