Topic: A C _Either(A, B) type for P0709
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 01 Jun 2018 18:42:49 -0700
Raw View
On Friday, 1 June 2018 13:40:12 PDT inkwizytoryankes@gmail.com wrote:
> One question, do you consider implementation this by sending additional
> return address to function instead of using carry flag?
You're basically talking about setjmp/longjmp, though without a full state
saving and restoring. I think this is not a good idea, as it likely breaks
control-flow execution protection mechanisms, which are being added to CPUs,
compilers and OSes to prevent Return-Oriented Programming.
Then again, *how* the ABI implements _Either is not part of the standard.
That's an ABI's decision.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8087760.pu14tFzVlu%40tjmaciei-mobl1.
.
Author: inkwizytoryankes@gmail.com
Date: Sat, 2 Jun 2018 03:37:34 -0700 (PDT)
Raw View
------=_Part_16782_804169317.1527935854090
Content-Type: multipart/alternative;
boundary="----=_Part_16783_694903098.1527935854090"
------=_Part_16783_694903098.1527935854090
Content-Type: text/plain; charset="UTF-8"
On Saturday, June 2, 2018 at 3:42:53 AM UTC+2, Thiago Macieira wrote:
>
> On Friday, 1 June 2018 13:40:12 PDT inkwizyt...@gmail.com <javascript:>
> wrote:
> > One question, do you consider implementation this by sending additional
> > return address to function instead of using carry flag?
>
> You're basically talking about setjmp/longjmp, though without a full state
> saving and restoring. I think this is not a good idea, as it likely breaks
> control-flow execution protection mechanisms, which are being added to
> CPUs,
> compilers and OSes to prevent Return-Oriented Programming.
>
> Then again, *how* the ABI implements _Either is not part of the standard.
> That's an ABI's decision.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
>
>
>
> Right Intel shadow stack will not work with this, It would need use `jmp`
to return and this indeed will create hole in this mechanism.
OS version could be updated to support this new feature but CPU solution
simply kills it.
BTW im thinking now is there possibility for cases where programs that was
to smart for it own good get break by this CPU protection?
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/adfdbbc8-82a8-45c9-94b8-de8498376a36%40isocpp.org.
------=_Part_16783_694903098.1527935854090
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, June 2, 2018 at 3:42:53 AM UTC+2, Thi=
ago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday, =
1 June 2018 13:40:12 PDT <a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"hYoOnLsoAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">inkwizyt...@gmail.com</a> wrote:
<br>> One question, do you consider implementation this by sending addit=
ional
<br>> return address to function instead of using carry flag?
<br>
<br>You're basically talking about setjmp/longjmp, though without a ful=
l state=20
<br>saving and restoring. I think this is not a good idea, as it likely bre=
aks=20
<br>control-flow execution protection mechanisms, which are being added to =
CPUs,=20
<br>compilers and OSes to prevent Return-Oriented Programming.
<br>
<br>Then again, *how* the ABI implements _Either is not part of the standar=
d.=20
<br>That's an ABI's decision.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br>
<br>
<br></blockquote><div>Right Intel shadow stack will not work with this, It =
would need use `jmp` to return and this indeed will create hole in this mec=
hanism.</div><div>OS version could be updated to support this new feature b=
ut CPU solution simply kills it.</div><div><br></div><div>BTW im thinking n=
ow is there possibility for cases where programs that was to smart for it o=
wn good get break by this CPU protection?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/adfdbbc8-82a8-45c9-94b8-de8498376a36%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/adfdbbc8-82a8-45c9-94b8-de8498376a36=
%40isocpp.org</a>.<br />
------=_Part_16783_694903098.1527935854090--
------=_Part_16782_804169317.1527935854090--
.
Author: Niall Douglas <nialldouglas14@gmail.com>
Date: Sat, 2 Jun 2018 07:32:11 -0700 (PDT)
Raw View
------=_Part_17416_1533015728.1527949931828
Content-Type: multipart/alternative;
boundary="----=_Part_17417_1315451886.1527949931828"
------=_Part_17417_1315451886.1527949931828
Content-Type: text/plain; charset="UTF-8"
>
>
> Then again, *how* the ABI implements _Either is not part of the standard.
> That's an ABI's decision.
>
Absolutely correct. The paper suggests the carry flag, but it's totally up
to the ABI. So long as whatever the compiler does is consistent, it's not
our concern.
Niall
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/64e910e4-5255-44ab-a214-39fa05e6726b%40isocpp.org.
------=_Part_17417_1315451886.1527949931828
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Then agai=
n, *how* the ABI implements _Either is not part of the standard.=20
<br>That's an ABI's decision.
<br>
</blockquote><div><br></div><div>Absolutely correct. The paper suggests the=
carry flag, but it's totally up to the ABI. So long as whatever the co=
mpiler does is consistent, it's not our concern.</div><div><br></div><d=
iv>Niall=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/64e910e4-5255-44ab-a214-39fa05e6726b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/64e910e4-5255-44ab-a214-39fa05e6726b=
%40isocpp.org</a>.<br />
------=_Part_17417_1315451886.1527949931828--
------=_Part_17416_1533015728.1527949931828--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 02 Jun 2018 08:18:29 -0700
Raw View
On Saturday, 2 June 2018 03:37:34 PDT inkwizytoryankes@gmail.com wrote:
> BTW im thinking now is there possibility for cases where programs that was
> to smart for it own good get break by this CPU protection?
I think the technology is opt-in.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3154031.2ilte4zLj3%40tjmaciei-mobl1.
.