GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE

  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Notices by Jarkko Sakkinen (jarkko@social.kernel.org)

  1. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 02:14:15 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Haelwenn /элвэн/ :triskell:
    @lanodan AH OK sorry! Yeah, well that part was just a click bait ;-) I agree that it is engineering wise worse solution!
    In conversation about 2 months ago from social.kernel.org permalink
  2. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 02:12:59 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Haelwenn /элвэн/ :triskell:
    @lanodan it does not rely on assumptions. it is more like that in production you often need to have somehow certified/audited crypto. I.e. it is irrelevant how strong or weak the crypto is in some sense as long as it has gone through that process.

    thus, statically linked crypto is a problem.

    also it is a problem even when the crypto would audited that you can only hotfix all deployed rust by updating all possible rust programs. it's much easier to hotfix a single crypto entity, which could be DSO.
    In conversation about 2 months ago from social.kernel.org permalink
  3. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 02:12:58 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Haelwenn /элвэн/ :triskell:
    • Jarkko Sakkinen
    @lanodan it's a special corner case and i'm talking about deployments at scale of even hundreds or thousands nodes and fucking armed guards and shit xD usually corps have this thing called Secure Development Lifecycle (SDL) process that everything to needs to comply and it is hard to map to bunch of Rust programs with random versions of random crypto.
    In conversation about 2 months ago from social.kernel.org permalink
  4. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 02:12:57 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Haelwenn /элвэн/ :triskell:
    • Jarkko Sakkinen
    @lanodan you have to keep in mind that while rust is memory safe there is no programming language that is "crypto safe". thus you need to do this in order to scale.
    In conversation about 2 months ago from social.kernel.org permalink
  5. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 01:14:21 JST Jarkko Sakkinen Jarkko Sakkinen
    Software crypto would really need its own "official" systemd service as that way any application could have audited crypto. I.e. crypto operations would be executed by that service and results returned back to the caller. It could probably be just user service running inside session in order to guarantee better privacy.

    This is partly because Rust does not have a proper DSO support, and this would address this flaw in Rust. It is not a question how great some random crate is but more like can you make software that can be used in production as per standards that companies use.

    E.g., I cannot recommend to use tpm2sh to use anything else except kernel testing for this exact reason no matter how the crates are implemented or how well I might orchestrate the calls.
    In conversation about 2 months ago from social.kernel.org permalink
  6. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 01:14:20 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Jarkko Sakkinen
    It would be comptetitive advantage for Rust to have first class DSO support. It's like 99% of things Rusts static linking model is exactly right thing to do but for 1% of use cases you should just have a DSO.

    Prime examples:

    - Core crypto libraries. These need to be hotfixe when CVE arises.
    - Core graphic libraries.
    - System GUI libraries.
    In conversation about 2 months ago from social.kernel.org permalink
  7. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 06-Feb-2025 07:39:43 JST Jarkko Sakkinen Jarkko Sakkinen
    "keep calm and hack linux"

    My job situation back to more Linux oriented work, which should allow me to have space to work on also on my unfinished patch sets i.e.

    1. Continue with v4l2-loopback (according to Git last time touched 2025-19-01)
    2. TPM2 asymetric keys (2024-11-18).

    Nothing is fully closed yet but having a meeting for one decent opportunity tomorrow that I will consider. Thus, also open for queries since you never know until ink is on the paper of course ;-)
    In conversation about 9 months ago from social.kernel.org permalink
  8. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 06-Feb-2025 07:39:42 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Neal Gompa (ニール・ゴンパ) :fedora:
    @Conan_Kudo

    I don't know and I knowingly do not check the previous submission albeit I know it exists. I check that only when I plan to send this. It is a risk because it might dilate my creative thinking :-) I don't care if the first submission does not end up anywhere as I don't have any rush for this, i.e. can do as many iterations as required. I'm also pretty seasoned and patent when it comes to LKML ;-) I.e. that part is least of my worries, or I don't give a fuck to say it straight :-)

    Please take this with a grain of salt how the code is *right now* (i.e. not yet ready for review) as I've had to take a break from this (had not free bandwidth).

    https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=v4l2-loopback&id=4a4a2cfa6724dc546e1ab4d56e8a15461512e7ce

    I also have a matching test program, which tracks 1:1 the ioctl changes:

    https://codeberg.org/jarkko/v4l2-loopback-test/

    The commit on top is my staging area not something you see in the final patch set. The test program helps me to make sure that I don't catastrophically break anything.

    I'll basically do for RFC (not final proposal):

    1. NOT clean up the code because of cleaning up :-) Changing "presumable messy" is a risk. Any clean ups are only a side-effects of doing something actually useful. I also highly respect others peoples work in open source so I always have crystal clear reason for any possible delta.
    2. Refactor ioctl signatures and structures to be ABI agnostic.
    3. open(/dev/v4l2-loopback): create a new loopback driver.
    4. V4L2LOOPBACK_CTL_ADD: add a new capture/output device to the loopback driver.
    5. close(/dev/v4l2-loopback): tear down the driver (and obviously also devices it has created).
    6. Define a sane locking model for the internals. I'm not 100% if it works but at least it does not have good coherence. It should be dead obvious how locks work in any driver and should documented in the header (which I'll do).

    For cover letter I'll put an option to rewrite with Rust since it is hardware agnostic (and thus that would make sense in new driver). The first RFC version is in C in order to draw a clear path from OTT, to in-kernel C and finally to Rust.

    I don't care how many iterations it takes as it is just a hobby sudoku for me.

    Phew. Well this was good because 3 weeks gone since last lookup. I'm happy that I have a test program since especially after changing how devices are created and adding necessary anonymous inode shenanigans you need to be able to test those iterations as you go.
    In conversation about 9 months ago from social.kernel.org permalink

    Attachments

    1. Domain not in remote thumbnail source whitelist: git.kernel.org
      V4L2LOOPBACK_CTL_ADD: Reburnish the API - kernel/git/jarkko/linux-tpmdd.git - Linux TPM Device Driver
    2. Domain not in remote thumbnail source whitelist: codeberg.org
      v4l2-loopback-test
      from jarkko
      v4l2-loopback-test
  9. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 06-Feb-2025 07:39:41 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Neal Gompa (ニール・ゴンパ) :fedora:
    • Jarkko Sakkinen
    @Conan_Kudo Bookmarked as source material for the cover letter. But yeah "eventual Rust driver" is my plan with first steps in C. Rewriting a driver takes me a day once I have the design in my head so it is only fun then...
    In conversation about 9 months ago from social.kernel.org permalink
  10. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 06-Feb-2025 07:39:40 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Neal Gompa (ニール・ゴンパ) :fedora:
    • Jarkko Sakkinen
    @Conan_Kudo ... once you get the grip,
    In conversation about 9 months ago from social.kernel.org permalink
  11. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 06-Feb-2025 07:39:39 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Neal Gompa (ニール・ゴンパ) :fedora:
    • Jarkko Sakkinen
    @Conan_Kudo I promised to Steve Klabnik to test out DMA Rust patch set when he was complaining about that in Bluesky.

    The selfish goal in that is that while I do this, that pushes me to rework my BR environment to be "Rust enabled" and testing some actual Rust kernel code probably helps me to draw the mental picture how to make this work in Rust.

    ... and obviously keeping that promise because if I say something, I usually also execute it (with some delays ofc like in this case) :-)
    In conversation about 9 months ago from social.kernel.org permalink
  12. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 06-Feb-2025 07:39:38 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Neal Gompa (ニール・ゴンパ) :fedora:
    • Jarkko Sakkinen
    @Conan_Kudo Hmm... So I have guess what has happened in "meta-level" with previous submissions: if you don't have a smoke test you hang yourself to the existing user space toolchain and the API is really the part here that sucks the most and needs a lot of rework. It's racy and bad. So what I do in meta-level here correctly that I took pause writing kernel code, and made a trivial smoke test program. That's why I believe that I will eventually deliver.
    In conversation about 9 months ago from social.kernel.org permalink
  13. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 06-Feb-2025 07:39:37 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Neal Gompa (ニール・ゴンパ) :fedora:
    • Jarkko Sakkinen
    @Conan_Kudo I should learn to not write a spam thread but yeah for better or worse this is how i aim.
    In conversation about 9 months ago from social.kernel.org permalink
  14. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 30-Jan-2025 23:43:47 JST Jarkko Sakkinen Jarkko Sakkinen
    Removed the malware after one month of suffering.

    #microsoft #malware
    In conversation about 9 months ago from social.kernel.org permalink

    Attachments


    1. https://media.social.kernel.org/media/16d0c956836d7452085c9021ac003170b03dcdb972fbc692b4b2298ea4d3eb5f.png
  15. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Tuesday, 21-Jan-2025 06:03:59 JST Jarkko Sakkinen Jarkko Sakkinen
    https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/ #systemd #tpm #tpm2
    In conversation about 10 months ago from social.kernel.org permalink

    Attachments

    1. No result found on File_thumbnail lookup.
      Bypassing disk encryption on systems with automatic TPM2 unlock | oddlama's blog
      oddlama's personal web page and blog
  16. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Tuesday, 21-Jan-2025 06:03:58 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Lennart Poettering
    • Jarkko Sakkinen
    @pid_eins any thoughts on this one?
    In conversation about 10 months ago from social.kernel.org permalink
  17. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Tuesday, 14-Jan-2025 21:05:18 JST Jarkko Sakkinen Jarkko Sakkinen
    Ubuntu was just what Lenovo puts by default. Caused me almost heart attack 😀 Installing Fedora 41
    In conversation about 10 months ago from social.kernel.org permalink
  18. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Tuesday, 14-Jan-2025 20:53:51 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Jarkko Sakkinen
    • Natanael Copa
    @ncopa It's really my recommended board for testing RISC-V kernel. And the reason for this is that it is aging ;-) Also BuildRoot upstream boots it nicely.
    In conversation about 10 months ago from social.kernel.org permalink
  19. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Tuesday, 07-Jan-2025 07:47:16 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Natanael Copa
    The very first thing with this board is set the pins to SDIO mode ;-) Figure 4-10 in https://doc-en.rvspace.org/VisionFive2/PDF/VisionFive2_QSG.pdf
    In conversation about 10 months ago from social.kernel.org permalink

    Attachments


  20. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Wednesday, 20-Nov-2024 18:36:38 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • Krzysztof Kozlowski
    @krzk lol did not know i was a "tested-by regular" ;-) not in this stats but looked few older and seems to be that it is my the most common list.
    In conversation about a year ago from social.kernel.org permalink
  • Before

User actions

    Jarkko Sakkinen

    Jarkko Sakkinen

    I'm a Linux kernel engineer with the focus in TEE's and confidential computing. Right now I'm enabling Keystone and fTPM for RISC-V Linux

    Tags
    • (None)

    Following 0

      Followers 0

        Groups 0

          Statistics

          User ID
          148578
          Member since
          12 Jul 2023
          Notices
          41
          Daily average
          0

          Feeds

          • Atom
          • Help
          • About
          • FAQ
          • TOS
          • Privacy
          • Source
          • Version
          • Contact

          GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

          Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.