Okay, let's start. Thanks for coming to my talk. I really appreciate that. So, my name
is Jean-Marie Verde. I'm French. You can probably hear that from my very strong accent. I do
currently live in the US. I work for HPE within the advanced engineering group. The world
of my group is to work on the technology we might be needing within the next three to five
years to integrate into our product. So, I'm part of the team who is designing the next generation
of the product and servers. How family are you with product? Do you know at least the name? So,
this is our H86 suburb brand. Okay. I live in San Francisco, Barrier. So, my Apollo giant
if I look a little bit blurry or not awake. It's currently at your clock in the morning to my
body. I wouldn't say it's odd. My brain doesn't really know why it is. So, I'm involved in
framework development and I'm also involved at supporting new chip architecture. So, I was part
of the team with design and arm-based systems within HPE. So, we have into our product catalogue,
multiple chip architecture from Intel and AMD, but also on peer and in VGA. And on peer and
in VGA are pretty new to the catalogue. And we faced a couple of challenges when we tried to
part of firmware stack to this architecture, which asked which trapped some research activity within
the company and within the engineering. So, the common issues that we faced is we have a common
firmware stack between our Intel and AMD platforms. And we wanted to offer the exact same family
stack to our customers for in IRM. And due to the very strong legacy included into this
firmware stack, the port has been pretty complex and difficult to feel. So, one we think is
we are currently struggling because the firmware technology are currently aging. And all the
concept of the firmware, at least within a servers, are pretty old. So, I don't know if you are
familiar with the UE5, but UE5 is currently about 25 years old. So, which in the tech industry
make it very old. And it has been designed at a time where system where we are very much less
complicated than today. And security threat, one also very smaller. And this has been a very
good technology during the past 20 years, but we think that we need to work on something else
and the next stage. The other thing is the BMC side of MIU with baseball management
controllers. So, raise your hand for the one who knows at least who what it is. So, the BMC is in
charge of managing the server health. So, this is roughly a system into a systems. So, that is the
first thing which starts when you put the power inside a server. It will provide remote management
capability like turning on and half the machines, but it will be also monitoring the system
status just to cool down the machines by spinning up the fans and recording all many issues or any
hardware errors, which might be happening on the whole side, which could be for example, some
demarrows, which happen pretty frequently in some cases. And this is used to debug the systems.
So, that's BMC is running a firmware. And this firmware is getting closer and closer to
full operating system. So, which is mainly based currently on Linux. And that's an embedded Linux
distribution. It's getting bloated to, it's getting harder and harder to maintain because of the
complexity of the software stack. And we think that there might be some challenges to address the future.
So, in parallel, we envision that there will be needs for more and more cheaper architecture
with the upcoming AI requirements. And also the innovation around RISPA, IRM, X86,
GPU computing, FPGA, all of these things needs to be integrated with servers. And we started to
look at how to do that at the hardware level. So, during the past 20 years, we designed system
through a vulnerability approach, which means that we had an engineering team, which was focused
at designing a specific product and they even get to the market. So, this ended up to be a massive
motherboard where you have all the features and then massive motherboard. So, that doesn't scale
in a world where you have to support with people, chip architecture. And we created into the
open compute project foundation program just to build modular servers. So, when we speak about
modular servers, there are a couple of challenges to discuss with the older industry partners,
which means how to interconnect all the pieces together and avoid that there is incompatibility.
So, this is not common into the IT industry. So, we are used to do that to the PCI Express
consumption. For example, if you plug in a PCI Express card within an HP machine or
third systems or any other vendors, it works. So, there's no miracle behind that. There has been a
lot of works between all the two vendors and all the system architect just to make it work and
ensuring that everything is working smoothly. So, while we are overseeing is that the
future is going to be modular servers. Whatever happens. And when we think about modular servers,
it means that the combination of the systems is going to be a way much more complicated than within
the modular and monolithic world. It means that the firmware stack we have first to discover
what's inside the machine. So, right now when we start a firmware on the servers, it knows exactly
what to expect into the machine. So, within the next couple of years, the firmware we have to
discover on what's inside the systems and try to initialize it properly without any issues.
So, that approach of modular machines is not cannibal with the current aromatic energy that we have
and work currently reviewing what's needed to be done. So, on the left-hand side, you have
all the current behavior of the firmware stack, which is static, design for monolithic machines,
and it's coming also with another pain mainly the update process is�d devices. So, which means
that you have different update processes for an NVMe drive for a graphic card, a CPU, or a PMC.
So, that also doesn't scale in a world where you have modularity. So, what we think is,
we would be needing to put in place some front points where the hardware is going to get the firmware
from and the firmware is going to become more and more volatile. So, we believe that it is not going
to stand into the machine anymore, it is going to be somewhere on the network and the only one thing
that the machine is able to do is to boot from the network and reach with its firmware from the
network. And based on that, we might be able to have a very highly adaptative firmware stack,
which means that we got a big database on firmware, which is sitting somewhere into the data
centers or in the internet and the systems we are going to connect to that database.
The idea is not to become proprietary around firmware distribution or whatever. So,
all of this works, it is done into an open source program and it is performed within the
open compute project foundation. So, it is fully public. So, one we are proposing for the next generation
of systems and upcoming platforms is to cut the firmware into a separate part. So, the left-hand
sign is something that if you are familiar with the ROM, like the PI stage. So, roughly we start
the low-level hardware and put it into a stage where it is going to boot from a networking stack.
So, you are going to tell me, but there is no networking stack on any NVMe drives.
So, while working at the hardware level to add some internet interface is to an NVMe drives,
image, which is signed and validated through the security stack of the ubiquitous loaders.
And then launch from memory, it is retrieved through the network by using the TFTP protocol
or the HTTP protocol. And during the boot process of that specific Linux kind of image,
we are attaching a block storage devices which is coming from the network by using the ISC's
protocol. So, everything is loaded from the network and we are just breaking the storage buyers
and the firmware is totally volatile. So, if you unplug the machine from the data centers and you
try to plug it somewhere else, it won't be able to boot as long as you do not have the
right-hand stack. So, this is also increasing the security if you are hanging over system
to between a user to different end users. And we are also able to that process to integrate
some package manager on the firmware level. So, if you have to run a firmware update,
you don't need to refresh the whole machines and you are not going to break the systems
because you are updating the firmware remotely into a storage area which is in the rig right
operation load. So, we are working as I say on implementing that technology at the NVMe
level. So, what we do is we still have a boot block within every NVMe device.
I don't know if you are familiar with NVMe device architecture but this is very amazing devices.
So, the data center gradient NVMe device currently are coming with a NACOR arm 64B chip
into the controller. Most of them are coming with 4 to 16GB of RAM. So, roughly you can run
Linux locally into every NVMe device that you are running within your data center. It's really
amazing when you think about it. But this is also coming with older complexity.
So, that is why we think that we need to be able to keep this firmware up today. It's also for
security purposes because the firmware which is running into the NVMe device is becoming more
and more complex. And what we have done is when using the CPU with the process done for the
VMC. So, this is exactly the same complex system which is replicated into different devices.
And we use the VMC as a software firmware database. So, we boot the VMC from the network.
The drive is starting up and is issuing a DHCP request to the VMC. And it's gaining the
firmware image associated to that drive into its own memory. And then you can start the device.
So, roughly that whole process will ensure that every time you reboot the host, it will
gather the letters and letters firmware targeting that specific devices. And we can apply that
boot processes to all the PCIX device devices that we have known hope to now. So, one of the key
advantages is during the discovery processes, the client are just going to issue DHCP request
with an incoming device descriptors. And that device descriptors is used to retrieve the right
firmware image to the target. And this is giving us the opportunity to be way much more modular
under the firmware level. So, we are not pushing the firmware. We are just delivering firmware based
on incoming requests from the systems. So, I have a small demo. I hope it works. So, we have
what we call a firmware database manager, which is roughly a top-of-fract, switches, which has
been modified to then if you have found my content to servers. And I have a server which is
based in Houston that I'm currently turning on, I hope it is going to turn home. And you should
be able to see on that screen. I don't know why it's not full screen. Yeah, it should be full screen.
So, on the left-hand side, you see the, why don't you see the screen? Because I need to
exit the presentation mode. So, on the left-hand side, you see the BMC, which is starting up.
So, right now, it has retrieved an IP address on the switch. And it is receiving the firmware image
from the switch to the TFTP protocol. So, as soon as the firmware has been retrieved, it is validating
the feed images. So, which has been encrypted and signed. So, the private key has been validated.
And that's a channel trust from the sequence of trust. The init RAMFS is also signed. So,
we are validating the init RAMFS images, which is containing the iSCSI mount protocol, which is used
to mount the Wi-Fi system from the BMC. All of that is stateless in some way. So, if we turn
off the power, the firmware is no longer inside the machine. So, the only one thing which sits inside
the platform is the bootloader, which is U-Boot, which can be held in it through the, um, the, the,
the internet stack. So, the Linux kernel is booting and we will be seeing that it is issuing
the DHCP request. So, this is just before mounting the root Wi-Fi system. And it is going to
mount the root Wi system just after it's received the IP address. So, this is what we see there.
There is an exclusive mount, which has been issued for devices, which is about 5.2 megabytes.
So, this is also coming with one core advantages. So, there is no space limitation. So, you can
envision to have a firmware with 10 gigabyte of storage or 100 of gigabyte of storage. You are
going to tell me, but why do we need that? Um, I would, I would tell you, we don't know yet
why we may be needing that. But what we, what we know is that the spino is currently
painting the apps, because we need to use compressed, fine system just to make fit on the 32
meg of 64 meg or 120 meg devices, all the software that we need to turn on, complex devices.
So, well, this kind of approach, we can, we can definitely remove that limitation. So, you can have
one gig, 10 gig or even smaller is needed, but there is no space limitation.
Let's wait for the boot to finish. And, currently, done with the presentation.
I don't know if you have any questions about this concept. So, let's start with the
questions. Who want to start? I'll see you too.
OK.
Yes.
I would say that's the same thing when dealing with security.
If something goes wrong anywhere, you're just crude.
So we can secure, I excuse me.
If something goes wrong with the TFTP servers,
what would happen for the security standpoint.
So while using TFTP today,
the main goal is to use HTTP as protocol.
With encryption, and our next generation of BMC
is currently including what we call the security
and play, where we can store security.
Some certificates just to initiate the link.
And what we envision is that we will be using this kind of reports on any devices.
The gentleman at the back, it was the first one to raise his end.
You understand that correctly, yes?
Yeah, it needs the bootloader of the firmware.
But while we look at the firmware complexity from a server,
the bootloader is nothing compared to everything else around that firmware stack.
So in each device, what we are working on is how the bootloader,
which is just turning on the basic hardware,
and issuing the TFTP HTTP as a request.
So we think that this is trying to get a very minimalistic firmware
on building into the device,
and get all the complex software stack from the website.
Okay, so the question is about the PCI Express specification,
which we set up a minimum time just to turn on the devices.
I would say, why would we do right now,
as being part of advanced engineering,
as well trying to prove that it could work,
and if it works, specification I'll make to evolve.
So, and if it makes sense to everybody,
we just get back to the PCI Express specification,
and then let's make that develop.
And right now, we have all the technology at the BMC level
to keep in reset states the CPU complex,
and the PCI Express would complex,
just to wait for all the PCI Express devices
to receive their firmware before releasing the PCI with complex.
So we can do a lot of things.
So we have time out.
I'll be there during the next two days,
so if you have questions, feel free.
Thank you.