WEBVTT

00:00.000 --> 00:20.000
We will be talking about enabling architectural features in Debian, PAC and BTI on 64.

00:20.000 --> 00:21.000
Thank you so much.

00:21.000 --> 00:25.000
Hello, everyone. Good afternoon.

00:25.000 --> 00:27.000
Thanks, please.

00:27.000 --> 00:31.000
Tafit, you're always standing up.

00:31.000 --> 00:34.000
So I would like to begin by telling you who I am.

00:34.000 --> 00:39.000
Lots of people in this room know me already, but for those who don't, my nickname is Emma,

00:39.000 --> 00:42.000
on IRC and with the match everywhere.

00:42.000 --> 00:46.000
I've been a dead end developer for a long time now, about 20 years,

00:46.000 --> 00:50.000
and since 2023, a couple of years I joined Arm as a dead end developer.

00:50.000 --> 00:55.000
And when I did, when I got the job friend asked the great question,

00:55.000 --> 00:58.000
and he said, why did they hire you actually?

00:58.000 --> 01:00.000
Because Debian works already on 64,

01:00.000 --> 01:03.000
but I don't see any point for you to be working there.

01:03.000 --> 01:06.000
Which I found, you know, is a very interesting question,

01:06.000 --> 01:10.000
even Debian works in my laptop, probably works in your laptop as well,

01:10.000 --> 01:13.000
and it's not that we're closing the distros level and we're saying,

01:13.000 --> 01:15.000
okay, work is done.

01:16.000 --> 01:18.000
Distros development is a bit of an ongoing process,

01:18.000 --> 01:21.000
and it involves a lot of different moving parts,

01:21.000 --> 01:24.000
which is kind of the topic of this presentation.

01:24.000 --> 01:27.000
And also, my friend, when you ask the question,

01:27.000 --> 01:30.000
you know, I request a very long explanation about what

01:30.000 --> 01:32.000
Linux distros is, according to me,

01:32.000 --> 01:36.000
and you're getting the distilled version of that.

01:36.000 --> 01:40.000
So you can see a Linux distra just as a bunch of packages put together,

01:40.000 --> 01:44.000
maybe source or binary depending on the type of distro.

01:44.000 --> 01:47.000
But there is more to that.

01:47.000 --> 01:49.000
Of course, these packages are nice and low,

01:49.000 --> 01:51.000
but you need to install them on a system otherwise,

01:51.000 --> 01:53.000
you know, they're not much use.

01:53.000 --> 01:56.000
On top of that, you could see it differently,

01:56.000 --> 01:59.000
and actually consider the distra as the release.

01:59.000 --> 02:01.000
So maybe the release process,

02:01.000 --> 02:05.000
we had talks today about different sort of rolling distros.

02:05.000 --> 02:08.000
Maybe that's what the distribution agreed upon.

02:08.000 --> 02:12.000
Or you have stable releases that are cut at a certain point

02:12.000 --> 02:14.000
in time with a certain process.

02:14.000 --> 02:18.000
And this process is what also makes the distribution in a way.

02:18.000 --> 02:21.000
The group of people that then come up with agreements

02:21.000 --> 02:26.000
and discussions and then come up with rules and procedures

02:26.000 --> 02:28.000
and try to follow them.

02:28.000 --> 02:30.000
I want to talk about two talks,

02:30.000 --> 02:32.000
someone said that the hardest thing is

02:32.000 --> 02:35.000
of development is convincing people to do things.

02:35.000 --> 02:39.000
And that's basically what this talk is about.

02:40.000 --> 02:43.000
I would use an architectural feature,

02:43.000 --> 02:46.000
as an example of enabling a change in the distribution,

02:46.000 --> 02:49.000
which is, you know, touching different parts.

02:49.000 --> 02:55.000
And how this process is really mostly about talking to people at the end of the day.

02:55.000 --> 02:58.000
But given that the architectural features have two names,

02:58.000 --> 03:01.000
it seems proven to tell you what this name is about,

03:01.000 --> 03:02.000
Park and VTI.

03:02.000 --> 03:04.000
That's the first thing we'll talk about.

03:04.000 --> 03:07.000
Then I will tell you how we went about to enable the features,

03:07.000 --> 03:11.000
how we were checking the status of enablement,

03:11.000 --> 03:13.000
and what we're going to do next.

03:13.000 --> 03:18.000
Park and VTI, with our disk to create the acronyms about.

03:18.000 --> 03:20.000
So these are two security features.

03:20.000 --> 03:23.000
The idea is to make a line of this draw better

03:23.000 --> 03:26.000
by mitigating control flow attacks.

03:26.000 --> 03:29.000
So the basic idea would be, you know,

03:29.000 --> 03:34.000
in the past you had a very simple stack overflow attacks,

03:35.000 --> 03:38.000
whereby you could have a buffer of a flow vulnerability,

03:38.000 --> 03:41.000
right past the end of the buffer,

03:41.000 --> 03:43.000
and then inject some shell code,

03:43.000 --> 03:46.000
and you were ready to go.

03:46.000 --> 03:48.000
Computer systems became better,

03:48.000 --> 03:51.000
and now mostly, you know, not all buffer,

03:51.000 --> 03:54.000
but actually the buffers are not executable in general.

03:54.000 --> 03:56.000
So you cannot just do that,

03:56.000 --> 03:59.000
but what you can do, you can mount more sophisticated attacks,

03:59.000 --> 04:02.000
whereby you hijack the control flow,

04:02.000 --> 04:04.000
hence the name control flow attacks,

04:04.000 --> 04:07.000
and you essentially redirect the execution flow

04:07.000 --> 04:10.000
to routines that would be legitimate

04:10.000 --> 04:12.000
and they are remembered for a reason, for example,

04:12.000 --> 04:13.000
G-lip C-routines,

04:13.000 --> 04:15.000
but if you're clever enough,

04:15.000 --> 04:20.000
you can point to areas called gadgets in this area,

04:20.000 --> 04:24.000
and change them in mountain attack.

04:24.000 --> 04:27.000
There are two main categories of such attacks,

04:27.000 --> 04:29.000
one is called return-oriented programming attacks,

04:29.000 --> 04:32.000
and the other one is jump-oriented programming attacks,

04:32.000 --> 04:34.000
similar but a bit different,

04:34.000 --> 04:36.000
and a pack is the first mitigation,

04:36.000 --> 04:38.000
called pointer authentication,

04:38.000 --> 04:40.000
and it's for ROP attacks,

04:40.000 --> 04:42.000
and the other mitigation is called BTI,

04:42.000 --> 04:44.000
branch target identification,

04:44.000 --> 04:47.000
and it's for jump-oriented programming attacks.

04:47.000 --> 04:49.000
I will tell you a little bit about both,

04:49.000 --> 04:50.000
but not a lot,

04:50.000 --> 04:52.000
because we don't have three hours,

04:52.000 --> 04:55.000
and the pack would be essentially,

04:55.000 --> 04:58.000
the idea is that in a return-oriented programming attack,

04:59.000 --> 05:01.000
you're exploiting the buffer overflow

05:01.000 --> 05:04.000
by overwriting the return address and the function,

05:04.000 --> 05:07.000
so that instead of getting back to whatever it was called,

05:07.000 --> 05:10.000
you begin that attack of chain-ing gadget together.

05:10.000 --> 05:15.000
And the way pack mitigates this is by signing the return address,

05:15.000 --> 05:17.000
so at the very beginning of the function,

05:17.000 --> 05:21.000
there is a assembly instruction that signs the return address,

05:21.000 --> 05:24.000
which is in our registry and on-arm,

05:24.000 --> 05:27.000
and then just before returning,

05:27.000 --> 05:30.000
this address is authenticated,

05:30.000 --> 05:32.000
this signed address is authenticated,

05:32.000 --> 05:34.000
the authentication fails the whole thing,

05:34.000 --> 05:37.000
knows a runtime if it's successful,

05:37.000 --> 05:40.000
everything continues working.

05:40.000 --> 05:42.000
BTI is a bit similar,

05:42.000 --> 05:44.000
but different,

05:44.000 --> 05:47.000
the idea with BTI is that the goal is to mitigate

05:47.000 --> 05:49.000
jump-oriented programming attacks,

05:49.000 --> 05:52.000
where the idea is not to work with the return address,

05:52.000 --> 05:54.000
but rather with jumps,

05:54.000 --> 05:57.000
and in a jump instruction you can pass an arbitrary address,

05:57.000 --> 06:01.000
so we cannot have something to sign at the beginning of execution,

06:01.000 --> 06:04.000
we need to instead validate where we are jumping to.

06:04.000 --> 06:08.000
So the idea is to introduce new instructions called landing pods,

06:08.000 --> 06:11.000
BTI, branch target identifiers,

06:11.000 --> 06:15.000
that we put wherever expected jumps are valid.

06:15.000 --> 06:19.000
So if you jump anywhere else, you get an help.

06:20.000 --> 06:21.000
So that's it.

06:21.000 --> 06:24.000
There's a lot more, of course, to say about all this,

06:24.000 --> 06:27.000
the end of the talk, I'll give you links to reference material,

06:27.000 --> 06:29.000
if you want to read more.

06:29.000 --> 06:32.000
How did we enable all of this in the distro?

06:32.000 --> 06:36.000
Very simple, there is one flag to pass to either GCC on LVM,

06:36.000 --> 06:39.000
and you can say dash and branch protection equal standard,

06:39.000 --> 06:42.000
you enable both end of the talk.

06:42.000 --> 06:45.000
Well, you can also enable either Park or BTI,

06:45.000 --> 06:47.000
but the work we did was,

06:47.000 --> 06:50.000
yes, to set this flag.

06:50.000 --> 06:53.000
But the deployment has a little, like a few concerns,

06:53.000 --> 06:56.000
there are a few things that we need to look for.

06:56.000 --> 06:58.000
In the case of Park, it's fairly alright,

06:58.000 --> 07:01.000
in the sense that we just add new instructions.

07:01.000 --> 07:03.000
If the instructions are there,

07:03.000 --> 07:05.000
there will be executed, of course.

07:05.000 --> 07:09.000
All the CPUs that were maybe designed before all of this came out,

07:09.000 --> 07:12.000
are not going to have problems,

07:12.000 --> 07:15.000
because the new instructions were defined in the knob space.

07:15.000 --> 07:18.000
So when all CPUs get knobs, instead of this stuff,

07:18.000 --> 07:21.000
which is nice, we don't have to provide multiple packages,

07:21.000 --> 07:24.000
you know, one package for more modern CPUs,

07:24.000 --> 07:26.000
for example, and another one for the old ones.

07:26.000 --> 07:28.000
So that's okay.

07:28.000 --> 07:31.000
We just have to build a program and we're happy.

07:31.000 --> 07:34.000
For BTI, it's a bit more complicated.

07:34.000 --> 07:37.000
I mentioned that we're adding this new landing paths,

07:37.000 --> 07:40.000
so you can only jump into specific places,

07:40.000 --> 07:43.000
which means that when you're compiling, for example,

07:43.000 --> 07:47.000
a C program, you may have multiple C files that become object files,

07:47.000 --> 07:49.000
and then the linker puts them together.

07:49.000 --> 07:53.000
Now, it would be really sad if one of those object files

07:53.000 --> 07:54.000
would not have the landing paths,

07:54.000 --> 07:56.000
and then we put everything together,

07:56.000 --> 07:59.000
and if you jump in the wrong place, then the program crashes,

07:59.000 --> 08:00.000
there would be very bad.

08:00.000 --> 08:03.000
So to avoid that, the linker,

08:03.000 --> 08:08.000
when it's linking, checks whether actually the old object files

08:08.000 --> 08:10.000
have BTI enabled, and if they do,

08:10.000 --> 08:13.000
it says, okay, this thing can have BTI,

08:13.000 --> 08:16.000
and it does so by adding a note to the old section.

08:16.000 --> 08:19.000
So the L file will have a note that says, okay,

08:19.000 --> 08:22.000
this thing can do BTI,

08:22.000 --> 08:25.000
which means that then the loader at runtime will check for it,

08:25.000 --> 08:27.000
and we say, okay, this thing is BTI enabled,

08:27.000 --> 08:30.000
we can go ahead and enable it.

08:30.000 --> 08:33.000
There's a little trick here, a little thing.

08:33.000 --> 08:37.000
So even if you build a simplest hell of word program,

08:37.000 --> 08:40.000
you know, one line of code that says,

08:40.000 --> 08:44.000
print hello in NC, that is going to use a couple of object files

08:44.000 --> 08:46.000
from GCC and G ellipse.

08:46.000 --> 08:50.000
And given that, as I said, all object files need to have BTI on,

08:50.000 --> 08:54.000
it means that even the simplest hell of word in order to have BTI,

08:54.000 --> 08:56.000
needs to be built with a G ellipse and GCC

08:56.000 --> 08:59.000
that will have previously built with BTI on, right?

08:59.000 --> 09:03.000
So this means that to enable all of this,

09:03.000 --> 09:05.000
we first have to put it in GCC and G ellipse,

09:05.000 --> 09:08.000
which means that we have to convince the GCC maintainer to do it,

09:08.000 --> 09:10.000
and G ellipse maintainer to do it,

09:10.000 --> 09:13.000
and then the package maintainer to also enable this flag

09:13.000 --> 09:15.000
for all packages in the name.

09:15.000 --> 09:18.000
So this was mostly work of communication,

09:18.000 --> 09:22.000
talking to people asking nicely and so forth.

09:22.000 --> 09:28.000
We got all of this in July, 22, 2024.

09:28.000 --> 09:30.000
So all packages uploaded today,

09:30.000 --> 09:37.000
so they began after this date, started getting BTI on.

09:37.000 --> 09:39.000
How do we track all of this?

09:39.000 --> 09:41.000
So how do we check which packages have it on,

09:41.000 --> 09:46.000
which don't, and what has to be done?

09:46.000 --> 09:51.000
So as I said, the whole idea is that you get a new note in the F,

09:51.000 --> 09:54.000
so if you just write type redf dashnet notes,

09:54.000 --> 09:57.000
and the executable, you will get the notes,

09:57.000 --> 10:01.000
and then you can check if BTI is on or not,

10:01.000 --> 10:05.000
which is pretty simple and nice.

10:05.000 --> 10:07.000
So one of the things I did is,

10:07.000 --> 10:09.000
because of course I don't just want to analyze LS,

10:09.000 --> 10:13.000
I would like to know whether the whole debut in archive has BTI on or not,

10:13.000 --> 10:17.000
and which packages still have to be enabled and was listed.

10:17.000 --> 10:19.000
And possibly also regressions,

10:19.000 --> 10:22.000
so if something has BTI and then suddenly doesn't have it anymore,

10:22.000 --> 10:24.000
because somebody dropped the flag,

10:24.000 --> 10:25.000
who knows why.

10:25.000 --> 10:27.000
It would be nice to know that.

10:27.000 --> 10:31.000
So I wrote a few scripts that use snapshot BbNOR,

10:31.000 --> 10:34.000
I can make sure many of you know what that is,

10:34.000 --> 10:36.000
but it's essentially a very cool service.

10:36.000 --> 10:39.000
It's a bit like a time machine for the BbN archive.

10:39.000 --> 10:43.000
You can hit as a very nice JSON API,

10:43.000 --> 10:46.000
it gives you the list of all snapshots available,

10:46.000 --> 10:49.000
and then you can point your source is list,

10:49.000 --> 10:53.000
for example, at a certain snapshot,

10:53.000 --> 10:55.000
and then you can install the B&C precisely,

10:55.000 --> 10:58.000
as it was two weeks ago, for instance.

10:58.000 --> 11:03.000
So this seemed like a very cool way to find out

11:03.000 --> 11:06.000
what was the BTI enablement state,

11:06.000 --> 11:08.000
to set a given point in time in the past,

11:08.000 --> 11:11.000
and how it's progressing.

11:11.000 --> 11:14.000
So the idea is to get the list of all,

11:14.000 --> 11:17.000
well, to download all the architecture dependent packages,

11:17.000 --> 11:19.000
from snapshot BbNOR get a second day,

11:19.000 --> 11:22.000
for all of them extract the package,

11:22.000 --> 11:24.000
go through all the elf files,

11:24.000 --> 11:26.000
see which ones have the feature on,

11:26.000 --> 11:27.000
and which ones don't,

11:27.000 --> 11:30.000
and then print three graphs.

11:30.000 --> 11:33.000
Downloading the archive doesn't take a lot,

11:33.000 --> 11:34.000
it's about 20 minutes,

11:34.000 --> 11:36.000
while being nice to the service,

11:36.000 --> 11:39.000
and having only seven or eight parallel downloads,

11:39.000 --> 11:40.000
and so forth.

11:40.000 --> 11:43.000
And then running the analysis on our VM,

11:43.000 --> 11:45.000
which eight cores takes about half an hour,

11:45.000 --> 11:46.000
so this is perfectly fine.

11:46.000 --> 11:47.000
It could be optimized,

11:47.000 --> 11:49.000
but 50 minutes to analyze the whole day,

11:49.000 --> 11:51.000
and archive is all right,

11:51.000 --> 11:53.000
we don't do it too often.

11:53.000 --> 11:57.000
And this is essentially the output of that set of scripts.

11:57.000 --> 12:01.000
The red line on top is the number of binary packages

12:01.000 --> 12:03.000
in the BbNOR chip,

12:03.000 --> 12:05.000
at least one elf file,

12:05.000 --> 12:07.000
a bit less than 25,000.

12:07.000 --> 12:09.000
You can see that the red line does a bit up and down,

12:09.000 --> 12:12.000
that depends on whether new packages have been introduced,

12:12.000 --> 12:15.000
or some packages have been dropped.

12:15.000 --> 12:17.000
But it stays fairly constant.

12:18.000 --> 12:21.000
And then on the bottom you'll see the blue line,

12:21.000 --> 12:25.000
and starting from when we got to Glypsy and GCC rebuild,

12:25.000 --> 12:27.000
and we added the default flags,

12:27.000 --> 12:30.000
then slowly all packages being uploaded to the archive,

12:30.000 --> 12:32.000
started getting bit the eye.

12:32.000 --> 12:34.000
So the blue curve follows precisely,

12:34.000 --> 12:36.000
you know, uploads to the VM.

12:36.000 --> 12:39.000
That's the only thing it is.

12:39.000 --> 12:41.000
And it goes up,

12:41.000 --> 12:43.000
but it seemed to go fairly slowly,

12:43.000 --> 12:46.000
I mean there's probably a lot of packages that don't get uploaded,

12:46.000 --> 12:48.000
so often.

12:48.000 --> 12:53.000
So during that chat with Paul Heather's in Cambridge,

12:53.000 --> 12:55.000
we from the release team,

12:55.000 --> 12:59.000
we came up with the obvious idea of trying to rebuild everything,

12:59.000 --> 13:02.000
and see which packages in the BbNOR would get to be

13:02.000 --> 13:06.000
the eye if we were just to rebuild them with the right flags.

13:06.000 --> 13:09.000
Yeah, so here, this is a great idea,

13:09.000 --> 13:11.000
and it's like what we should do.

13:11.000 --> 13:15.000
I made a list of packages that have at least one elf file,

13:15.000 --> 13:18.000
we don't want to rebuild packages that only should pdf,

13:18.000 --> 13:21.000
for example, because they don't get bit the eye.

13:21.000 --> 13:24.000
And then I rebuild them all,

13:24.000 --> 13:26.000
and I check whether they do get bit the eye or not,

13:26.000 --> 13:28.000
with the scripts you've seen before,

13:28.000 --> 13:31.000
and it turned out to my delight that many of them did,

13:31.000 --> 13:36.000
about 7,000 source packages did get bit the eye on.

13:36.000 --> 13:40.000
So then we said, okay, let's must rebuild them all,

13:40.000 --> 13:42.000
right, let's rebuild them all,

13:42.000 --> 13:47.000
so that we basically close that gap, you've seen earlier.

13:47.000 --> 13:50.000
Before doing so, I double checked that all those packages

13:50.000 --> 13:53.000
were actually uploaded before July 22nd,

13:53.000 --> 13:55.000
otherwise it seemed like something strange,

13:55.000 --> 13:57.000
they should have gotten bit the eye already,

13:57.000 --> 14:00.000
if they were built already with a proper tool chain,

14:00.000 --> 14:05.000
that was the case, so I didn't embarrass myself by sending a list of wrong packages.

14:05.000 --> 14:09.000
And yeah, so I asked the release team to please rebuild

14:09.000 --> 14:12.000
7,000 packages, which in the beginning you have to say,

14:12.000 --> 14:15.000
schedule, being enemies, please.

14:15.000 --> 14:20.000
And Sebasti Arama here did all the work of scheduling the rebuild,

14:20.000 --> 14:25.000
so thank you very much to both Sebasti and Paul, if you see this.

14:25.000 --> 14:28.000
Yeah, and the graph looks much better after that.

14:28.000 --> 14:33.000
Those are all the rebuilds that were staggered across a couple of days.

14:33.000 --> 14:38.000
And then after that, the line keeps on following pretty much precisely,

14:38.000 --> 14:42.000
packages being added or removed, doesn't grow too much.

14:42.000 --> 14:47.000
As expected, because we already got everything that would get bit the eye

14:47.000 --> 14:51.000
with a simple rebuild.

14:51.000 --> 14:59.000
So what can we do next to try and further shrink that gap in the next weeks?

14:59.000 --> 15:04.000
So in that graph, you've seen that there are about 19,000 packages that have bit the eye,

15:04.000 --> 15:06.000
and there's 5,000 that don't.

15:06.000 --> 15:11.000
Those binary packages come from 3500 source packages.

15:11.000 --> 15:16.000
And so the realization is that we can probably categorize them,

15:16.000 --> 15:19.000
so we can see how comes those packages.

15:19.000 --> 15:22.000
There are so many packages that don't get bit the eye, if you rebuild them.

15:22.000 --> 15:27.000
And the realization is that GCC and LLVM are not the only compilers in the

15:28.000 --> 15:34.000
produce L5's, Fabian is reading, because it is laughing because it's in the Rust team.

15:34.000 --> 15:42.000
And yeah, so we started looking at this list and categorizing these packages by language.

15:42.000 --> 15:44.000
So now a bit of trivia.

15:44.000 --> 15:48.000
What do you think is the language, which is the biggest of all in all of this?

15:48.000 --> 15:50.000
Haskell.

15:50.000 --> 15:52.000
Yes.

15:52.000 --> 15:56.000
There are a ton of packages in the Avian that are written in Haskell,

15:56.000 --> 15:58.000
and they have L5's.

15:58.000 --> 16:03.000
So not interpreted Haskell, but you actually produce an L5.

16:03.000 --> 16:05.000
And what is the next one then?

16:05.000 --> 16:06.000
Hello.

16:06.000 --> 16:07.000
Hello.

16:07.000 --> 16:08.000
Hello.

16:08.000 --> 16:09.000
Hello.

16:09.000 --> 16:10.000
Hello.

16:10.000 --> 16:11.000
There's a big language.

16:11.000 --> 16:13.000
There's a devroom about it somewhere.

16:13.000 --> 16:14.000
Hello.

16:14.000 --> 16:15.000
Hello.

16:15.000 --> 16:16.000
How's it going?

16:16.000 --> 16:17.000
It's going.

16:17.000 --> 16:18.000
Go.

16:18.000 --> 16:20.000
Go is the next one.

16:20.000 --> 16:25.000
And then somebody said objective common, and that's indeed in the list as well.

16:25.000 --> 16:27.000
And then we finally have Rust.

16:27.000 --> 16:33.000
The reason why Rust is, I mean, of course there's a lot of software in the Avian that uses Rust in different ways.

16:33.000 --> 16:38.000
But Firefox is not part of all of this, because Firefox already ships binaries that are not, you know,

16:38.000 --> 16:40.000
built with the Rust compiler.

16:40.000 --> 16:44.000
So those are, that's a package that we don't consider in this.

16:44.000 --> 16:48.000
These are pure Rust packages built with Rust, see and everything.

16:48.000 --> 16:49.000
Okay.

16:49.000 --> 16:53.000
So the obvious idea now is to fix these compilers.

16:53.000 --> 16:59.000
For Haskell, there's already work on going at ARM, colleague of mine called Bill is working on this.

16:59.000 --> 17:03.000
And for Go and Rust, there are two upstream issues.

17:03.000 --> 17:06.000
And they, again, seem to be mostly about communication.

17:06.000 --> 17:09.000
So there's a long discussion when people are getting about things.

17:09.000 --> 17:17.000
And so I really hope this moves a bit further, so that we can get, you know,

17:17.000 --> 17:21.000
they'd be a more secure essentially.

17:21.000 --> 17:29.000
And then once that is all done, there will be a long tail of another about 1,300 packages that don't fall in those categories.

17:29.000 --> 17:34.000
So there we can see our C++, but they just ignore C flags completely.

17:34.000 --> 17:38.000
So they don't use the C flags you've set, they overrides C flags for various reasons.

17:38.000 --> 17:42.000
I'm sure some are very good reasons and some are very bad reasons.

17:42.000 --> 17:45.000
And so we will have to look into all of those.

17:45.000 --> 17:52.000
And then there's probably also going to be a very long tail of strange cases like stuff with an in assembly.

17:52.000 --> 17:56.000
God knows.

17:56.000 --> 17:57.000
Okay.

17:57.000 --> 18:00.000
So, yes.

18:00.000 --> 18:03.000
To conclude, Puck and BTI are useful features.

18:03.000 --> 18:06.000
I think in ARM64, and they will be available in Trixie.

18:06.000 --> 18:11.000
All the packages you've seen before will be fully protected by both Puck and BTI.

18:11.000 --> 18:20.000
And there's a Wikipedia page there with all the details about what I've talked today.

18:20.000 --> 18:22.000
And much more, of course.

18:22.000 --> 18:28.000
There's also towards the end of the Wikipedia reference section with a bunch of PDFs that really explain in detail.

18:28.000 --> 18:33.000
Puck and BTI and control flow attacks and how they come to measures work.

18:33.000 --> 18:37.000
So if you're interested, go ahead and take a look.

18:38.000 --> 18:48.000
And yeah, I also wanted to make the point that distribution work is not only hacking and from to the keyboard, but it's also talking from to the keyboard, perhaps with other people.

18:48.000 --> 18:57.000
And coordinating and tracking status and trying to convince folks that something is worth doing and so on.

18:57.000 --> 19:02.000
Additionally, another point I wanted to make is that this reward is also about integration.

19:02.000 --> 19:06.000
So if the integration is not done, the future is not there.

19:06.000 --> 19:15.000
You can come up with the best possible feature in the work, very clever, supported in the kernel, supported in the C library, and the bootloader and whatnot.

19:15.000 --> 19:23.000
But then if you don't do the integration work and put everything together, then the future is essentially not there.

19:23.000 --> 19:26.000
And that's all I had.

19:33.000 --> 19:35.000
Any questions?

19:44.000 --> 19:47.000
Thank you for the great talk.

19:47.000 --> 20:01.000
I'm mostly interested in those packages that I mentioned that North Sea Flex, because of the actually for my own personal reasons for, I run the debugging for the service in Devon.

20:01.000 --> 20:06.000
And that's also impacted by that decision in packages.

20:06.000 --> 20:14.000
So I was only if you have a list of the packages that like maybe we can work on and help with BTI and debug it for these.

20:14.000 --> 20:20.000
Oh, this would be lovely. So I do have a full list of old packages that are not into those categories.

20:20.000 --> 20:26.000
So packages that did not get the feature enabled and are not written in, sorry, Haskell, Rast and so on.

20:26.000 --> 20:31.000
So all of those are good candidates to look at, about 1,300, so the list is long.

20:31.000 --> 20:32.000
Yeah.

20:32.000 --> 20:39.000
But some are immediately obvious. There are a few where you open the make file and it just sent C Flex equals.

20:39.000 --> 20:40.000
Yeah.

20:40.000 --> 20:41.000
That's it.

20:41.000 --> 20:42.000
Yeah.

20:42.000 --> 20:43.000
So that's a pretty simple one.

20:43.000 --> 20:50.000
And others are trickier because maybe they use Arcane build systems and it's not that easy to figure out where things are at.

20:50.000 --> 20:53.000
But yeah, I would love to work with you on that.

20:53.000 --> 20:54.000
That's great.

20:54.000 --> 21:03.000
There's also, I forgot the name of it, but there's a system to grab build logs essentially and see if certain flags are set or not.

21:03.000 --> 21:04.000
Right.

21:04.000 --> 21:05.000
That's, that's good.

21:05.000 --> 21:07.000
Maybe we could use that as well.

21:07.000 --> 21:08.000
Yeah.

21:08.000 --> 21:09.000
That's good one.

21:09.000 --> 21:13.000
I've been using that system for, but I don't have a full list of them.

21:13.000 --> 21:17.000
So I just, if you do, that's, that's great. Thank you.

21:24.000 --> 21:31.000
Thanks.

21:31.000 --> 21:34.000
So you mentioned the sampler.

21:34.000 --> 21:42.000
What if in line assemblers missing these landing paths or signing instructions?

21:42.000 --> 21:43.000
Right.

21:43.000 --> 21:49.000
So there is, there is the option of writing the landing path.

21:49.000 --> 21:53.000
Right. So you can write your assembly in a way that you put the landing path in the right place.

21:53.000 --> 21:56.000
And things work.

21:56.000 --> 22:00.000
And then you manually have to mark the object as BTI enabled.

22:00.000 --> 22:05.000
So then the linker will see, okay, this is, like, somebody claims this is BTI enabled.

22:05.000 --> 22:06.000
Probably is.

22:06.000 --> 22:10.000
And then when food swings together it will turn the feature on.

22:10.000 --> 22:12.000
So that's essentially the idea.

22:12.000 --> 22:18.000
There's an article also referenced in the sections that explains how to do all this.

22:18.000 --> 22:22.000
So there is the way to, well, the best idea would be to not use this.

22:22.000 --> 22:24.000
It's impossible.

22:24.000 --> 22:27.000
But there are cases where you can't, of course.

22:27.000 --> 22:32.000
And there's a way to do that.

22:52.000 --> 22:54.000
Thank you.