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 Saturday, 13-Jun-2026 01:44:45 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • James Morris
    @jmorris With coding agents, we're in a situation where we have bad behaving processes by design. So they need sandboxing, but it is in the level of preventing them going "over the top". I.e. a different scenario where you have actor that proactively tries to exploit your system :-) What I'm trying to do is to get a single binary that can address that level of brickwalls for agents, with a cross-os compatible policy - not to be the "IMAX prison".

    To make something meaningful I thought that being Anthropic policy format driven but with a more serious sandbox implementation is pretty good way to move forward on hardening this ecosystem.
    In conversation about 5 days ago from social.kernel.org permalink
  2. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 11-Jun-2026 02:20:44 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • James Morris
    @jmorris Thanks James :-) Your endorsement means a lot to me!
    In conversation about 7 days ago from social.kernel.org permalink
  3. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 11-Jun-2026 02:20:43 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • James Morris
    • Jarkko Sakkinen
    @jmorris Actually I love whenever I have a chance to do something with Win32 API :-) It's well documented and well engineered and usually solutions are not a dissapointment. I think overall it is an engineering achievement having been relevant and backwards compatible such a long span of time.
    In conversation about 7 days ago from social.kernel.org permalink
  4. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Thursday, 11-Jun-2026 02:20:43 JST Jarkko Sakkinen Jarkko Sakkinen
    in reply to
    • James Morris
    • Jarkko Sakkinen
    @jmorris And despite being critical about Microsoft as a company, Landstrip also proactively supports Win32 security mechanisms. Not many of these sandboxes do. macOS, Linux and Windows are all equally supported.
    In conversation about 7 days ago from social.kernel.org permalink
  5. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Wednesday, 10-Jun-2026 00:40:08 JST Jarkko Sakkinen Jarkko Sakkinen
    Landstrip 0.9.6 implements the Unix domain socket policy for Linux with LANDLOCK_ACCESS_FS_RESOLVE_UNIX, and falls back on using seccomp policy if the interface is not available.

    Unix domain socket Landlock LSM policies are an upcoming feature in Linux 7.1.

    https://crates.io/crates/landstrip/0.9.6
    https://lore.kernel.org/linux-security-module/20260327164838.38231-1-gnoack3000@gmail.com/
    In conversation about 8 days ago from social.kernel.org permalink

    Attachments


    2. No result found on File_thumbnail lookup.
      [PATCH v8 00/12] landlock: UNIX connect() control by pathname and scope - Günther Noack
  6. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Wednesday, 10-Jun-2026 00:39:38 JST Jarkko Sakkinen Jarkko Sakkinen
    Landstrip is sort of done or I don't know what to do with it further :-)

    Fix bugs and improve output returned to coding agent or other host I guess.

    I think the learning for me from this was that tool command would work pretty well in non-AI situations. E.g., it is great for executing external commands in a file manager.

    And Anthropic's description of architecture is well-made and I get it. The problem is that neither them nor their world most dangrous AIs are great at writing code, so their implementation is a shadow of the spec. This is why never trust AI researchers when they say anything about code.
    In conversation about 8 days ago from social.kernel.org permalink
  7. Embed this notice
    Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Friday, 20-Mar-2026 09:20:10 JST Jarkko Sakkinen Jarkko Sakkinen
    OMG I found an *active* GUS fork of ao486:

    https://github.com/xolod79/ao486_MiSTer/tree/GUS

    SB16 is a CPU hog with worst imaginable sound.

    486 SX-33 + 16 MiB + GUS is ideal :-) GUS is a legend, love it.
    In conversation about 3 months ago from social.kernel.org permalink

    Attachments

    1. Domain not in remote thumbnail source whitelist: opengraph.githubassets.com
      GitHub - xolod79/ao486_MiSTer at GUS
      ao486 port for MiSTer. Contribute to xolod79/ao486_MiSTer development by creating an account on GitHub.
  8. 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 10 months ago from social.kernel.org permalink
  9. 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 10 months ago from social.kernel.org permalink
  10. 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 10 months ago from social.kernel.org permalink
  11. 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 10 months ago from social.kernel.org permalink
  12. 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 10 months ago from social.kernel.org permalink
  13. 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 10 months ago from social.kernel.org permalink
  14. 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 Thursday, 06-Feb-2025 07:39:43 JST from social.kernel.org permalink
  15. 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 Thursday, 06-Feb-2025 07:39:42 JST 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
  16. 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 Thursday, 06-Feb-2025 07:39:41 JST from social.kernel.org permalink
  17. 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 Thursday, 06-Feb-2025 07:39:40 JST from social.kernel.org permalink
  18. 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 Thursday, 06-Feb-2025 07:39:39 JST from social.kernel.org permalink
  19. 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 Thursday, 06-Feb-2025 07:39:38 JST from social.kernel.org permalink
  20. 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 Thursday, 06-Feb-2025 07:39:37 JST 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
          48
          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.