0:00

Episode 396 of CPPcast,

0:02

recorded 28th of March,

0:04

2025. of

0:09

CPP

0:12

cast

0:15

recorded

0:18

28th

0:21

of March

0:24

2025. And

0:27

a leaked

0:31

message by

0:34

Biena Strostrup.

0:37

Then we

0:39

are joined by

0:42

Louis Dion. Louis

0:45

talks to us

0:48

about standard library

0:50

hardening. I'm your host

0:53

Timo Dumle joined by

0:55

my co-host Phil Nash.

0:58

Phil, how you doing

1:00

today? I'm alright, Tima, how you doing? I'm

1:02

all right. It's a bit hectic right now.

1:05

I just came back from a visit to

1:07

my hometown and in a couple days I'm

1:09

going to the UK to where you are

1:11

now to attend ACCU and I just have

1:13

a couple days in between. There's lots

1:15

of family stuff going on, so it's

1:17

a bit hectic and rushed at the moment,

1:20

but otherwise I'm doing great. Yeah, how are

1:22

you Phil. It sounds like a quiet

1:24

time by your standards, but yeah.

1:26

Yeah, no, it's pretty hectic for me

1:28

as well, obviously, preparing for ACCU.

1:30

I haven't even started preparing my

1:33

talk I've got yet, but... Oh, yeah,

1:35

I haven't started preparing my talk either,

1:37

and I think mine is on the

1:39

first day, isn't it? Last day, I

1:41

think, but... We'll talk about that next

1:43

week. So, Phil, just to remind or

1:45

read us, you are actually the event

1:47

manager of that conference, right? That is

1:50

correct, yes. All right. So yeah, I

1:52

can imagine, I have organized conferences before,

1:54

so I can imagine how much work

1:56

that is. So yeah, thank you very much

1:58

for doing all of that. yeah, throwing

2:00

together an amazing conference and juggling it

2:03

with all the other stuff. So. Yeah,

2:05

well I hope to, hope to see

2:07

a few of our listeners there as

2:09

well. It's a great conference. If you've

2:11

never been to ACCU, I can highly

2:14

recommend it and we will all be

2:16

there. All right. So, at the top

2:18

of every episode, we'd like to read

2:20

a piece of feedback and this time

2:23

we actually got quite a lot of

2:25

feedback. We got quite a lot of

2:27

emails from people telling us that they're

2:29

really happy that the show is back

2:31

because we've... We were on hiatus for

2:34

something like four months and then we

2:36

came back two weeks ago and now

2:38

we're doing we're back to our usual

2:40

every two weeks schedule and we got

2:42

a lot of feedback that people are

2:45

happy with that. So that's really hard

2:47

warming. Thank you so much for this

2:49

feedback. It's a good feeling to know

2:51

that that people are listening to the

2:54

show and they care about the show.

2:56

So I just want to read one

2:58

of those emails because obviously we can't

3:00

read all of them. There were quite

3:02

a few more but this one is

3:05

by Yurg and Yurg and Yurg says.

3:07

Hi, this is just my part of

3:09

reducing the spam ratio in your email,

3:11

Sminy Face. Thank you, York. I really

3:13

appreciate that. I have nothing in particular

3:16

to say except that it's great to

3:18

hear your back and well. I just

3:20

realized how out of touch I am

3:22

or was with the latest developments because

3:25

your podcast is apparently my primary source

3:27

of info on C++. Yeah, it's a

3:29

bit scary as well. It is. I

3:31

hope we're doing a half decent job,

3:33

but yeah, this is part of the

3:36

fun. So thank you very much, York,

3:38

and everybody else for listening. And please

3:40

keep sending us emails. We'd like to

3:42

hear your thoughts about the show. And

3:45

while you can still reach us on

3:47

X, Mastodon, and LinkedIn, the best way

3:49

to give us feedback is by email

3:51

at CPPcast.com. Joining us today is Louis

3:53

Dion. So Louis has been doing CIPAS

3:56

for a while. In the past he's

3:58

done a lot of metaprogramming with libraries

4:00

like Busthana and typewriter with libraries like

4:02

Dino. And he now works at Apple

4:04

where he is the code owner of

4:07

LipC++ Plus. And if people don't know

4:09

what that is, that is the standard

4:11

library implementation of NLVM, the one that

4:13

comes with a clang compiler. So that

4:16

is a pretty big deal. And Louis

4:18

is an active superstar standard committee member,

4:20

and recently has been focusing on making

4:22

existing CSBAS code safer by leveraging LipCPASPoss's

4:24

position in the stack to deliver incremental

4:27

improvements to large amounts of code. Well

4:29

Louis that sounds amazing so welcome again

4:31

to the show and I'm really looking

4:33

forward to talking to you about all

4:35

of this. Yeah I'm looking forward to

4:38

talking about that as well but I

4:40

want to pull out one thing from

4:42

the bio that we're not going to

4:44

be talking about so now's my only

4:47

chance because you did mention that you

4:49

you worked on Dino back in the

4:51

day I know it's been a few

4:53

years but I've got a bit of

4:55

an interesting type of erasure at the

4:58

moment myself so. Well, one of the

5:00

things I've been thinking about is how

5:02

reflection, if and when we actually get

5:04

it in C++, may impact type of

5:06

razor labors because it can be a

5:09

bit awkward to use. It is so

5:11

awkward, right? So I think it is

5:13

actually one of the biggest change changers

5:15

for type of razor. I remember, like,

5:18

even back in the days when I

5:20

got involved in reflection a little bit,

5:22

I think it might have been some

5:24

Isikwami thing. I gave a presentation where

5:26

I basically used the... Reflection facilities back

5:29

then, you know, which were completely different

5:31

from the ones that were standardizing right

5:33

now, to show how we could re-implement

5:35

Dino in just a few lines, right?

5:37

It was like, it fit like on

5:40

a couple of slides briefly. So it's

5:42

going to be a game changer, you

5:44

know, it's going to be a lot

5:46

simpler, to implement, it's going to be

5:49

better, you know, easier to use. Yeah,

5:51

it is going to be a game

5:53

changer for this specific area of C++.

5:55

I think that's. Nice, you know, foreshadowing

5:57

the, what are you looking forward to

6:00

in C++, we'll ask a bit later.

6:02

All right, yeah, we'll get more into

6:04

that later. So, Louis, hold on, because

6:06

before we get to you, we have

6:08

a couple of news. articles to talk

6:11

about. But feel free to comment in

6:13

any of these, of course. So today

6:15

I got three of them. The first

6:17

one actually has to do with a

6:20

conference that just ended. And it's not

6:22

one of those seabasasas conferences that we

6:24

usually talk about here on the show,

6:26

but it is one that a lot

6:28

of people attend and that is interesting,

6:31

which is the game developers conference. GDC

6:33

2025. It's just wrapped up. And in

6:35

connection with that conference, there is actually

6:37

a new blog post. No, I don't

6:39

like look into it every day, but

6:42

like every once in a while there's

6:44

stuff in there that I'm like, oh

6:46

yeah, this could be really interesting to

6:48

you, quite a lot of people. So

6:51

this one is called How Build Insights,

6:53

Reduced Call of Duty, Modern Warfare Two's,

6:55

built times by 50%. So that's a

6:57

pretty big number. So, so this blog

6:59

post is mostly about seepasas built insights,

7:02

which is a tool that ships with

7:04

Visual Studio, if I've not mistaken. And

7:06

it's about optimizing build times as the

7:08

title says, which is a huge deal

7:10

for video game people, but also for

7:13

many other CSAs developers. So the block

7:15

reads a little bit like a marketing

7:17

sales pitch for that product, but it's

7:19

still really interesting and I recommend you

7:22

read it. The approach roughly is that

7:24

they measure kind of like the performance

7:26

of the build using VCperf and MS

7:28

build and like a bunch of Microsoft

7:30

tools. They analyze the resulting profile, they

7:33

use Windows Performance Analyzer, they find inefficiencies

7:35

in the build process, and then they

7:37

implement optimization based on what they found

7:39

and they remeasure and then keep doing

7:42

that. The article goes into quite a

7:44

lot of detail about what they found

7:46

and what they've done to cut the

7:48

compile times on this really big game

7:50

by quite a lot. And there were

7:53

three of them that I thought, that's

7:55

really interesting stuff, that's kind of cool.

7:57

One of them was that they found

7:59

force inlining which I think a lot

8:01

of game people and probably a lot

8:04

of other people they just slapped horse

8:06

in line all over their code. That

8:08

was actually significantly increasing compilation time and

8:10

that was primarily due to nested calls

8:13

on forced inline functions. The one function

8:15

in particular had 13,700 force inline calls,

8:17

just one function, because there was like

8:19

a combinatorial explosion in call counts. And

8:21

that resulted in over a minute of

8:24

extra compile time, just that one function

8:26

being forced in line to like thousands

8:28

of times. Then the other one was...

8:30

There was a single function with particularly

8:32

large dynamic initializers that were somehow triggered

8:35

by it and that was adding millions

8:37

of unnecessary operations and that was slowing

8:39

down a whole program analysis which is

8:41

something that you do after you compiled

8:44

your individual like transition units and that's

8:46

quite important to get more optimization and

8:48

make the game faster and and that

8:50

single function was slowing the whole program

8:52

analysis down by nine fold like nine

8:55

times. So that added another three minutes

8:57

to the build. They got rid of

8:59

that. And the last one I thought

9:01

was my favorite one. They actually found

9:03

issues with Visual Studio itself. They found

9:06

that Link Time Code Generation, which is

9:08

like one of the built steps that

9:10

takes up a lot of time, was

9:12

using a hash table implementation that wasn't

9:15

very well suited for the tasks and

9:17

created lots of cash misses. And

9:19

so those cathemas were again slowing

9:21

down the build by quite a

9:23

lot. And so then they actually,

9:25

you know, they actually have to

9:28

go and like fix the build

9:30

tools as well, not just to

9:32

optimize the code. So I thought

9:34

that was a really interesting kind

9:36

of thing where you start optimizing

9:38

your code, but also optimizing your

9:40

tools for build times. Yeah. Actually,

9:42

a fun fact about this year.

9:44

Several years ago, LibC plus was

9:46

using the always in line attribute

9:48

on almost all of its functions.

9:50

And we got rid of that

9:53

now, right? And the reason was

9:55

basically to like control the some

9:57

ODR. aspects of the library, it

9:59

was to avoid like OBR violations.

10:01

So we, yeah, it's kind of

10:03

a complicated story. We'll talk about

10:05

that later, I'm sure. Yeah, I

10:07

think we might, yeah. But yeah,

10:09

so we got rid of that

10:11

now and like we saw like

10:13

improved, you know, the compiler is

10:15

able to optimize better, better code

10:18

side, much better debugging experience as

10:20

well. So yeah, it's. You know,

10:22

it's something that we did on

10:24

all of our functions. It's kind

10:26

of, it was kind of surprising

10:28

to find out about that first.

10:30

That's fun. So, so always in

10:32

line in, in clang, is that

10:34

the same as force in line

10:36

in Microsoft? I guess, I guess

10:38

it is. Yes, it is. I

10:40

actually don't know for sure. Yeah,

10:43

right. Yeah, well, cool. So the

10:45

second news item I have is

10:47

a GitHub issue that has been

10:49

opened against the C++ bus core

10:51

guidelines, which, you know. a lot

10:53

of the community uses for writing

10:55

C++. And it's like essentially like

10:57

a pull request against those guidelines.

10:59

To remove the recommendation that we

11:01

should use dot H as the

11:03

file extension for C++ header files.

11:05

And there is a recommendation that

11:08

we should use something else instead

11:10

such as dot HPP. There's a

11:12

bunch of motivation given dot H

11:14

clashes with C. So dot H

11:16

is supposed to be for C

11:18

headers and not for C++ headers.

11:20

And CSRs headers are typically not

11:22

usable as C headers. So there's,

11:24

you know, according to the person

11:26

behind this value in saying this,

11:28

this is a CSRs header, this

11:30

is not a C header in

11:33

a way that, you know, people

11:35

and tools can immediately see. And

11:37

also, use of dot H is

11:39

popular, but it's not actually universal.

11:41

There are code bases that do

11:43

use dot HPP or dot HXX

11:45

or something else, which I can

11:47

confirm, like I've worked on such

11:49

code bases, I'm sure, so have

11:51

you. Actually, it is in our

11:53

community interest to actually differentiate and

11:55

distinguish people as lost from sea

11:57

because especially for example with this

12:00

whole recent safety and security discussion

12:02

that been going on for the

12:04

last couple years. Security people really

12:06

like throwing a CNC assassin to

12:08

one bucket and it's always like

12:10

they always talk about C slash

12:12

C++ and you know like making

12:14

a clear difference just by how

12:16

we choose our file extensions you

12:18

know my may help actually get

12:20

the message across that those are

12:22

actually different programming languages. which that

12:25

one like is marked as a

12:27

more minor consideration but compared to

12:29

the others but like yeah it's

12:31

it's interesting so that suggestion generates

12:33

generated actually quite a lot of

12:35

discussion on read it I think

12:37

in the past there was also

12:39

a big threat about this in

12:41

stack overflow and in other places

12:43

it is quite contentious I don't

12:45

know what the resolution will be

12:47

but I'm curious what you think

12:50

about it I tend to agree

12:52

with one of the comments that

12:54

it's a nice idea but this

12:56

ship has sailed and I think

12:58

it's too late to to run

13:00

it back in. Like even if

13:02

we make the convention now I

13:04

were going to use.H.P. or whatever

13:06

it is we decide on. Well

13:08

there's so many lines of code

13:10

out there right now using dotH

13:12

that we can't change that it's

13:15

just going to be an inconsistency

13:17

and unlike Other times when we

13:19

bring up the inconsistency argument where

13:21

you can say, well, that's just

13:23

going to hold us back from

13:25

improving, that's the thing. I don't

13:27

think it's actually going to improve

13:29

anything. So, probably not a fight

13:31

worth having, although I tend to

13:33

agree with the underlying sentiments. Right.

13:35

So, Louis, in your standard library,

13:37

I guess your headers don't have

13:40

any extension, which... Which by the

13:42

way is really weird. I don't

13:44

understand. Yeah, it's weird. Like I

13:46

never understood that. Yeah, that's that's

13:48

kind of weird. What's the deal,

13:50

right? I thought the idea was

13:52

that they're not necessarily actually implemented

13:54

in head of files at all.

13:56

It's more like a, you know,

13:58

you want to include this sort

14:00

of pseudo module. But in practice

14:02

they kind of are, right? So

14:05

you. Go to the source code

14:07

for vector and then you're in

14:09

a file that's just called vector.

14:11

Yeah, but it doesn't have to

14:13

be implemented that way. Yeah, yeah.

14:15

I mean, to me, I mean,

14:17

if that's irrational, it seems like

14:19

one of these places where the

14:21

standard tries to be overly general

14:23

and give us like a lot

14:25

of like, you know, allow for

14:27

many different ways to be conforming

14:29

implementation when in reality I mean.

14:32

don't really need that much anyway.

14:34

But yeah, so we actually have

14:36

private headers as well, right, to

14:38

like help implement the public ones.

14:40

And we use the H. And

14:42

frankly, I just don't really have

14:44

an opinion. I'm very neutral on

14:46

this. I mean, I think I

14:48

agree, I think with the underlying

14:50

statement that's like, yes, it's nice

14:52

to have something that, you know,

14:54

differentiates C plus from C. But

14:57

at the same time, it just

14:59

seems like such a... sort of

15:01

very small thing. I don't know,

15:03

I just, I don't think it's

15:05

worth spending a lot of time

15:07

and energy sort of discussing that

15:09

when we have, you know, other

15:11

things that are much more important,

15:13

but that's really just like my

15:15

personal position. So like I would

15:17

go with whatever makes people happy

15:19

essentially is my position. So yeah,

15:22

I don't care. It's a pretty

15:24

good position. I think I can

15:26

get behind that. So what do

15:28

you think then, Tima? Well... It's

15:30

kind of similar. I do like,

15:32

you know, kind of in my

15:34

way my brain is wide. I

15:36

kind of like things being categorized

15:38

and labeled and cleanly differentiated from

15:40

each other. I mean, you don't

15:42

see this because it's just audio

15:44

only. But if you do see,

15:47

like Phil and Louis see my

15:49

room and like there's lots of

15:51

little drawers that painstakingly labeled and

15:53

regards to what's in them. So

15:55

I would actually, you know, say,

15:57

yeah, dot H for C and

15:59

dot H for CPP for CPP

16:01

makes a lot of sense. But

16:03

much like Louis, I don't think

16:05

this is something we like should

16:07

spend time on because kind of

16:09

the kind of what we win

16:12

by. I'm spending a lot of

16:14

time on it and what it

16:16

costs to spend a lot of

16:18

time on it that we don't

16:20

spend on other things. It's kind

16:22

of like that ratio doesn't seem

16:24

to be very favorable. So I

16:26

wouldn't spend too much time on

16:28

discussing this probably and in my

16:30

opinion. That's exactly why people like

16:32

to discuss it. Well, I guess

16:34

that's just how the internet works,

16:37

isn't it? paper by Biena Strujop,

16:39

which was in the latest mailing,

16:41

so in the latest round of

16:43

papers that were published a couple

16:45

weeks ago, with the paper number

16:47

P3651, and it's called note to

16:49

the CSR Standards Committee members. And

16:51

it is actually a publication of

16:53

a message that Biena sent earlier

16:55

on the committee internal mailing lists,

16:57

and then that got leaked to

16:59

the public. And there were other

17:02

articles that were kind of talking

17:04

about that and then Biana said,

17:06

okay, well, now that's been leaked,

17:08

I might as well just release

17:10

it officially. So he did. And

17:12

it is an interesting read. So

17:14

it is a call to urgent

17:16

action partly in response to unprecedented

17:18

serious attacks on C+, so this

17:20

is all about the safety and

17:22

security debate that has been going

17:24

on for I think three years

17:26

now and I guess more intensity

17:29

than before or something like that.

17:31

At least two. At least two.

17:33

There was one sentence there that

17:35

really caught my attention. Biana says,

17:37

I feel strongly about this. Please

17:39

don't be fooled by my relatively

17:41

calm language. And this is kind

17:43

of a big black like, oh,

17:45

okay, okay, he is, he is

17:47

being serious here. This is something

17:49

that, you know, we should pay

17:51

attention to. So Biana is disappointed

17:54

that profiles did not make it

17:56

under CSUS 26. Because that's not

17:58

necessarily because it's a bad idea,

18:00

but because we just didn't have

18:02

a kind of proper spec in

18:04

time. But he says, you know,

18:06

at least the committee didn't do

18:08

didn't do nothing. So TSOS 26

18:10

will have a hardened standard library.

18:12

This is something he explicitly calls

18:14

out. So we have Louis here

18:16

to talk about that in a

18:19

minute. That's going to be very

18:21

interesting. But beyond. says that profiles

18:23

are essential for the future of

18:25

civil status. He says that they

18:27

will not break your code, they

18:29

will not, you know, prevent us

18:31

from standardizing other stuff later, and

18:33

we should move forward with that.

18:35

So that's kind of an oversimplified

18:37

summary of that article. So yeah,

18:39

I thought that was significant because

18:41

that's kind of what on Biana's

18:44

heart right now and he says,

18:46

you know, this is really important,

18:48

please listen to what I'm saying

18:50

to what I'm saying. Yeah, any

18:52

thoughts? Definitely worth a read if

18:54

you haven't seen it already. And

18:56

it sort of reminds me of

18:58

the position you were in back

19:00

in January with regard to contracts,

19:02

a lot of different misinformation or

19:04

misunderstandings going around and like, so

19:06

one chance to correct it and

19:09

put the right information out there

19:11

and this is Biana's moment doing

19:13

the same thing with profiles, I

19:15

think. I think from my perspective,

19:17

profiles were... kind of pretty vague

19:19

for a long time, you know,

19:21

and I think what's happening and

19:23

what happened in Austria is partly

19:25

that, you know, we've just started

19:27

the like really truly understanding what

19:29

profiles are going to, you know,

19:31

make possible concretely. And so it's

19:34

there's also like for any feature,

19:36

especially a feature of that size.

19:38

you need to give people the

19:40

time and the chance to truly

19:42

like consider the different aspects how

19:44

it interacts with other parts of

19:46

the language and so on and

19:48

I feel like maybe this is

19:50

a little bit of a like

19:52

what's happened is a little bit

19:54

of a timing the result of

19:56

maybe like I don't want to

19:59

say bad timing but maybe being

20:01

a little bit late you know

20:03

with the thing so yeah I

20:05

feel that I feel that we

20:07

should not, like we sometimes use

20:09

the fact that like C++ being

20:11

reckoned, you know, by various, you

20:13

know, in various ways, as a

20:15

motivation to, you know, for change,

20:17

but I think it shouldn't, we

20:19

should not forget. basically that we

20:21

need to do things right. And

20:23

sometimes that takes time basically to

20:26

do things, right? So I think

20:28

that's more important at the end

20:30

of the day than doing like

20:32

a major reaction for something that

20:34

we perceive as an imminent trap,

20:36

you know. Yeah, so actually, this

20:38

whole topic of profiles is as

20:40

much part of the safety and

20:42

security discussion as library hardening is,

20:44

which is the other. Which is

20:46

the topic that, you know, we

20:48

invited you here for, Louis. Of

20:51

course, library hardening is a little

20:53

bit more advanced than profiles. In

20:55

fact, it has been accepted for

20:57

CBS 26. They all stream meeting.

20:59

It's very exciting. So we want

21:01

to talk to you about that.

21:03

You have actually been on the

21:05

show before. I looked into the

21:07

archive. That was all the way

21:09

back in 2016. When you were

21:11

chatting to Rob and Jason about

21:13

Bust Hanna, which I think at

21:16

the Metaprogramrogramming library, you wrote that

21:18

was like very, very, very, very

21:20

new. Everybody was very excited about

21:22

it. Was at the time a

21:24

very new way of programming with

21:26

constant expert. But a lot of

21:28

stuff has happened since then, hasn't

21:30

it? So much, I mean, yeah,

21:32

it feels like a lifetime, yeah.

21:34

All right, so library hardening. So,

21:36

so what is it? It's really

21:38

simple, honestly, like, do you know

21:41

how the standard has a bunch

21:43

of these preconditions? Like the in

21:45

the standard for the library clauses

21:47

you have a bunch of these

21:49

preconditions that are like written explicitly

21:51

or sometimes they're a little bit

21:53

implicit but they're very like obvious.

21:55

Well we're just basically turning those

21:57

from being undefined behavior if you

21:59

don't satisfy the precondition into being

22:01

like a guaranteed I'm going to

22:03

say guarantee crash that there's obviously

22:06

like more to it's actually like

22:08

a contract violation. But basically we're

22:10

giving you know we're providing a

22:12

guarantee that something not bad you

22:14

know is going to happen if

22:16

you if you don't satisfy precondition.

22:18

So it's very basic. Could you

22:20

give us an example of one

22:22

of these preconditions? something concrete to

22:24

think about? Yeah, for sure. So

22:26

standard vector over the bracket, for

22:28

example, has a pre-conviction that the

22:31

index to pass is less than

22:33

the size of the vector, right?

22:35

And that's to make sure that

22:37

you don't index your vector out

22:39

of balance. And so under a

22:41

hardened implementation of the standard, you

22:43

would get a contract violation if

22:45

you fail to provide, like if

22:47

you provide an index, that's too

22:49

large. Whereas today in a normal

22:51

non-partian implementation, you do get undefined

22:53

behavior, which means that in most

22:56

cases what's actually going to happen

22:58

is that you're just going to

23:00

be reading or writing outside of

23:02

the bounds of your vector, which

23:04

is bad, obviously. All right, so

23:06

how does that work concretely? So

23:08

let's say I have a code

23:10

base that uses the vector, which

23:12

I think most of us do,

23:14

and then I have a call

23:16

to operate this square bracket, and

23:18

I mess it up. And then

23:20

I have a weird bug today,

23:23

and then I upgrade our current

23:25

brand compiler. Is it like, I

23:27

guess, I guess, actually, let me

23:29

rewind. Is this something, so now

23:31

we've accepted this in the CSOS

23:33

26, which of course, isn't really

23:35

even standardized yet and much less

23:37

available as a compiler flag, but

23:39

it is something I can already

23:41

use today if I'm on CBS

23:43

17 or CBS 20, or isn't

23:45

that right? Yes, I mean, it

23:48

depends on the, like if you're

23:50

using LibC+, well, actually, if all

23:52

implementations provide something that is kind

23:54

of similar, you know, it has,

23:56

you know, differences, but, yeah, so,

23:58

so the standard library hardening actually

24:00

comes from standardizing something that we

24:02

did, you know, we started several

24:04

years ago, but we, we did

24:06

in LibC+, plus, and you can

24:08

already enable. the same checks, essentially

24:10

the same sort of balance checks

24:13

in Lipsie process today. whatever your

24:15

standard mode is, and you just

24:17

do that by using a macro

24:19

that we provide. And it's kind

24:21

of less nice than the standard

24:23

thing, but it's effectively, it's the

24:25

same, because you get the same

24:27

chest. So yeah, it is available

24:29

today, already. And now we have

24:31

standardized it, which means that when

24:33

you flip the switch to CSOS

24:35

26, then it will just be

24:38

on by default, or what does

24:40

that mean? No, right. So basically,

24:42

the thing that we're standardizing is

24:44

that we... So you know how

24:46

the standard has like two notions

24:48

basically, a notion of like two

24:50

implementations today. It has like a

24:52

normal hosted implementation and it has

24:54

a notion of a freestanding implementation.

24:56

And when you implement, right, for

24:58

bare metal. So you basically, like

25:00

the ISO standard is really like

25:03

describing two standards in a certain

25:05

way, right? It's like a template

25:07

for, you know, producing standards and

25:09

you have like two standards. And

25:11

rather than basically like another access

25:13

to this. So just like an

25:15

implementation can decide to be hosted

25:17

or freestanding, you can also decide

25:19

to be hardened or well, not

25:21

hardened. And so the idea is

25:23

that completely, let's say you have

25:25

planned, it plainly provides today a

25:28

flag called dash as freestanding. And

25:30

when you pass dash of freestanding,

25:32

it says under that flag I

25:34

am a a confirming ISO C++

25:36

3 standing implementation. We're actually not

25:38

really conforming but that's the you

25:40

know in spirit. And then you

25:42

don't have like dynamic memory you

25:44

don't have threads and stuff like

25:46

that right? Well it disables a

25:48

bunch of stuff right? And like

25:50

you know there's no special mangling

25:53

for Maine there's like all kinds

25:55

of things that are okay okay

25:57

okay yeah interesting and and the

25:59

idea basically is that your compiler

26:01

when you pass maybe in dash

26:03

F hardened would now give you

26:05

a conforming target implementation of the

26:07

standard. And what that means is,

26:09

I said before, is that when

26:11

you are a conforming pardon implementation

26:13

of the ISO standard, then you

26:15

need to not have you be

26:17

when you index a factor out

26:20

of that. So that's kind of

26:22

the way this goes. So people

26:24

who are interested in getting this

26:26

would enable the flag that turns

26:28

their implementation into a hardened implementation

26:30

if they provide such a thing,

26:32

which we expect people or implementations

26:34

are actually going to provide. And

26:36

then they get all the guarantees

26:38

that comes with that. Oh right,

26:40

so basically you took the flag

26:42

that you already have essentially and

26:45

you said okay now that's a

26:47

flavor of the standard that's basically

26:49

blessed by the superstar standard itself.

26:51

Yeah exactly yes that's that's the

26:53

way that's basically a way to

26:55

introduce a language mode without acknowledging

26:57

that it's really a language mode

26:59

because that is not a very

27:01

very popular idea. All right. So

27:03

the way that we specified it

27:05

in the proposal is that it

27:07

is a contract violation. fail to

27:10

respect some of these, one of

27:12

these preconditions. And so you get

27:14

the whole sort of contracts machinery,

27:16

you know, you get to like

27:18

override your handler, you get the,

27:20

you know, the contract semantic selection,

27:22

and so on. And so that's

27:24

actually extremely useful. Because, and that's

27:26

something that we noticed in Tokyo,

27:28

right? People, and we, we, like,

27:30

you know, talked about it, like,

27:32

a whole lot, actually, over the

27:35

past year. Yeah, there was a

27:37

lot of back and forth to

27:39

get the wedding ride to make

27:41

sure it gels with the main

27:43

contract's proposal. And yeah. Right. And

27:45

even changes to contracts themselves, because

27:47

in Tokyo. I remember when I

27:49

first sort of, I don't know,

27:51

I woke up from, I don't

27:53

know what, and I realized like,

27:55

hey, contracts, like, it's like super

27:57

important. And it's like, it's like

28:00

extremely relevant to what we're doing.

28:02

And I was like, hey, but

28:04

it actually does not support like

28:06

the main use case that I

28:08

have. And then we, you know,

28:10

we talked about it and we

28:12

like, you know, improved contracts a

28:14

little bit here and there. And

28:16

like, it's like, it's like a

28:18

perfect fit. it gives you the

28:20

exact set of like requirements that

28:22

you need to have in order

28:25

to really deploy hardening on a

28:27

large scale or even on a

28:29

small scale at a small scale.

28:31

So for example, the ability to

28:33

have the observed semantics of contracts,

28:35

which is to say that you

28:37

when a precondition is not respected,

28:39

you're going to, the handbra is

28:41

going to get called so that

28:43

you can say, for example, oh,

28:45

you know, the vector was accessed

28:47

outbound, but it does not terminate

28:50

the program. The program just keeps

28:52

going, right? And whatever happens, happens.

28:54

That's not a very clean thing

28:56

to do, but it's actually extremely

28:58

important in practice because if you

29:00

have like a huge code base,

29:02

you're going to have been lying.

29:04

instances of UV like insensitive undefined

29:06

behavior that are actually not causing

29:08

any harm. But if you decide

29:10

to actually crash and abort a

29:12

program, when you encounter that UV,

29:14

now you've got a real big

29:17

stability problem. So that's an actual

29:19

issue for being able to deploy

29:21

this in production. So what you

29:23

might want to do is do

29:25

something like enable the observed semantic

29:27

for, you know, one or two

29:29

releases while you're driving down the

29:31

amount of bugs. And as you're

29:33

fixing those, and at some point

29:35

you become comfortable, that you're not

29:37

going to bring down your whole

29:39

server or have your desktop app

29:42

actually crash all the time. So

29:44

you fix those bugs, then you

29:46

actually enable hardening with a proper

29:48

trapping semantics, which is also all

29:50

provided by contracts. And boom, I

29:52

mean, now you're in a good

29:54

place. So this, like the set

29:56

of features provided by contracts, especially

29:58

the contract violation handling part of

30:00

it, is just like a perfect

30:02

match for exactly what we're trying

30:04

to do in the standard library.

30:07

So I'm really, really happy that

30:09

both got in together. Yeah, I'm

30:11

really happy as well. And a

30:13

lot of the motivation for, for

30:15

example, having observed that you say

30:17

that you know, have for the

30:19

standard library is, it's the same

30:21

motivation that you have for like

30:23

the. the base feature right where

30:25

somebody adds their own pre or

30:27

post and and they want exactly

30:29

that they want to be able

30:32

to deploy that without crashing their

30:34

code if they got it wrong

30:36

so so it's just really interesting

30:38

to see how like from both

30:40

sides it all kind of comes

30:42

together and makes sense that makes

30:44

me very happy yeah yeah on

30:46

the one hand it does seem

30:48

that the timing is right to

30:50

do it now and number of

30:52

ways in the contracts being there,

30:54

the focus on safety and security.

30:57

On the other hand, this is

30:59

something we could have done many

31:01

years ago, we'd be right at

31:03

the start, but why didn't we?

31:05

And for a lot of people,

31:07

that's because there's got to be

31:09

a performance cost to doing these

31:11

checks. So is that really something

31:13

that we can afford? I think

31:15

it is. There, well, so actually,

31:17

we, you know, lipsylosis is hardly,

31:19

it's been around for a while

31:22

now, and we went through, But

31:24

part of that, you know, as

31:26

part of that, we have examples

31:28

of like basically standard library hardening

31:30

being deployed in production. I mean,

31:32

we've deployed it in, you know,

31:34

it's on the kernel, in WebKit,

31:36

we've deployed it in a bunch

31:38

of internal code bases, and Google

31:40

is also like, has also deployed

31:42

it in like their whole code

31:44

base. which if I understand correctly

31:46

that includes the service like you

31:49

you know chrome a bunch of

31:51

mainstream apps and they actually wrote

31:53

a blog post with their experience

31:55

and they showed that like they

31:57

got it down to a point

31:59

three percent performance slowdown so so

32:01

is it something that you can

32:03

afford well I guess that depends,

32:05

but I would say, you know,

32:07

given, like, they found over, like,

32:09

they found over, like, a thousand

32:11

bugs, and they estimate that it's

32:14

going to reduce their number of

32:16

bugs by, like, one or two

32:18

thousands yearly, and they reduce their,

32:20

like, baseline sexual number by 30%.

32:22

I mean, it's just, like, you

32:24

know, those numbers are amazing. And

32:26

if the only thing that you

32:28

have to pay is, like, point

32:30

three percent performance, I don't know,

32:32

but to me, it's like, it's

32:34

like, like, like, like, like, like,

32:36

like, like, like, like, like, like,

32:39

like, like, like, like, like, like,

32:41

like, like, like, like, like, like,

32:43

like, like, like, like, like, like,

32:45

like, like, like, like, like, like,

32:47

like, like, like, like, like, like,

32:49

like, like, like, like, like, like,

32:51

like, like, like, like, But there's

32:53

a lot of aspects of the

32:55

hardening proposal. And of course, you

32:57

know, since it comes from the

32:59

Lip C++ cardening, the design of

33:01

that specific feature in Lip C++,

33:04

there's a lot of aspects of

33:06

that that are meant to enable

33:08

that to make that possible. So

33:10

for example, the way that we

33:12

implement traps, which is actually taken

33:14

from the Swift Standard Library, is

33:16

that we enable like a single,

33:18

sorry, we insert a single instruction

33:20

to trap. So it's very very

33:22

low cost. It does not increase

33:24

your code size a lot. It's

33:26

something that the compiler can reason

33:29

about, maybe can hoist it out

33:31

of loops. And it's just like,

33:33

it's a very, very low cost

33:35

approach to doing this. So yes,

33:37

I do think it is something

33:39

that people can, most people should

33:41

be able to. afford that sort

33:43

of performance hit because it's very

33:45

very small. And then the other

33:47

thing is we can also, well

33:49

the leaps of information of hardening

33:51

at least, allows you to select

33:54

whether you want to enable hardening

33:56

on a per translation unit basis.

33:58

So if you actually have like

34:00

a very hot loop that may

34:02

not be security critical, you know.

34:04

then you might not want to

34:06

actually enable hardening in that translation

34:08

unit, but then you harden the

34:10

rest of your application. So you

34:12

can actually try to pick the

34:14

things that you want to harden.

34:16

And yeah, this fine grain control

34:19

is really important if you want

34:21

to actually do it in the

34:23

real world. So I'm happy that

34:25

you're mentioning pertrastration unit because that

34:27

gets us into a whole interesting

34:29

set of questions that we had

34:31

to answer for the base. contracts

34:33

proposal as well. And I'm curious

34:35

how you answered it for the

34:37

standard library. Right. So for things

34:39

like, you know, what happens if

34:41

you have the same function in

34:43

one transition unit with another one

34:46

without hardening? What if that function

34:48

is in line? What if, like,

34:50

does that affect ABI? Does it

34:52

affect, like, how do you, how

34:54

does the linkage choose between the

34:56

hardened and the non-hardened one if

34:58

it's, if it's, if it's in

35:00

line? How does the user know

35:02

which one gets picked? There's a

35:04

whole set of questions here, like

35:06

how does this actually work? Right,

35:08

it's actually very difficult and it's

35:11

not a fully solved problem, just

35:13

to be very clear. So I

35:15

think it's useful maybe like for

35:17

a listener, I think it's useful

35:19

to step back and to basically

35:21

the idea here is that you,

35:23

when you have a translation unit,

35:25

right, you select a set of,

35:27

you're going to say configuration options

35:29

that affects how like what code

35:31

is generated. So these configuration options.

35:33

that includes like, do you have

35:36

exceptions enabled? Do you have hardening

35:38

enabled? Even the standard mode actually

35:40

affects that because we have if

35:42

that's based on the standard mode

35:44

inside the standard library and you

35:46

may have that in your code

35:48

as well. So there's a lot

35:50

of different, you know, comparative flags

35:52

that affect the actual binary output

35:54

or, you know, code gen that

35:56

you get inside a translation unit.

35:58

Now, the idea is that with

36:01

templates, right? we have the one

36:03

definition rule where basically if you

36:05

have the same function with the

36:07

same name, right, that just instantiated

36:09

in different translation units, the linker

36:11

needs to be able to keep

36:13

just one of them, right, when

36:15

it links everything together to produce

36:17

an actual executable. So the idea

36:19

is that one definition rule says

36:21

that if they have the same

36:23

name, if all the functions have

36:26

the same name, then they need

36:28

to have the same. code gem.

36:30

They need to, it needs to

36:32

be the same code because otherwise,

36:34

because the linker is basically picking

36:36

one at random. And so if

36:38

you have functions with the same

36:40

name, but that have different code

36:42

gen, now basically you don't know

36:44

which function you're going to be

36:46

ending up with in your final

36:48

executable. And that is the root

36:51

of this whole question. And hardening

36:53

contracts, evaluation semantics, dash F no

36:55

exceptions, even though that is not

36:57

acknowledged by the standard, but that

36:59

still exists. Those are all things

37:01

that... that affects the code gen.

37:03

And we need a way to

37:05

sort of make sure that you

37:07

get the function, that you actually

37:09

use the function that has a

37:11

code gen that you wanted. Because

37:13

an example of something that can

37:16

happen otherwise. So let's say you

37:18

call a function that may grow

37:20

an exception, right? And you're compiling

37:22

your code with exceptions enabled. So

37:24

you call the function, you have

37:26

a tri-catch, you're doing everything correctly

37:28

to handle your errors. But then

37:30

you actually link against like a

37:32

distant translation unit over there that

37:34

has been compiled with exceptions disabled.

37:36

And under exception to the label,

37:38

the function instead like aborts the

37:40

program, right? And but it's cool

37:43

because you're not actually... calling, like

37:45

you're not linking against, I mean,

37:47

you enabled exceptions in your translation

37:49

unit, right? And then when you

37:51

actually laid everything together, the problem

37:53

is if the linker decides to

37:55

pick the version of the function

37:57

that was compiled with exceptions as

37:59

labeled, that thing actually aborts, it

38:01

does not throw an exception. So

38:03

now it's got to try to

38:05

attach against a function, right? that

38:08

actually aborts, because that's the version

38:10

that the linker picks. And so

38:12

you don't see it in your

38:14

code, right? You're like, why the

38:16

hell is this aborting? I've seen

38:18

bugs like this. They're very, very,

38:20

very hard to even figure out

38:22

what the hell is going on.

38:24

Like as soon as you have

38:26

an audio bug, like, yeah, you're

38:28

going to spend days on this.

38:30

It's just staring at the code

38:33

and being like, why? Is this

38:35

a boring, I am catching the

38:37

exception? And it's just because, well,

38:39

you're just not calling the function

38:41

that you think you are, right?

38:43

You're just calling the, it's the

38:45

other version of the if-def. So,

38:47

with all of that, you know,

38:49

understood now, basically, how do we

38:51

solve that problem? So, the problem

38:53

comes at the end from the

38:55

fact that we have a function,

38:58

well, I'm gonna say two functions,

39:00

really, with the same name, but

39:02

they have different code, right. the

39:04

configuration, like the properties that it

39:06

has in the CodeGen. So what

39:08

we do in LipC+, and that's

39:10

not actually like a full solution,

39:12

but it helps a lot, right?

39:14

So in LipC Plus Plus, we

39:16

actually compute what we call an

39:18

ODR signature based on various properties

39:20

of the current build, right? So

39:23

we actually sniff some of the

39:25

compiler flags, and then we say,

39:27

all right, hardening mode is, you

39:29

know, fast. Exceptions are enabled. This

39:31

is the, like, here's the numerical

39:33

version of the library. And there's

39:35

other stuff like the standard mode

39:37

we could add and then bunch

39:39

of stuff like that. But for

39:41

now we just like sniff these

39:43

three properties, we then, on the

39:45

two processor level, we form a

39:48

stream, right? That looks like N-E

39:50

and then a number, whatever. It's

39:52

just like some sort of hash,

39:54

right? So you basically mangle the

39:56

compile of like somehow. Exactly, so

39:58

we take a hash of the

40:00

compiler's flags. It's a very, very,

40:02

it's a very primitive version of

40:04

that. I did not know that's

40:06

interesting. That's really cool. Yeah, we

40:08

actually do that. If you grab

40:10

for ODR signature and Lipshiples stuff,

40:13

there's a very long comment that

40:15

explains how this works, why it's

40:17

done, et cetera, and it's pretty

40:19

interesting. It came from like, yeah,

40:21

it's, we converge towards the solution

40:23

after like years of banging our

40:25

heads against these sort of issues,

40:27

these sort of issues. And basically

40:29

what we do with that spring

40:31

now is that we, and that's

40:33

the nasty part I guess, but

40:35

we basically include that special hash

40:37

into the mingling of every function

40:40

that we produce ever. Right. every

40:42

ABI, like everything that is not

40:44

part of the Dylib's API, essentially,

40:46

right? So everything that we don't

40:48

want to keep ABI stable. And

40:50

that's this lip CBP hide from

40:52

ADI macro. That's, you know, the

40:54

thing, the macro, that macro applies

40:56

this, this ABI tag, this like

40:58

special mangling property to the functions.

41:00

So that's how we fix that.

41:02

And the result is basically that

41:05

now, if you're calling vector operator,

41:07

from a hardened translation unit. You're

41:09

reading that calling vector over the

41:11

bracket. You're calling vector over the

41:13

bracket underscore hard and fast. And

41:15

if someone else is calling vector

41:17

over the bracket from a non-hardened

41:19

translation unit, they're calling vector over

41:21

the bracket underscore not hardened. And

41:23

so when the later, when you

41:25

throw the later at these translation

41:27

units, there's no confusion as to,

41:30

you know, which function where you

41:32

call calling, right. So there's no

41:34

chance that you're actually going to.

41:36

thing that you're calling a hardened

41:38

implementation when in reality whoops you

41:40

were calling it not like an

41:42

unsafe one this is all going

41:44

to work as I've intended that's

41:46

the goal right so so that's

41:48

fascinating two questions immediately after this

41:50

explanation first does that have an

41:52

impact on binary size and how

41:55

bad is that and and the

41:57

second question is what what happens

41:59

when like it's the function is

42:01

inlined and you never have a

42:03

symbol anywhere right so It does

42:05

have an impact on binary size,

42:07

but basically, the impact it has

42:09

is that now, like, you have

42:11

the exact, like, you have more

42:13

copies of function, but you have

42:15

one copy per copy that is

42:17

required. In other words, like, you

42:20

don't have duplicate code, you just

42:22

have. you know, the correct code.

42:24

You have as much code as

42:26

you need to actually do the

42:28

thing you want to do. Correct.

42:30

Whereas previously, it's as if you

42:32

had like some really nice outlining,

42:34

you know, of the... in your

42:36

compiler, but these outlining optimizations were

42:38

incorrect. And so, you know, that's

42:40

what you get by default. So

42:42

we're just restoring that. So, yeah,

42:45

if you do that sort of

42:47

trick, you will notice maybe a

42:49

little bit of a cosides change,

42:51

but at the same time, this

42:53

is the cost for correctness. Now,

42:55

the other thing is, it's actually

42:57

not a full solution, because the

42:59

moment you pass through a function

43:01

that is not have an AI

43:03

tag like that. Now, so for

43:05

example, if you get in-lined into

43:07

another function, like a user function,

43:10

that does not have an ADI

43:12

tag, then, you know, well, I

43:14

guess if you get in-lined, then

43:16

it's okay because the code that

43:18

gets in-lined is the one that

43:20

you selected with your compilers like,

43:22

so that's fine. But if the

43:24

function that you were in-lined into

43:26

is a user function, which also

43:28

gets ODR duplicated duplicated by the

43:30

later, and it didn't have... an

43:32

ODR signature, then it's the same

43:34

problem all over again, and you

43:37

don't get that guarantee. So that's

43:39

why it is, like, Lipsucus itself

43:41

is protected from these issues, but

43:43

because, you know, the only way

43:45

Lipsucus is useful is by being

43:47

used from user code, and because

43:49

user code is not protected from

43:51

this issue, you know, there's only,

43:53

like, it's not a complete solution,

43:55

basically, like, it's still a problem.

43:57

But we don't see it very

43:59

often, at least not since we've

44:02

introduced the ODR signatures. You mentioned

44:04

that you sniffed the compiler flags,

44:06

which makes me think that you're

44:08

looking for ODR odours. Oh, yeah,

44:10

classic film again. Right. So. I

44:12

mean obviously we just standardized this

44:14

but it's been around for quite

44:16

a lot longer right in the

44:18

form of vendor specific compiler flags.

44:20

Can you talk a little bit

44:22

about like the history and also

44:24

how much deploy? I'm the experience

44:27

you already had with the stuff,

44:29

like is this out in the

44:31

wild? Are people already using this?

44:33

Like, can you tell us a

44:35

little bit about what you found

44:37

out? Yeah, for sure. So, actually,

44:39

there's been interest for, like, it

44:41

started a long time ago. It

44:43

was totally not like C++ Harding,

44:45

but like, we've been interested in

44:47

the Harding C++ code as a

44:49

general thing for a very long

44:52

time. And often. We wanted to

44:54

do that in like context that

44:56

we're not posted. So context, you

44:58

know, maybe like, you know, firmware

45:00

or the kernel or places where

45:02

Lipshiplessness was not typically available because

45:04

actually Lipshiposis was not really usable

45:06

outside of a posted environment a

45:08

couple of years ago. So. So

45:10

we tried a bunch of things

45:12

and eventually they increased support for

45:14

like freestending in lip c++ opened

45:17

new doors and we realized that

45:19

hey these environments were securely super

45:21

important that didn't have lip ceposote

45:23

before now we can actually you

45:25

know have lip ceposus in it

45:27

and lip ceposus provides you know

45:29

awesome tools like spam stood a

45:31

race to the vector and things

45:33

like that that are more strongly

45:35

types than your typical sort of

45:37

just, you know, see raw pointers

45:39

all over the place, kind of

45:42

thing, right? And, and so then

45:44

we realize, well, maybe actually using

45:46

Lipsiebels Plus, you know, in these

45:48

places and making sure that Lipsiebelsus

45:50

provides increased down safety, you know,

45:52

would be, you know, a good

45:54

way to make progress. And so

45:56

that's what led essentially to this

45:58

safe mode in the And there

46:00

was some adoption in WebKaid, you

46:02

know, Chrome was also like an

46:04

early adopter of that. And then,

46:07

and that was like a basic

46:09

sort of on-off mode where you

46:11

could like get essentially a bunch

46:13

of assertions that we had in

46:15

the library. They were not. really

46:17

audited, they were not really surveyed

46:19

or anything, but you got like

46:21

a bunch of assertions that were

46:23

not too expensive, you know. It

46:25

wasn't very formalized at that point,

46:27

but that's, you know, what, that

46:29

was like the first incarnation of

46:31

it. And you did get a

46:34

function that allowed you to sort

46:36

of customize how, like, what would

46:38

happen when an assertion went wrong,

46:40

right? And Then we improved it

46:42

in 2024 in ALV&18 into a

46:44

full hardening mode that we know

46:46

today. And the main difference here

46:48

basically is that the hardening mode

46:50

that we have today provides, actually

46:52

it provides four different modes. It

46:54

has no carbonate, obviously. Then it

46:56

has fast parting. extensive and debug.

46:59

And the idea is that like

47:01

not all assertions are equally important,

47:03

right? For example, a vector over

47:05

the bracket is pretty important because

47:07

it's an out of bounds issue.

47:09

But a null pointer, the reference

47:11

is usually not that big of

47:13

a deal because it reliably leads

47:15

to a crash. I say reliably,

47:17

you know, it depends on a

47:19

bunch of stuff. And I know

47:21

that like the referencing a null

47:24

pointer can can lead to like

47:26

a high-sum bug where the compiler

47:28

is going to like time travel

47:30

because it sees that you're doing

47:32

something bad down there and so

47:34

it can actually like cost issues

47:36

but in practice like usually if

47:38

you do reference a mode pointer

47:40

you will get a sec fault

47:42

right and so those are not

47:44

equally dangerous and so for that

47:46

reason we actually classify assertions and

47:49

we give people high level modes

47:51

that they can you know this

47:53

so that they can decide what's

47:55

right for them and enable basically

47:57

that mode in their code. So

47:59

that's one of the main differences.

48:01

And then there's, you know, a

48:03

bunch of other design principles that,

48:05

you know, we can get into

48:07

like the fact that like we

48:09

can pick a default mode, like

48:11

the vendors and take the default

48:14

mode that the library comes from.

48:16

So if you're on a. platform

48:18

where safety is like super important

48:20

and performance is maybe also important

48:22

but less in safety, you can

48:24

ship like a lipship so that

48:26

is hardened by default. Then we

48:28

already talked about the the ODR

48:30

stuff basically that was also like

48:32

a requirement for us to make

48:34

it like ODR safe and to

48:36

allow enabling different modes for TU

48:39

because that allows incremental adoption by

48:41

people. They can like enable hardening

48:43

in the part of their code

48:45

base but not all of it

48:47

and things should not blow up

48:49

from an ODR perspective like we

48:51

talked about earlier. And yeah so

48:53

there's a few design principles like

48:55

that but basically that's that's where

48:57

it came to be and where

48:59

it is now. Right so now

49:01

you've got hardening into C+, Plus

49:03

Plus 26. Is that work all

49:06

done? It's full for tied up

49:08

or is there more to do?

49:10

Right, so there is still some

49:12

more to do. I think there's

49:14

a, so first of all, like

49:16

the first writing paper we have

49:18

does not cover the full standard

49:20

library. So we did like a

49:22

survey of the most important ones

49:24

and one of our regarding principles

49:26

there was that we only wanted

49:28

to standardized assertions that we already

49:31

had deployment experience with in Lipsibelslox.

49:33

And that was just like to

49:35

short circuit any. We were kind

49:37

of late in the cycle too,

49:39

so we wanted to short circuit

49:41

any sort of, you know, discussion

49:43

that would potentially question, you know,

49:45

has this actually been implemented? Is

49:47

this actually, you know, worth it

49:49

and blah, blah, blah. So we

49:51

just, we basically just, we just

49:53

decided to standardize things that we

49:56

had already deployed. So there's still

49:58

more to do. We want to

50:00

do like a good survey of

50:02

like to ranges, for example. to

50:04

add some missing preconditions. I think

50:06

there is some work to do

50:08

an empty span as well. there's

50:10

still some more to do from

50:12

the hiring perspective, but we have

50:14

I think we have a good

50:16

start like this this is a

50:18

fair coverage at this point. Right,

50:21

so nearly there, but a bit

50:23

more to do, but I mean

50:25

it's hardening all there is to

50:27

safety in C-plus Pass or there

50:29

are other areas you're interested in.

50:31

Yeah, actually there's another proposal that

50:33

we've been working on. It's a

50:35

paper that's in the pipeline. It's

50:37

in core now. It's adding a

50:39

typed operator new. And it's a

50:41

typed operator new. Yeah, it's a

50:43

type operator new. So it's basically

50:46

a way to define operator new

50:48

as a template. And the first

50:50

parameter of that new kind of

50:52

operator new is a type identity.

50:54

So you actually get the type

50:56

that is being allocated as a

50:58

parameter inside operating, right? And the

51:00

benefit here, it just actually originates

51:02

from a project that aimed at

51:04

improving the security of existing code

51:06

as well. And the goal here

51:08

was to mitigate type confusion attacks.

51:11

So type confusion is basically when

51:13

an attacker, let's say you have

51:15

like a dangling pointer to something

51:17

and you're interpreting. like you have

51:19

a pointer to a few but

51:21

in reality it's a dangling pointer

51:23

and what's really in that memory

51:25

location is not a scoop it's

51:27

a bar and that bar is

51:29

like a super interesting control data

51:31

structure from your kernel for example

51:33

right and let's say you have

51:36

like a legitimate API to actually

51:38

set the food that is dangling

51:40

now you can and you know

51:42

if if food is a string

51:44

for example and you have like

51:46

a legitimate API that you can

51:48

use to set that string to

51:50

whatever byte values you want now

51:52

you you can control exactly the

51:54

contents of the bar with your

51:56

legitimate API right and you can

51:58

get the program to do like

52:00

basically whatever you want. So

52:03

that's the general idea. So now

52:05

this originates from two things.

52:07

First, yes there is a

52:09

dangling pointer somewhere so that's

52:11

bad. But also there is

52:14

basically an aliasing issue where

52:16

you think it's you think it's a

52:18

fool but really it's a bar right?

52:20

And so the idea is that if

52:22

you had a magic system allocator

52:25

that makes sure that you never

52:27

allocate mainly for a few in

52:29

the same place where you have allocated

52:31

memory for a bar. So if you

52:33

make sure that a few in a

52:35

bar, dynamically outdated food and bar can

52:37

never ever alias, you will still have

52:39

your thinking point or bug, but you're

52:41

not going to be able to exploit

52:44

it in the same way. That's the idea. So

52:46

that's a mitigation technique is that does

52:48

not fix the bug, but it makes

52:50

it so much harder for a bad

52:52

person to exploit. So if we like,

52:54

unroll this, basically. The idea here is

52:57

that in order to implement that

52:59

sort of, we call it type

53:01

isolation, right, the system allocator

53:03

needs a knowledge of what type

53:05

is being allocated. But that

53:08

is not knowledge that we have available

53:10

in Oprah New today, because the signature

53:12

of Oprah New is like, I get

53:14

a size Tini, a bunch of other

53:17

stuff, but I don't know what type

53:19

I'm allocating. So, so this, so

53:21

we actually implemented like

53:23

a playing extension that, that

53:26

passes a like 64-bit integer alongside

53:28

operator-to-new. We have like a funky

53:30

operator, like a new variant of

53:33

operator-to-new Inlet C-Class Plus, that describes

53:35

the type being allocated, and then

53:37

we pass a bound to our

53:40

system allocation, which does some amount

53:42

of type isolation, and really, really

53:45

helps mitigate these sort of issues.

53:47

And so what we asked ourselves is,

53:49

is there a way that we

53:51

can make? this technique more easy

53:53

to do without having to do

53:55

like a complicated vendor extension. And

53:57

so that's why basically we propose.

54:00

adding a type operator new where operator new

54:02

now knows the type being allocated so it

54:04

if it wants to it can actually pass

54:06

that down to the system allocator or to

54:09

any custom allocator you might implement

54:11

for yourself. So that's kind of the

54:13

idea and we think that there is

54:15

also a lot of other benefits to

54:17

like there's other non-safety related things that

54:20

you can do with this feature so

54:22

we're pretty excited about that. Nice I

54:24

look forward to all the discussion about

54:26

new new new versus old new. All

54:29

right, so we talked a lot about

54:31

library hardening and contracts and and

54:33

do you operate in you and other

54:35

safety and security related things, but we

54:37

are actually coming up on time here.

54:39

So I think we should slowly wrap

54:41

up. But before we do that, we have

54:44

our traditional last question, which is apart

54:46

from all of the stuff that we

54:48

talked about, is there anything else in the

54:50

world of CSRs right now that

54:53

you find particularly interesting or exciting?

54:55

Yeah, I well, we kind of talked about

54:57

it, but I'm really excited about

54:59

contracts. I just want to say

55:02

it again. But really, I'm really

55:04

happy to see that reflection making

55:06

progress. I think it's, yeah, I think

55:08

it's just going to open the door

55:10

to so many awesome things, right?

55:12

Like that's your Asia, also interrupt

55:14

with other languages. It's just going

55:16

to be like, you know, I think

55:19

it's a great feature, very powerful feature,

55:21

especially. As an implementer, I'm very scared,

55:23

though, that's for what users are going

55:25

to be able to do. We've been

55:28

discussing with clang people about ways

55:30

to protect our implementation against abuse.

55:32

Otherwise, we think that mental compartment

55:35

upgrades are going to be very,

55:37

very difficult because people are actually

55:39

going to do weird stuff with

55:42

our implementation details. And yeah, basically, it's

55:44

going to be very powerful, but also, you

55:46

know, if you can. use implementation details too

55:48

much than it gets hard to do any

55:50

kind of upgrade. And so I think we'll need

55:52

to figure out ways to protect

55:54

ourselves against that, maybe some special

55:56

attributes, special compartment diagnostics that prevent

55:58

people from shooting. themselves in the

56:01

foot. But apart from that, you know,

56:03

that's, you know, I think that's point.

56:05

I think there's technical solutions to that.

56:07

Another thing that I'm pretty excited with

56:09

is Hannah's work on expanding concepts really.

56:12

I'm really glad that she's working on,

56:14

you know, taking concepts for it to

56:16

its full potential. I think she's been

56:18

doing amazing work. So I'm actually really

56:21

looking forward to that. It does create

56:23

quite a bit of work for me,

56:25

but, you know, I think it's worth

56:27

it's important. So yeah, I think those

56:30

are the two things on my radar.

56:32

So what's the latest there? We can now

56:34

throw exceptions at compile time. Yeah,

56:36

she's got like an implementation of

56:38

that. I mean, it's super, super,

56:40

uh, impressive, really. I think co-routines

56:42

is the one remaining thing, isn't it?

56:44

I'm actually not sure what is the same of

56:46

the co-routine one. So that was,

56:48

I think, controversial people, people, some

56:51

people were saying it's not really

56:53

implementable. There was a lot of

56:55

discussion. At the last meeting that

56:57

I have completely missed because

56:59

I was I was busy

57:01

with getting contracts into 26

57:03

so I have actually no idea

57:05

where that is right now. Probably

57:08

suspended. Okay that was

57:10

a good one. That was a good one.

57:12

All right well we started with

57:14

with both Hannah with Hannah

57:16

Dusikova so that was a nice

57:18

complete circle but I think we

57:20

need to wrap up there so Thank

57:22

you for coming on the show. Is

57:25

there anything else you want to tell

57:27

us before we go? Like, you know,

57:29

where we can find you when I

57:31

continue the conversation? Sure, I

57:33

mean, you can reach out to

57:36

me by email, mostly, otherwise I'm

57:38

on the album discord, or you can

57:40

reach out to me by just screening

57:42

and issue against some people. So I

57:44

guess it's pretty much all I do

57:46

these days. So, yeah, and thanks for

57:48

having on. Thanks so much for listening

57:50

in as we chat about C++ Plus

57:52

Plus. We'd love to hear what you

57:54

think of the podcast. Please let us

57:57

know if we're discussing the stuff that

57:59

you're interested in. If you have a

58:01

suggestion for a topic, we'd love

58:03

to hear about that too. You

58:05

can email all your thoughts to

58:07

feedback at CPPcast.com. We'd also appreciate

58:09

it if you can follow CPPcast

58:11

at CPPcast on X or at

58:13

Maston at CPPcast.com on Maston and

58:15

leave us a review on iTunes.

58:17

You can find all of that

58:19

info and the show notes on

58:21

the podcast website at CPPcast.com. The

58:23

theme music for this episode was

58:25

provided by podcast themes.com.