1udfx9cf8azi0

> No, because if nbytes > sizeof(*hwrpb), your version causes the kernel to only write part of the buffer, and then when the app accesses fields at the end of the struct, it would read uninitialized data, which is very bad.

> I would agree with you if the kernel had some other mechanism to pass the size of the buffer that was actually filled to the client (like e.g. the read() syscall does) but the getsysinfo() API doesn't return that data, so the kernel must either fill the buffer entirely or return failure.

As you mention, this struct is versioned. Userspace can tell how much of the struct was filled by checking the size field (hwrpb->size).

> But allowing nbytes < sizeof(*hwrpb) has the benefit that the kernel developers can add fields at the end of the struct without breaking backward compatibility with older applications.

That's a related but separate issue. Backward compatibility can be handled by switching on nbytes or by copying fewer bytes with a carefully designed struct. It's not clear that backward compatibility was the original intention of this code, the original intention more seems to be sanitizing tainted input. This struct has not changed in at least 16 years.

> The original less-than check was deemed incorrect

It was only deemed incorrect because of an information leak. Not because it's a valid use-case for user space to copy smaller portions of *hwrpb into user space. https://github.com/torvalds/linux/commit/21c5977a836e399fc71...

That's what the original check is for:

    if (nbytes < sizeof(*hwrpb))

If the buffer isn't large enough to hold *hwrpb, then it already fails. The original check was good, only needed to change the amount of bytes copied to sizeof(*hwrpb).

    if (nbytes < sizeof(*hwrpb))
        return -1;
    
    if (copy_to_user(buffer, hwrpb, nbytes) != 0)
        return -2;

The fix that was done was:

    if (nbytes > sizeof(*hwrpb))

But I think the correct fix is:

    if (copy_to_user(buffer, hwrpb, sizeof(*hwrpb)) != 0)

It never makes sense to copy out of the hwrpb pointer any size other than sizeof(*hwrpb).

Hacker News is not the best crowd for something like this. Everyone here most likely already has their own optimized workflow for something like this, including me.

This is probably best suited for digital creative types who use Windows and Mac and aren't comfortable with the terminal. Animators, illustrators, video editors, 3d artists, music producers, youtubers, streamers, etc.

It's not clear to me that that second group wants something like this. To be fair, from your marketing I have no idea what your software does and I doubt that group would either. I get that you're trying to communicate this is a "universal" file experience but what does that mean in concrete terms? Users shouldn't have to install your software to understand what it does. I also don't see them caring that this is open source or works on Linux.

At this stage I would totally refresh the marketing and optimize it for that second group. Work with a PR person or marketing expert that understands how to concretely and efficiently communicate the value of what you are building to that second group. I would also take down the source repos and discontinue the Linux version (or keep it private for now, until there is demand) to save your team effort at this super early stage.

Good luck

The study did not show that Ivermectin killed SARS-CoV-2 viral particles. Prior to the pandemic, Ivermectin was known to act as an broad anti-viral. This is due to Ivermectin being a protease inhibitor, i.e. it blocks an enzyme from acting. It's important to note that this is the mechanism through which approved anti-virals for SARS-CoV-2, such as Paxlovid, operate.