Live data from Hacker News

-fbounds-safety: Enforcing bounds safety for C

clang.llvm.org

121–129 of 129 posts

Re: -fbounds-safety: Enforcing bounds safety for C

#121
post #35
post #2

I want an OS distro where all C code is compiled this way. OpenBSD maybe? or a fork of CheriBSD? macOS clang has supported -fbounds-safety for a while, but I"m not sure how extensively it is used.

Maybe this: https://fil-c.org/pizlix >Pizlix is LFS (Linux From Scratch) 12.2 with some added components, where userland is compiled with Fil-C. This means you get the most memory safe Linux-like OS currently available. The author, @pizlonator, is active on HN.

I'm aware of Pizlix - it's a good project/idea that needs to go mainstream; as you mention, memory safety is currently limited to userland (still a huge improvement over traditional unsafe userland.)

Note also that it uses fil-c rather than clang with -fbounds-safety. I believe fil-c requires fewer code changes than -fbounds-safety.

Re: -fbounds-safety: Enforcing bounds safety for C

#122
post #30

Has any progress been made on this? I remember seeing this proposal 3 or 4 years ago but it looks like it still hasn't been implemented. It's a shame because it seems like a useful feature. It looks like Microsoft has something similar ( https://learn.microsoft.com/en-us/cpp/code-quality/understan... ) but it would be nice to have something that worked on other platforms.

As I and others noted below, it is included in Apple's clang version, which is what you get when you install the command line tools for Xcode. Try something like:

    clang -g -Xclang -fbounds-safety program.c
Bounds check failures result in traps; in lldb you get a message like:

    stop reason = Bounds check failed: Dereferencing above bounds

Re: -fbounds-safety: Enforcing bounds safety for C

#124
post #3
post #2

I want an OS distro where all C code is compiled this way. OpenBSD maybe? or a fork of CheriBSD? macOS clang has supported -fbounds-safety for a while, but I"m not sure how extensively it is used.

>I want an OS distro where all C code is compiled this way. You first have to modify "all C code". It's not just a set and forget compiler flag.

Indeed. I still want it.

Re: -fbounds-safety: Enforcing bounds safety for C

#125

Earlier quoted context omitted.

EMV terminals are not under daily cybersecurity attack - you need to have physical access unless you designed your system weirdly. You probably had loads of vulnerabilities. But also depending on when you did it, all you had to process was a bar code which is also isn’t some super complicated task. I’m not trivializing the safety of munitions. I’m attempting to highlight that safety and stability in a munitions conte…

> EMV terminals are not under daily cybersecurity attack - you need to have physical access unless you designed your system weirdly. They are under daily attack - in public, at tills, operated by minimum-wage earners. > You probably had loads of vulnerabilities. Sure. Hundreds of thousands of terminals sitting in the field, networked, under the control of minimum wage employees, each holding credit card details for h…

Physical attacks are difficult to pull off at scale, especially anonymously. There’s a huge evidence trail linking the people involved to the scheme. And a device being in the hands of a minimum wage employee is very different from a bored and talented and highly skilled person probing your software remotely. Now who’s naive?

As for certification and it being difficult, what does that have to do with the process of bread in Paris? Unless you’re somehow equating certification with a stamp of vulnerability imperviousness in which case you’re seeing your own naivete instead of in others. Btw, Target was fully certified and fully had their payment system breached. Not through the terminals but through the PoS backend. And as for “but you’re here living and breathing”, there’s constant security breaches through whatever hole, memory safety or otherwise. Persistent access into the network is generally only obtainable through credential compromise or memory safety.

> When did you meet this person?

You. You’re here claiming that memory safety issues are statistical noise yet every cloud software I’ve seen deployed regularly had them in the field, sometimes even letting a bad one through to canary. And memory safety issues persisted despite repeated attempts to fix issues and you couldn’t even know if it was legitimately an issue or just a HW flaw due to being deployed at scale enough that you were observing bad components. It’s a real problem and claiming it’s statistical noise ignores the consequences of even one such issue being easily accessible.

Re: -fbounds-safety: Enforcing bounds safety for C

#126

Earlier quoted context omitted.

> EMV terminals are not under daily cybersecurity attack - you need to have physical access unless you designed your system weirdly. They are under daily attack - in public, at tills, operated by minimum-wage earners. > You probably had loads of vulnerabilities. Sure. Hundreds of thousands of terminals sitting in the field, networked, under the control of minimum wage employees, each holding credit card details for h…

Physical attacks are difficult to pull off at scale, especially anonymously. There’s a huge evidence trail linking the people involved to the scheme. And a device being in the hands of a minimum wage employee is very different from a bored and talented and highly skilled person probing your software remotely. Now who’s naive? As for certification and it being difficult, what does that have to do with the process of b…

> You. You’re here claiming that memory safety issues are statistical noise yet

Claiming that the exploit rate percentage is statistical noise is different from claiming that it's a safe language.

Looks like you have a premade argument to argue.

You haven't answered my question, though: Have you used LLMs to generate any code for yourself?

Re: -fbounds-safety: Enforcing bounds safety for C

#127
post #119

Earlier quoted context omitted.

Even Fujitsu has been moving away from SPARC. What was the last SPARC Fujitsu designed?

What matters is that they are still selling them.

Kind of. Atos still sell GCOS/GECOS mainframes, but they are Xeon boxes running emulators. Same with Unisys and MCP (which was written in an ALGOL and had bounds checked IIRC).

Re: -fbounds-safety: Enforcing bounds safety for C

#128
post #82
post #62

Earlier quoted context omitted.

Might as well not even talk about anything with the Oracular kiss of death.

Not everyone suffers from Oracle phobia. Some of us actually do read licenses before using products. Also the FAANG are hardly any better only because they spew cool marketing stuff like do no evil.

FAANG won’t send auditors to check whether your are in compliance with what license you paid for. Per core/socket licensing is one of the reasons POWER can do SMT/8.

Re: -fbounds-safety: Enforcing bounds safety for C

#129

Earlier quoted context omitted.

> you need some part of your stack to be unexploitable. Kernel level process isolation is extremely robust. > If your attitude is that getting exploited doesn’t matter because your software is unprivileged It’s not that exploits doesn’t matter. It’s that process architecture is a stronger form of guarantee than anything provided by a language runtime. I agree that the place where rust is most beneficial is for progra…

How can process architecture be a stronger guarantee than anything provided by a language runtime when it is enforced by software written in a language? You have a process receiving untrusted, potentially malicious input from the outside. If there’s an exploit then an attacker can potentially take control of the process. Your process is isolated, that’s good. But it can still communicate with other parts of your syst…

> How can process architecture be a stronger guarantee than anything provided by a language runtime when it is enforced by software written in a language?

Please learn more about this topic. You don't understand OS security models.

Post reply on HN