alschwalm

LD_AUDIT is another one worth knowing about (though I admittedly use it less often than LD_DEBUG) https://man7.org/linux/man-pages/man7/rtld-audit.7.html

Yeah, that was my assumption as well, good to have it confirmed though. Thanks for your excellent work on bytehound!

Interesting approach. How is performance compared to something like https://github.com/koute/bytehound

Looks nice! Kind of reminds me of binwalk: https://github.com/ReFirmLabs/binwalk

I'm curious how the benchmarks are for Btrfs on 6.1, given the improvements that (I think) landed in it: https://www.phoronix.com/news/Linux-6.1-Btrfs

Looks like it: https://docs.hylang.org/en/stable/api.html#let

I recall hearing it had been implemented a while back, seems like it's true!

I've also hit this issue. About a year ago I made an effort to use blink, but after a bit of work I recall essentially discovering that any support was effectively abandoned. I wish they would remove the note in the FAQ about supporting multiple engines, as it doesn't seem to be the case.

It is definitely also worth mentioning the now-stabilized procedural macros [1] (unless I missed where they are described). proc macros power some of the more complex macro usage in the rust ecosystem (like rocket and actix-webs router macros, any sort of custom derive, etc).

[1]: https://doc.rust-lang.org/reference/procedural-macros.html

  Location: Huntsville, AL, USA
  Remote: Yes
  Willing to relocate: No
  Technologies: Rust, C, C++, python, Xen, KVM, hypervisor development, Linux kernel development, IDA Pro
  Résumé/CV: https://alschwalm.com/resume/resume.pdf
  Email: adamschwalm@gmail.com

I am currently a technical lead for a hypervisor product. My career has primarily been focused on low-level security and performance for quasi-embedded systems, but I also have experience with reverse engineering and machine learning applications. I am passionate about using modern technologies like rust to improve the security posture of products and would like to continue to work in that area.

https://github.com/alschwalm/transient - A tool for quickly creating short-lived virtual machines for doing kernel or hypervisor testing, made after I got tired of dealing with races and general complexity from libvirt-based tools.

VirtIO is very usable via QEMU, without libvirt (naturally, because in the configuration described in the article, libvirt is just calling QEMU). It is usually as simple as `qemu-system-x86_64 -drive file=/path/to/my/disk,if=virtio`.

I'm concerned about self hosting a service like this as well, so I put mine behind an nginx reverse proxy that requires a client cert for auth. That way, an attacker won't even be able to reach the bitwarden server to try to get in (unless there's a vulnerability in nginx).

We were actually previously using vagrant (-libvirt) for our CI, but moved away from it to this because vagrant does not seems to work very reliably when run in parallel. For example image downloading doesn't seem to have a filesystem lock, so one would succeed and the others failed.

In general, we wanted to be able to spin up our test VMs under docker containers to eliminate issues with differences between our CI shell-runners. Using libvirt based tooling makes that pretty hard. Calling to qemu directly, on the other hand, makes this easy.

There are some other benefits as well such as having direct console access which is not provided by vagrant, but can be very useful for kernel tests.

There is a typo under the 'optimal performance' section. "A zero cost _abstractoin_ ought..."

Shameless plug: If you enjoy that, you may like a version that I made that sinks the audio and transcripts with puppies[1], available here: https://www.youtube.com/channel/UCn1ibFnn3NcXjQHY47o0yWg/vid... Though this particular case is not available yet.

[1]: The idea was originally inspired by Last Week Tonight, I just automatically generate them.

Wow this is really detailed. Thanks!

The keyboardio is the only keyboard I know of that has the palm keys, but I've been interested in buying or making a keyboard that has them. Any writup on your build?

The article on the "hitchhiker's paradox" that this links to made this much more clear to me (as well as being shorter): https://the8layers.com/2016/10/30/how-long-will-you-wait-hit...

I tend to like https://www.draw.io/ for that sort of thing (there is a chrome app if you want to run offline).

Wait, what? I know that hw accelerated video decoding is generally not available on linux chrome, but I'm pretty sure that lots of other things are. From my chrome://gpu

    Canvas: Hardware accelerated
    CheckerImaging: Disabled
    Flash: Hardware accelerated
    Flash Stage3D: Hardware accelerated
    Flash Stage3D Baseline profile: Hardware accelerated
    Compositing: Hardware accelerated
    Multiple Raster Threads: Enabled
    Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
    Rasterization: Software only. Hardware acceleration disabled
    Video Decode: Software only, hardware acceleration unavailable
    Video Encode: Software only, hardware acceleration unavailable
    WebGL: Hardware accelerated
    WebGL2: Hardware accelerated

But this is with an integrated GPU, so maybe things are different for discrete cards.

There is a description of the problem here: https://github.com/hylang/hy/issues/1056

I think it really comes down to python having limited scoping capabilities (I think you can only really make new scopes with function declarations), this can maybe be hacked around, but at too high a performance cost to be usable.

Hy is a great project. One unfortunate thing, though, is that no one has been able to successfully implement `let`, which makes writing idiomatic lisp almost impossible. I'm curious if anyone can actually prove it can't be done or is just very difficult (or too slow to be useful).

The problem I tend to think of is that they store the urls in the clear, so an attacker (who can bypass SSL) will potentially be able see which sites you have passwords saved for. There's a writeup that mentions it here: http://www.martinvigo.com/even-the-lastpass-will-be-stolen-d...

Presented graphically here: http://i.imgur.com/xMyblyM.png

Though the graphic, like this post, doesn't talk much about elf segments.

Maybe a reference to the protagonist from Hackers: http://www.imdb.com/title/tt0113243/

Author here. This is a pretty introductory post, but I wanted to do something basic before going more in-depth. The next part (hopefully!) will contain a tool release (in the form of an IDA plugin) for automating things.

It is probably also worth noting that there is a good optimization opportunity when using noexcept move constructors. std::vector::push_back has a strong exception safety guarantee, so the normal behavior when the vector is at capacity is to create a new buffer and copy construct each item in the vector into it. If the copy constructor of any element throws, the original buffer is still in a coherent state.

If the type has a move constructor that is noexcept, then each element can be move-constructed without fear of an exception occurring. For many types, this is vastly more efficient.

I'm a fan of the graphics as well. Does anyone know what they were made with? I see the org-mode reference at the bottom of the page, but I assume that doesn't include the images.

Anyone have any thoughts on why removing the superfluous assignments had such a dramatic effect? That was a surprise to me.

I think just DIE's would be sufficient, definitely don't need accelerator table stuff.

I've actually considered looking more at the LLVM dwarf writing components. Do you have any experience with that?