Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Hi Lennart,
debian-ports -> debian-arm
On Fri, Jun 29, 2018 at 5:00 PM Lennart Sorensen
wrote:
> On Fri, Jun 29, 2018 at 10:20:50AM +0100, Luke Kenneth Casson Leighton wrote:
> > in addition, arm64 is usually speculative OoO (Cavium ThunderX V1
> > being a notable exception) which means it's vulnerable to spectre and
> > meltdown attacks, whereas 32-bit ARM is exclusively in-order. if you
> > want to GUARANTEE that you've got spectre-immune hardware you need
> > either any 32-bit system (where even Cortex A7 has virtualisattion) or
> > if 64-bit is absolutely required use Cortex A53.
>
> The Cortex A8, A7 and A5 are in order. The A9, A15, A17 etc are out of
> order execution. So any 32 bit arm worth using is pretty much always
> out of order execution.
Are you sure you're not interchanging A8 and A9, cfr. Linux kernel commit
e388b80288aade31 ("ARM: spectre-v2: add Cortex A8 and A15 validation of the
IBE bit")?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: `new' syscalls for m68k
On Fri, 10 Sep 2004, Geert Uytterhoeven wrote:
> I'm updating the syscall table for m68k...
>
> Below is a patch that adds all syscalls that m68k is currently lacking
> (compared to ia32). However, I'm wondering whether we need all of them:
> - Are sys_sched_[gs]etaffinity() needed for non-SMP?
> - I disabled [sg]et_thread_area() since sys_[gs]et_thread_area() are
> missing. Do we have to implement them, or should we use some other
> method for Thread Local Storage?
> - What about sys_vserver()?
> - What about sys_kexec_load()?
> - Any others we can/should drop?
My conclusion (so far). I will:
- drop sys_sched_[gs]etaffinity() (no SMP on m68k), and sys_kexec_load()
- reserve an entry for sys_vserver()
- add waitid() (2.6.9-rc2)
- rename p{read,write}64() to p{read,write} (cfr. m68knommu in 2.6.8.1-uc0)
Which leaves us with [sg]et_thread_area(): what do the glibc hackers have in
mind for TLS on m68k?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#271878: asm/setup.h non-existent #include on ppc
On Sat, 25 Sep 2004, GOTO Masanori wrote:
> At Sat, 25 Sep 2004 11:58:56 +1000,
> Benjamin Herrenschmidt wrote:
> > On Sat, 2004-09-25 at 11:44, GOTO Masanori wrote:
> > > At Wed, 15 Sep 2004 14:51:00 -0500,
> > > Stephen R. Marenka <[EMAIL PROTECTED]> wrote:
> > > > asm/setup.h contains #include ,
> > > > which is non-existent on ppc.
> > >
> > > Then what's the problem? I guess you didn't get any problems; if so I
> > > close this bug.
> > >
> > > BTW, PPC guys, is it intentional to include asm-m68k/setup.h in
> > > /usr/include/asm-ppc/setup.h ? At a glance, we have no need to
> > > include this header in setup.h.
> >
> > This is historically used by the APUS platform, which I think is an m68k
> > amiga with a ppc CPU stucked in it, but then, ask Geert, he'll know
> > better.
>
> Thanks for your reply. Geert, is it APUS still alive? If so, I guess
> asm-m68k/setup.h is necessary for asm-ppc/setup.h.
Yes, AFAIK APUS is still alive.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
