Ristovski
Joined 10 years ago
Karma
157
Submissions
53
Member since
Nov 6
https://ristovski.github.io/
View on Hacker NewsRecent submissions
Comment · 1 month ago
> In midvalues you will see a slight dot pattern.
Is this not simply some sort of watermark instead of an artifact?
Comment · 10 months ago
A similar tool to this (includes interactive TUI) is https://github.com/wagoodman/dive
Comment · 2 years ago
FastEndpoints is nice but they don't seem to plan on supporting NativeAOT anytime soon https://github.com/FastEndpoints/FastEndpoints/issues/565#is....
Comment · 2 years ago
For those wondering what the exact attack vector is, the AMD advisory has some details:
> Improper validation in a model specific register (MSR) could allow a malicious program with ring0 access to modify SMM configuration while SMI lock is enabled, potentially leading to arbitrary code execution. [0]
[0]: https://www.amd.com/en/resources/product-security/bulletin/a...
Comment · 2 years ago
> nvtop stands for NVidia TOP, a (h)top like task monitor for NVIDIA GPUs.
The Github repo[0] disagrees: > NVTOP stands for Neat Videocard TOP, a (h)top like task monitor for GPUs and accelerators.
I have been using this on AMD for a long time now.
Comment · 3 years ago
One of the major downsides of the Hexagon DSP is that its near impossible to actually run anything on it unless you somehow get your hands on an unprovisioned/unlocked SoC.
The HLOS (High-level OS) running on the Hexagon requires every "applet" to be signed by either the Qualcomm root cert or the OEMs cert. Usually, every phone has a set of generic Hexagon applets (or "skeleton libs") that are provided and signed by the OEM, which seem to be freely usable to offload some computational work to the DSP (mainly FastCV et al - https://developer.qualcomm.com/sites/default/files/docs/qual...). Those of course come with their own bugs: https://research.checkpoint.com/2021/pwn2own-qualcomm-dsp/
On some older SoCs, you were able to use a TOCTOU (Time of check to time of use) exploit to bypass the signature check by patching the applet loader shim in-memory, once it itself got authenticated: https://github.com/geohot/freethedsp/ (I have personally ported this to the msm8953, and it seems to work)
Comment · 3 years ago
IIRC there is some rudimentary AVR5 support in https://github.com/ZigEmbeddedGroup/microzig (https://github.com/ZigEmbeddedGroup/microzig/blob/main/src/m...)
Comment · 3 years ago
I believe that should be possible, yes.
Here is an interesting paper about Computrace: https://www.coresecurity.com/sites/default/files/private-fil...
Comment · 3 years ago
For anyone interested in efivars, I have an old blog post about essentially the same thing but going a bit more in-depth, including how to actually modify the efivar entries: https://ristovski.github.io/posts/inside-insydeh2o/
Comment · 4 years ago
An interesting comment made in the Phoronix forums:
> My theory is that fixing the Spectre V2 vulnerability on a hardware level would lead to fundamental architecture changes that AMD is not willing to make, because it may add so much more complexity to the architecture or it may just be too unconvenient. They probably realized that optimizing the code paths that the Linux kernel utilizes on the default mitigations mode is faster, simpler and it may involve less deeper changes, while still being secure.
> As far as I know, pretty much every CPU architecture that implements speculative execution is vulnerable to some version of Spectre, so note that this is not a fundametal flaw of AMD64.