Date: Fri, 29 Nov 2024 08:41:08 -0800
On Friday 29 November 2024 01:53:51 Pacific Standard Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> On Fri, Nov 29, 2024 at 6:53 AM Thiago Macieira wrote:
> > Then I don't see the point of having those functions in the Standard, if
> > they can't be used at all times.
>
> Sounds like you take the designers of Control Flow Enforcement as some
> sort of authority.
Yes. This functionality is already in the market and has been for 2 years (my
laptop has it), the hardware functionality cannot be changed any more.
You can opt out of it for your binaries, in debug-mode, if you want. But the
point stands: if this can't be used by a sufficiently large code base in many
different circumstances, it shouldn't be in the standard.
> I mean, I can devise some sort of programming
> scheme today that breaks certain functionality, but I wouldn't argue
> that the functionality I'm breaking is okay to be broken simply
> because of the aims of the scheme I designed.
Correct, but that's not the case here, is it?
Return-oriented programming has been a vector of attack on software that
needed mitigating. It has practically never been used for anything but
attacks, so forcing the CPU to deny that is a gain. This feature was designed
by hardware people in consultation with compilers and runtime developers
(including Microsoft) and a cost-benefit analysis was also made.
When you achieve the same, we will listen to you.
This case is very similar to encryption: by using it, you break the ability to
modify the packets on the fly, to insert or correct something the sender failed
to do or remove something it can't understand. This technique also has a name:
man-in-the-middle attack.
> > In fact, you should just write what you can as a library and make it
> > available for others to use, and the rest you should contribute as
> > intrinsics to compilers willing to take them. Get some experience first
> > in the use, the usefulness, and implementation limitations before
> > thinking of standardisation.
> Some of them need compiler support (aka 'compiler magic').
Like I said, contribute those to your compiler of choice as intrinsics.
Gotham via Std-Proposals wrote:
> On Fri, Nov 29, 2024 at 6:53 AM Thiago Macieira wrote:
> > Then I don't see the point of having those functions in the Standard, if
> > they can't be used at all times.
>
> Sounds like you take the designers of Control Flow Enforcement as some
> sort of authority.
Yes. This functionality is already in the market and has been for 2 years (my
laptop has it), the hardware functionality cannot be changed any more.
You can opt out of it for your binaries, in debug-mode, if you want. But the
point stands: if this can't be used by a sufficiently large code base in many
different circumstances, it shouldn't be in the standard.
> I mean, I can devise some sort of programming
> scheme today that breaks certain functionality, but I wouldn't argue
> that the functionality I'm breaking is okay to be broken simply
> because of the aims of the scheme I designed.
Correct, but that's not the case here, is it?
Return-oriented programming has been a vector of attack on software that
needed mitigating. It has practically never been used for anything but
attacks, so forcing the CPU to deny that is a gain. This feature was designed
by hardware people in consultation with compilers and runtime developers
(including Microsoft) and a cost-benefit analysis was also made.
When you achieve the same, we will listen to you.
This case is very similar to encryption: by using it, you break the ability to
modify the packets on the fly, to insert or correct something the sender failed
to do or remove something it can't understand. This technique also has a name:
man-in-the-middle attack.
> > In fact, you should just write what you can as a library and make it
> > available for others to use, and the rest you should contribute as
> > intrinsics to compilers willing to take them. Get some experience first
> > in the use, the usefulness, and implementation limitations before
> > thinking of standardisation.
> Some of them need compiler support (aka 'compiler magic').
Like I said, contribute those to your compiler of choice as intrinsics.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-11-29 16:41:13