GSoC 2012 - 32 bit API for 64 bit kernel

[Samuel J. Greear]

--20cf303bf94ccc53a804bc32151c
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Mar 25, 2012 at 3:19 PM, Ivan Sichmann Freitas <
ivansichfreitas at gmail.com> wrote:

> On Thu, Mar 22, 2012 at 12:40:07AM -0300, Ivan Sichmann Freitas wrote:
> > Hi,
> >
> > I'm a computer engineering student at Unicamp (brazilian university),
> > interested in compilers and computer architecture (and most low level
> > stuff), and the idea of implementing the ABI for running 32 bit
> > applications on a 64 bit kernel seems interesting and challenging.
> >
> > I have moderated knowledge of C, OS principles and Linux systems, some
> > experience with FreeBSD, I've already cloned dragonfly's git repository
> > and I'm studying the code to come with a planned roadmap of what would
> > be my work in gsoc. You can find me with the username ISF in github and
> > IRC networks (efnet, freenode and oftc).
>
> So, as far as I understood the idea and dragonfly's code:
>    - since the current code was created to be of only one architecture,
>      I would need to create a set of *_32 syscalls (will they maintain
>      the same numeric value in syscalls.master in relation of its 64
>      bits counterparts?).
>    - it's not clear to me how I will implement the control bits to
>      indicate 32 bit execution.
>    - I'm thinking in a way to implement this without breaking the
>      current 64 bit abi for existing applications, any thoughts on
>      that?
>
> As a draft of my planned roadmap:
>    - completely understand the syscalls' handling in the kernel
>    - analyze the difference of 32 and 64 elf formats and how it affects
>      the loader
>    - plan the implementation (try to avoid abi breakage and pitfalls)
>    - do it
>
> (not sure how much time for each step, but the 2 firsts should be quick)
>
> I would appreciate any feedback on this.
>
> --
> Ivan Sichmann Freitas
> GNU/Linux user #509059
>

You basically have it. Basically I think what it boils down to is a 32-bit
syscall layer that maps/translates/casts/converts as the case may be the
32-bit arguments to 64-bit arguments, calls the native 64-bit version of
the system call and then translates the return value as-necessary on the
way back. (This is probably mostly just a lot of grunt work, once the
framework is in place).

We have a mechanism for executing a binary with a specific kernel system
call vector, we use this to support Linux binaries, for example. You just
need to create a 32-bit vector, or re-use the main vector built with 32-bit
types, or similar for the 64-bit kernel and make sure that it is what gets
used when a 32-bit binary is executed.

FreeBSD has done this and the whole approach should be extremely similar,
it would be worth looking at what they have done and it is likely worth
simply copying their approach.

I will note that it is possible this project exceeds the scope of GSoC, but
that as long as it is done well even as little as 30 or 40% syscall
coverage is still probably quite useful and may be capable of running many
simple binaries. As a contingency, you should probably plan to create some
documentation about the translation layer so that if you don't achieve
complete system call coverage or if people add system calls in the future
it is easy to identify how system calls are to be added to the translation
-- assuming it isn't all automatic.

Sam

--20cf303bf94ccc53a804bc32151c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Sun, Mar 25, 2012 at 3:19 PM, Ivan Sichmann F=
reitas <span dir=3D"ltr"><<a href=3D"mailto:ivansichfreitas at gmail.com">i=
vansichfreitas at gmail.com</a>></span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div class=3D"im">On Thu, Mar 22, 2012 at 12:40:07AM -0300, Ivan Sichmann F=
reitas wrote:<br>
> Hi,<br>
><br>
> I'm a computer engineering student at Unicamp (brazilian universit=
y),<br>
> interested in compilers and computer architecture (and most low level<=
br>
> stuff), and the idea of implementing the ABI for running 32 bit<br>
> applications on a 64 bit kernel seems interesting and challenging.<br>
><br>
> I have moderated knowledge of C, OS principles and Linux systems, some=
<br>
> experience with FreeBSD, I've already cloned dragonfly's git r=
epository<br>
> and I'm studying the code to come with a planned roadmap of what w=
ould<br>
> be my work in gsoc. You can find me with the username ISF in github an=
d<br>
> IRC networks (efnet, freenode and oftc).<br>
<br>
</div>So, as far as I understood the idea and dragonfly's code:<br>
 =A0 =A0- since the current code was created to be of only one architecture=
,<br>
 =A0 =A0 =A0I would need to create a set of *_32 syscalls (will they mainta=
in<br>
 =A0 =A0 =A0the same numeric value in syscalls.master in relation of its 64=
<br>
 =A0 =A0 =A0bits counterparts?).<br>
 =A0 =A0- it's not clear to me how I will implement the control bits to=
<br>
 =A0 =A0 =A0indicate 32 bit execution.<br>
 =A0 =A0- I'm thinking in a way to implement this without breaking the<=
br>
 =A0 =A0 =A0current 64 bit abi for existing applications, any thoughts on<b=
r>
 =A0 =A0 =A0that?<br>
<br>
As a draft of my planned roadmap:<br>
 =A0 =A0- completely understand the syscalls' handling in the kernel<br=
>
 =A0 =A0- analyze the difference of 32 and 64 elf formats and how it affect=
s<br>
 =A0 =A0 =A0the loader<br>
 =A0 =A0- plan the implementation (try to avoid abi breakage and pitfalls)<=
br>
 =A0 =A0- do it<br>
<br>
(not sure how much time for each step, but the 2 firsts should be quick)<br=
>
<br>
I would appreciate any feedback on this.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Ivan Sichmann Freitas<br>
GNU/Linux user #509059<br>
</div></div></blockquote></div><br><div>You basically have it. Basically I =
think what it boils down to is a 32-bit syscall layer that maps/translates/=
casts/converts as the case may be the 32-bit arguments to 64-bit arguments,=
 calls the native 64-bit version of the system call and then translates the=
 return value as-necessary on the way back. (This is probably mostly just a=
 lot of grunt work, once the framework is in place).</div>
<div><br></div><div>We have a mechanism for executing a binary with a speci=
fic kernel system call vector, we use this to support Linux binaries, for e=
xample. You just need to create a 32-bit vector, or re-use the main vector =
built with 32-bit types, or similar for the 64-bit kernel and make sure tha=
t it is what gets used when a 32-bit binary is executed.</div>
<div><br></div><div>FreeBSD has done this and the whole approach should be =
extremely similar, it would be worth looking at what they have done and it =
is likely worth simply copying their approach.</div><div><br></div><div>
I will note that it is possible this project exceeds the scope of GSoC, but=
 that as long as it is done well even as little as 30 or 40% syscall covera=
ge is still probably quite useful and may be capable of running many simple=
 binaries. As a contingency, you should probably plan to create some docume=
ntation about the translation layer so that if you don't achieve comple=
te system call coverage or if people add system calls in the future it is e=
asy to identify how system calls are to be added to the translation -- assu=
ming it isn't all automatic.</div>
<div><br></div><div>Sam</div>

--20cf303bf94ccc53a804bc32151c--