linuxsh-dev

[linuxsh-dev] SH-4 cache performance improvement

[SUGIOKA T. <su...@it...>]

Hi, all.
I'm using current cvs version of the kernel,
and found that SH7709A(118MHz) executes user-land
programs much faster than SH7750(200MHz).

following patch makes this things better.
my SH7750 board takes about 4.7sec when compile hello.c
before applying this patch, and 2.2sec after patch.

current __flush_page_to_ram invalidates data cache of the page,
but I think write back is sufficient.  

I'm not sure whether this patch causes synonym problem.

Is this approach correct ?

Index: arch/sh/mm/cache.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache.c,v
retrieving revision 1.21
diff -u -r1.21 cache.c
--- arch/sh/mm/cache.c  2000/09/18 05:15:35     1.21
+++ arch/sh/mm/cache.c  2000/12/02 14:38:14
@@ -397,22 +397,21 @@
  */
 void __flush_page_to_ram(void *kaddr)
 {
-       unsigned long phys, addr, data, i;
+       unsigned long v;

-       /* Physical address of this page */
-       phys = PHYSADDR(kaddr);
-
-       jump_to_P2();
-       /* Loop all the D-cache */
-       for (i=0; i<CACHE_OC_NUM_ENTRIES; i++) {
-               addr = CACHE_OC_ADDRESS_ARRAY| (i<<CACHE_OC_ENTRY_SHIFT);
-               data = ctrl_inl(addr);
-               if ((data & CACHE_VALID) && (data&PAGE_MASK) == phys) {
-                       data &= ~(CACHE_UPDATED|CACHE_VALID);
-                       ctrl_outl(data, addr);
-               }
+       for (v = (unsigned long)kaddr; v < (unsigned long)kaddr+PAGE_SIZE; ) {
+               asm volatile(
+                       "ocbwb  @%0\n\t"
+                       "add    %2,%0\n\t"
+                       "ocbwb  @%0\n\t"
+                       "add    %2,%0\n\t"
+                       "ocbwb  @%0\n\t"
+                       "add    %2,%0\n\t"
+                       "ocbwb  @%0\n\t"
+                       "add    %2,%0\n\t"
+                       : "=r"(v)
+                       : "0" (v), "r"(L1_CACHE_BYTES));
        }
-       back_to_P1();
 }

 void flush_page_to_ram(struct page *pg)


-----
SUGIOKA Toshinobu

Re: [linuxsh-dev] Dreamcast RTC

[Philipp R. <pr...@pa...>]

On Fri, Dec 01, 2000 at 04:17:14PM +0100, Marcus Comstedt wrote:
>   Philipp> might want to use the standard trick of doing
> 
>   Philipp> 	do {
>   Philipp> 		val1 = (ctrl_inl(high word)<<16) + (ctrl_inl(low word)&0xffff);
>   Philipp> 		val2 = (ctrl_inl(high word)<<16) + (ctrl_inl(low word)&0xffff);
>   Philipp> 	} while(val1 != val2);
> 
> The code I use check that the value is the same four times in a row.
> That is what the SEGA libraries do, so maybe it's necessary.

>   Philipp> so arch/sh/kernel/time.c: get_rtc_time would look like this;
> 
> What is said here only concerns the Dreamcast.  It should not be
> applied to other machines using the SH cpu.  The Dreamcast RTC is part

Obviously :).  I think we still need to find a good solution for that problem,
preferrably one that doesn't live in arch/.

If you (i.e. all the people working on DC) plan on merging your work soon,
I'd propose moving the RTC code into a separate file and referencing it
through the machvec for generic builds (of course it's questionable how
much sense generic builds make for superh).

Re: [linuxsh-dev] Dreamcast RTC

[M. R. B. <ma...@uw...>]

On Fri, 1 Dec 2000, Philipp Rumpf wrote:

> On Thu, Nov 30, 2000 at 06:34:51PM -0600, M. R. Brown wrote:
> 
> > I'm currently working on host-tools and I have a patch to newlib for
> > gettimeofday (simply adds 20 years to the RTC val to get the Unix epoch of
> > Jan. 1, 1970).  I'll post the code when I get to my workstation, tommorow.
> 
> subtract, I hope.
> 

Er, oops, yes I meant subtract.

> so arch/sh/kernel/time.c: get_rtc_time would look like this;
> 
> static unsigned long get_rtc_time(void)
> {
> 	unsigned long val1, val2;
> 
> 	do {
> 		val1 = (ctrl_inl(high word)<<16) + (ctrl_inl(low word)&0xffff);
> 		val2 = (ctrl_inl(high word)<<16) + (ctrl_inl(low word)&0xffff);
> 	} while(val1 != val2);
> 
> 	/* should be date -d 'jan 1 0000 1950' '+%s'. */
> 	val1 -= 631152000;
> 
> 	return val1;
> }
> 
> 

I was thinking of #ifdef'ing the Dreamcast RTC code inside various
CONFIG_SH_DREAMCAST macros as it isn't standard SH4 stuff.  But other than
that your code looks good.

M. R.

Re: [linuxsh-dev] Dreamcast RTC

[Marcus C. <ma...@id...>]

>>>>> "Philipp" == Philipp Rumpf <pr...@pa...> writes:


  Philipp> Are the counters latched when you read the first register ?  Otherwise you

Nope.


  Philipp> might want to use the standard trick of doing

  Philipp> 	do {
  Philipp> 		val1 = (ctrl_inl(high word)<<16) + (ctrl_inl(low word)&0xffff);
  Philipp> 		val2 = (ctrl_inl(high word)<<16) + (ctrl_inl(low word)&0xffff);
  Philipp> 	} while(val1 != val2);

The code I use check that the value is the same four times in a row.
That is what the SEGA libraries do, so maybe it's necessary.


  Philipp> so arch/sh/kernel/time.c: get_rtc_time would look like this;

What is said here only concerns the Dreamcast.  It should not be
applied to other machines using the SH cpu.  The Dreamcast RTC is part
of the AICA chip, not of the cpu.


  Philipp> 	val1 -= 631152000;

Yup.


  // Marcus

Re: [linuxsh-dev] Dreamcast RTC

[Philipp R. <pr...@pa...>]

On Thu, Nov 30, 2000 at 06:34:51PM -0600, M. R. Brown wrote:
> The Dreamcast RTC is a 32-bit seconds counter at 0xa0710000 and 0xa0710004
> (32-bit registers).  a0710000 contains the high 16-bits in its LSW and
> a0710004 contains the low 16-bits.  The epoch or zero value (i.e. when the
> RTC starts counting) is January 1, 1950 00:00.

Are the counters latched when you read the first register ?  Otherwise you
might want to use the standard trick of doing

	do {
		val1 = (ctrl_inl(high word)<<16) + (ctrl_inl(low word)&0xffff);
		val2 = (ctrl_inl(high word)<<16) + (ctrl_inl(low word)&0xffff);
	} while(val1 != val2);

> I'm currently working on host-tools and I have a patch to newlib for
> gettimeofday (simply adds 20 years to the RTC val to get the Unix epoch of
> Jan. 1, 1970).  I'll post the code when I get to my workstation, tommorow.

subtract, I hope.

so arch/sh/kernel/time.c: get_rtc_time would look like this;

static unsigned long get_rtc_time(void)
{
	unsigned long val1, val2;

	do {
		val1 = (ctrl_inl(high word)<<16) + (ctrl_inl(low word)&0xffff);
		val2 = (ctrl_inl(high word)<<16) + (ctrl_inl(low word)&0xffff);
	} while(val1 != val2);

	/* should be date -d 'jan 1 0000 1950' '+%s'. */
	val1 -= 631152000;

	return val1;
}

Re: [linuxsh-dev] Dreamcast RTC

[M. R. B. <ma...@uw...>]

The Dreamcast RTC is a 32-bit seconds counter at 0xa0710000 and 0xa0710004
(32-bit registers).  a0710000 contains the high 16-bits in its LSW and
a0710004 contains the low 16-bits.  The epoch or zero value (i.e. when the
RTC starts counting) is January 1, 1950 00:00.

I'm currently working on host-tools and I have a patch to newlib for
gettimeofday (simply adds 20 years to the RTC val to get the Unix epoch of
Jan. 1, 1970).  I'll post the code when I get to my workstation, tommorow.

Heh, Rene, we really should collaborate :).

M. R.

On Thu, 30 Nov 2000, Rene Malmgren wrote:

> Hi everyone
> 
> I have bean working on my own Linux port (well not so own) port for the
> DC. And I think I have managed to remove most of the problems. But one
> still alludes me. The DC doesn't use std RTC. Which means that the clock
> doesn't work out of the box. Does anyone know where one can get some
> information on the DC RTC. Preferably with some background information
> on how it works. Up to now I have managed to find some information
> written by Marcus (http://mc.pp.se/dc) on the Netbsd mailing list. So I
> have managed to Iron out some of the problems but there are still some
> left. I have also managed to get Dan's libdream to work (with some
> hacking) so I'll probably use his timer routines eventually.
> 
> /Rene
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
> 
> 

Re: [linuxsh-dev] Big Endian

[Mitch D. <md...@po...>]

Chao-yi Lang wrote:
> 
> Hi.
> Has anyone tried the gcc 2.95.2 and glibc 2.1.3 using the Big Endian?

Hi Chao-yi,

I think just about everyone who is working on Linux for SuperH
is doing so in little-endian mode.  So there might be undiscovered
problems with big-endian mode.

I assume that if you're talking about glibc, you want to use
Linux on SuperH, rather than building standalone embedded
programs for the SuperH.  I would recommend against using plain
gcc 2.95.2 for this.  Instead I would suggest one of the following:

 - Using the versions of the toolchain that are stored in
   our CVS repository, and following Stuart Menefy's instructions.

     http://linuxsh.sourceforge.net/docs/getting-source.php3
     http://linuxsh.sourceforge.net/docs/building-source.php3
     
 - Trying the newer toolchain, according to Niibe-san's directions:

     http://www.geocrawler.com/archives/3/3076/2000/10/0/4574495/
     http://www.geocrawler.com/lists/3/SourceForge/3076/25/4701592/
     http://www.geocrawler.com/lists/3/SourceForge/3076/25/4701690/
     http://www.geocrawler.com/lists/3/SourceForge/3076/25/4701966/

Regards,

Mitch.

[linuxsh-dev] Dreamcast RTC

[Rene M. <re...@dr...>]

Hi everyone

I have bean working on my own Linux port (well not so own) port for the
DC. And I think I have managed to remove most of the problems. But one
still alludes me. The DC doesn't use std RTC. Which means that the clock
doesn't work out of the box. Does anyone know where one can get some
information on the DC RTC. Preferably with some background information
on how it works. Up to now I have managed to find some information
written by Marcus (http://mc.pp.se/dc) on the Netbsd mailing list. So I
have managed to Iron out some of the problems but there are still some
left. I have also managed to get Dan's libdream to work (with some
hacking) so I'll probably use his timer routines eventually.

/Rene

Re: [linuxsh-dev] Re: bad alignment fixup

[Greg B. <gb...@po...>]

G'day

Bryan Rittmeyer wrote:
> 
> Basically, I think the problem was with code like this:
> 
> ---
> #include <stdio.h>
> [...]

The compiler I have here (cvs snapshot from about 2 months ago)
generates perfectly-well aligned  assembler for this C code:


	.data
	.align 1			! bleep aligned to sizeof(short)
	.type	 bleep.3,@object
	.size	 bleep.3,6
bleep.3:
	.short	1
	.short	2
	.short	3
	.align 2			! bloop aligned to sizeof(long)
	.type	 bloop.4,@object
	.size	 bloop.4,8
bloop.4:
	.byte	1
	.zero	3			! bloop.boom aligned to sizeof(long)
	.long	2


> Please note: we're not using the latest toolchain here, and therefore,
> can't use the latest kernels. I would hate to go chasing after an
> already fixed bug, so I will look into testing the other engineer's code
> with the latest stuff as soon as possible.

  I know it's hard to keep up with these things, but in the long
run it's worth the effort.

> > It sends a SIGSEGV.  I'm currently looking into adding a siginfo struct
> > with sufficient information to emulate unaligned accesses efficiently.

  My two cents worth on the unaligned accesses issue.

<RANT>
Just Say No to unaligned accesses.  Unaligned accesses should only
happen
as the result of bad code or compiler bugs, both of which need to have
their cause fixed and *not* their symptoms covered up with bletcherous
bandaids like exception handlers which decode instructions to fake
unaligned accesses.  Decoding instructions is a job for the CPU (and
debuggers), and should *not* be part of the normal operation of the
system.  The fact that the Linux networking stack currently relies on
unaligned accesses in rare circumstances is a bletcherous relic of its
i386 heritage and should be hunted down, shot, and its head stuffed
and mounted to remind people of how to write portable code.  As long
as the kernel has fancy exception handlers which allow the networking
code to get away with this behaviour, it will only encourage the
disease to spread.
</RANT>

  Ok, I feel better now ;-)

  Seriously now, I'm concerned about the DoS aspect of relying on
unaligned access fixups in the networking stack.  Data-dependant
fixups in general are fine if used to handle events generated by
local processes, because they're self-limiting.  Send the process
SIGBUS or whatever and the problem goes away.  But fixups triggered
by network packets are not self-limiting in this way; it may be
possible to bring a machine to its knees either maliciously or
accidentally.

  The device I'm working on does wireless networking and might
in the future be sold for law enforcement or military applications.
With portable wireless devices you can't in general "protect the
devices with a router"; they have to be reasonably robust.  It
can't just go gaga when strange packets comes along.

  What I'm saying is, in the long term a network stack which
is DoS-vulnerable on SH4 is *not* acceptable.

  The only long-term solution I see is to remove the fixups from
the unaligned access exception handler and fix the brokenness
in the networking code


  Finally some practical experience which might help others.  I
recently had to debug Ben Reed's airo.c driver for the Aironet 4800
wireless ethernet card.  The machine was responding to ARP but
crashing on the first ping packet.  It turns out that inserting the
following line in the receive interrupt handler "fixed" it:

@@ -942,6 +959,7 @@
 				apriv->stats.rx_dropped++;
 			} else {
 				char *buffer;
+				skb_reserve(skb,2);	/* IP headers on 16 byte boundaries */
 				buffer = skb_put( skb, len );
 		                bap_setup( apriv, fid, 0x36+sizeof(len), BAP0
); 								bap_read( apriv, (u16*)buffer, len, BAP0 );

  Quite a few of the Linux network device drivers do this.  It's
an example of a bandaid which works around alignment problems
in a _relatively_ unbletcherous manner.  Obviously its a short
term solution only, but I hope it might help someone.

Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] Big Endian

[Chao-yi L. <la...@is...>]

Hi.
Has anyone tried the gcc 2.95.2 and glibc 2.1.3 using the Big Endian?

Thanks in advance.

Chaoyi

Re: [linuxsh-dev] Re: bad alignment fixup

[Philipp R. <pr...@pa...>]

On Tue, Nov 28, 2000 at 12:36:12PM -0800, Bryan Rittmeyer wrote:
> Philipp Rumpf wrote:
> 
> > gas warns about unaligned .longs.  gcc should never generate unaligned
> > accesses unless you use weird casting or assembler code.
> 

> Basically, I think the problem was with code like this:

That code definitely should compile and work fine without causing unaligned
accesses.

> I will test that exact snippet on the SH4 and see if we are still having
> problems. If we are, I guess it's due to the linker either not aligning
> structtwo or not aligning boom within structtwo?

s/linker/compiler/.   It would be a GCC bug, yes.

> Just to make sure--when a process catches, say, a SIGSEGV and hasn't
> installed a special handler for it, it's up to the shell to display the
> termination message?

yes.

Re: [linuxsh-dev] Re: bad alignment fixup

[Bryan R. <br...@ix...>]

Philipp Rumpf wrote:

> gas warns about unaligned .longs.  gcc should never generate unaligned
> accesses unless you use weird casting or assembler code.

Basically, I think the problem was with code like this:

---
#include <stdio.h>

struct structone
{
  unsigned short foo;
  unsigned short bar;
  unsigned short moo;
};

struct structtwo
{
  unsigned char blah;
  unsigned long boom;
};

int main(void)
{
        static struct structone bleep = {1, 2, 3};
        static struct structtwo bloop = {1, 2};   

        bleep.foo=1;
        bloop.boom=2;

        printf("%ld",bloop.boom);
        return 0;
}
---

I will test that exact snippet on the SH4 and see if we are still having
problems. If we are, I guess it's due to the linker either not aligning
structtwo or not aligning boom within structtwo?

As far as I know that code is standard, valid ANSI C.

Please note: we're not using the latest toolchain here, and therefore,
can't use the latest kernels. I would hate to go chasing after an
already fixed bug, so I will look into testing the other engineer's code
with the latest stuff as soon as possible.

> shouldn't happen.

indeed.

> It sends a SIGSEGV.  I'm currently looking into adding a siginfo struct
> with sufficient information to emulate unaligned accesses efficiently.

Ok... in this particular case the unaligned access was coming from a
child pthread. Perhaps the pthread parent caught the SIGSEGV and zombied
all the children? (sounds like a b-rate horror film)

> If you don't see your process's exit status your test environment is broken.

Just to make sure--when a process catches, say, a SIGSEGV and hasn't
installed a special handler for it, it's up to the shell to display the
termination message? I am using the BusyBox shell which may not do so,
in which case I will submit a patch to those guys to at least handle
SIGSEGV...

> if the process doesn't die with SEGV there's another kernel bug.

One which may have already been fixed. I will further investigate this
issue when I get some spare time (heh, in a year or two).

Thanks for the reply,

Bryan

-- 
Bryan Rittmeyer
mailto:br...@ix...
Ixia Communications
26601 W. Agoura Rd.
Calabasas, CA 91302

Re: [linuxsh-dev] #define pippo(X)....

[Greg B. <gb...@po...>]

Fabio Giovagnini wrote:
> 
> Hi , if I write :
> #define pippo(X) \
>                 X=4
> 
> the compiler (core 2.95.2) tells me "stray '\' in program."
> Does a pre-processor option exists to tell the compiler to parse
> correctly the expanded macros?

  You have stray whitespace after the \ character.  The gcc-core
from CVS handles this just fine.

Greg.
-- 
These are my opinions not PPIs.

Re: [linuxsh-dev] Re: bad alignment fixup

[Mitch D. <md...@po...>]

Philipp Rumpf wrote:
> 
> On Sun, Nov 26, 2000 at 12:40:28PM +1100, Mitch Davis wrote:
> > to make sure we never do by not supporting the emulation of userspace
> > unaligned instructions.  (Just do a printk and a SEGV).
> 
> SIGBUS is the traditional signal.

Right you are.

Regards,

Mitch.

Re: [linuxsh-dev] Re: bad alignment fixup

[Philipp R. <pr...@pa...>]

On Sun, Nov 26, 2000 at 12:40:28PM +1100, Mitch Davis wrote:
> to make sure we never do by not supporting the emulation of userspace
> unaligned instructions.  (Just do a printk and a SEGV).

SIGBUS is the traditional signal.

Re: [linuxsh-dev] Re: bad alignment fixup

[Mitch D. <md...@po...>]

NIIBE Yutaka wrote:
> 
> Philipp Rumpf wrote:
>  > I think we have four groups of accesses we might emulate or not:
>  > 1. kernel accesses to kernel memory
>  > 2. kernel accesses to user memory
>  > 3. user accesses to user memory, using "standard" instructions
>  > 4. user accesses to user memory, using non-standard instructions
> 
> Thanks for the summary.
> 
> My opinion is we only need #1.
...
> At least, we should output warning message when handling userspace
> unaligned access.

I agree.  If there was a non-trivial body of userspace code which
did unaligned access, I would consider #3 and #4 a necessary but
evil kludge.  But we don't, and I hope we never do.  And I'd like
to make sure we never do by not supporting the emulation of userspace
unaligned instructions.  (Just do a printk and a SEGV).

Just my two cents worth.  You can collect the other 2 cents here.

  http://www.geocrawler.com/lists/3/SourceForge/3076/50/4621975/

At the time the response to this was, "it's only for kernel mode".
Now it appears it's not, and my original comments still stand.

Regards,

Mitch.

Re: [linuxsh-dev] Re: bad alignment fixup

[NIIBE Y. <gn...@ch...>]

Philipp Rumpf wrote:
 > I think we have four groups of accesses we might emulate or not:
 > 1. kernel accesses to kernel memory
 > 2. kernel accesses to user memory
 > 3. user accesses to user memory, using "standard" instructions
 > 4. user accesses to user memory, using non-standard instructions

Thanks for the summary.

My opinion is we only need #1.

 > We definitely need to emulate 1) - at least unless someone convinces the
 > network guys to drop that requirement.

Is there anyone try to use ISOFS?  Takashi Yoshii said there're plenty
of code which might cause unaligned access.

For #2, #3, and #4, it would be interesting problem to solve,
technically, to supports the feature.  However, when people (of user
space application) rely on such a feature, in the long run, bad
quality would remain forever.

At least, we should output warning message when handling userspace
unaligned access.
-- 

Re: [linuxsh-dev] Re: bad alignment fixup

[NIIBE Y. <gn...@ch...>]

David Howells wrote:
 > Here's another patch to traps.c. this one uses set_fs() and changes all
 > __copy_user() to copy_from_user() or copy_to_user() to protect against
 > userspace programs trying to be sneaky and access kernel space on unaligned
 > addresses.

Thanks, installed.
-- 

Re: [linuxsh-dev] Re: bad alignment fixup

[Jesper S. <js...@re...>]

>>>>> "Philipp" == Philipp Rumpf <pr...@pa...> writes:

Philipp> On Fri, Nov 24, 2000 at 09:15:39AM +0900, NIIBE Yutaka wrote:
>> Philipp Rumpf wrote: > On Thu, Nov 23, 2000 at 04:50:26PM +0000,
>> David Howells wrote: > > > user code to emulate unaligned accesses,
>> which can be written as someone > > > actually found a userspace
>> programs that needs them.  > > > > We have the code anyway to fix
>> up kernel accesses.  > > no.  we have the code for the few insns
>> actually used by the kernel, and it > can go away as soon as
>> someone convinced DaveM having the network stack use > unaligned
>> accesses is silly.
>> 
>> I also think that supporting kernel unaligned access is not good
>> idea, but Jesper said that DoS possibility (we should check), which
>> I care.

Philipp> We currently need kernel unaligned accesses for weird network
Philipp> protocols; there's also a remote exploit possibility.  As for
Philipp> the DoS, I think what Jesper meant was that if you do emulate
Philipp> unaligned accesses, userspace can keep doing
Philipp> kernel->user->kernel transitions, which is true anyway.

That's what I meant. But on second thought, I guess the exit path goes
past the schedule code, doesn't it? If so, it's not an issue. My
concern was if there was a separate path in and out of the kernel to
the fixup code - but that's probably not the case.

Jesper

Re: [linuxsh-dev] Re: bad alignment fixup

[Philipp R. <pr...@pa...>]

On Fri, Nov 24, 2000 at 09:15:39AM +0900, NIIBE Yutaka wrote:
> Philipp Rumpf wrote:
>  > On Thu, Nov 23, 2000 at 04:50:26PM +0000, David Howells wrote:
>  > > > user code to emulate unaligned accesses, which can be written as someone
>  > > > actually found a userspace programs that needs them.
>  > > 
>  > > We have the code anyway to fix up kernel accesses.
>  > 
>  > no.  we have the code for the few insns actually used by the kernel, and it
>  > can go away as soon as someone convinced DaveM having the network stack use
>  > unaligned accesses is silly.
> 
> I also think that supporting kernel unaligned access is not good idea,
> but Jesper said that DoS possibility (we should check), which I care.

We currently need kernel unaligned accesses for weird network protocols;
there's also a remote exploit possibility.  As for the DoS, I think what
Jesper meant was that if you do emulate unaligned accesses, userspace can
keep doing kernel->user->kernel transitions, which is true anyway.

>  > Do it correctly or don't do it at all.  "We emulate all unaligned memory
>  > accesses except 3 or 4 we didn't bother with" isn't a sensible rule.
> 
> Agreed.
> 
> I installed the patch hoping we could do it correctly.  If it's
> difficult, and we can't see enough rationale about DoS possibility,
> it's better to drop the kernel unaligned access support.

I think we have four groups of accesses we might emulate or not:
1. kernel accesses to kernel memory
2. kernel accesses to user memory
3. user accesses to user memory, using "standard" instructions
4. user accesses to user memory, using non-standard instructions

We definitely need to emulate 1) - at least unless someone convinces the
network guys to drop that requirement.

I don't think we need to emulate 2) - there is nothing wrong, I think, with
returning -EFAULT for unaligned user space pointers passed to syscalls that
try get_user or put_user (we'd lose the atomicity anyway).

Emulating 2) adds some bloat to the unaligned access handler (__copy_user
instead of memcpy).

I don't think we need to emulate 3) either, and I think it's a terrible
precedent to emulate 3) but not 4);  emulating 3) adds yet another bit
of bloat to the unaligned access handler (copy_*_user instead of
__copy_user).  emulating 4) means adding support for many new instructions,
and I'm not sure all of them can be emulated satisfactorily.

> Local user access is more likely than network attack.  Network attack
> can be handled by other devices and feature (router, firewall rules), 
> so we should have more care for local user access.

I don't think there are any security holes left in the patch posted
yesterday (which emulates 1, 2, and 3), but I need to have another look.

Re: [linuxsh-dev] Re: bad alignment fixup

[NIIBE Y. <gn...@ch...>]

Philipp Rumpf wrote:
 > On Thu, Nov 23, 2000 at 04:50:26PM +0000, David Howells wrote:
 > > > user code to emulate unaligned accesses, which can be written as someone
 > > > actually found a userspace programs that needs them.
 > > 
 > > We have the code anyway to fix up kernel accesses.
 > 
 > no.  we have the code for the few insns actually used by the kernel, and it
 > can go away as soon as someone convinced DaveM having the network stack use
 > unaligned accesses is silly.

I also think that supporting kernel unaligned access is not good idea,
but Jesper said that DoS possibility (we should check), which I care.

 > Do it correctly or don't do it at all.  "We emulate all unaligned memory
 > accesses except 3 or 4 we didn't bother with" isn't a sensible rule.

Agreed.

I installed the patch hoping we could do it correctly.  If it's
difficult, and we can't see enough rationale about DoS possibility,
it's better to drop the kernel unaligned access support.

Local user access is more likely than network attack.  Network attack
can be handled by other devices and feature (router, firewall rules), 
so we should have more care for local user access.
-- 

Re: [linuxsh-dev] Re: bad alignment fixup

[Philipp R. <pr...@pa...>]

On Thu, Nov 23, 2000 at 04:53:37PM +0000, David Howells wrote:
> 
> > What version of insmod are you using?
> 
> insmod v2.3.15
> 
> > Is the problem being caused by loading a specific module?
> 
> ext2.o
> 
> > I'm also not keen on having the kernel fix up unaligned accesses for me, as
> > if I have a bug in my program I want to know about it.
> 
> Hence it logs the first 10 fixups it makes.

Insufficient for development purposes.  At least you need something like
alpha's UAC_SIGBUS which allow you to go on debugging without a reboot
after the fist 10 unaligned accesses.

Re: [linuxsh-dev] Re: bad alignment fixup

[Philipp R. <pr...@pa...>]

On Thu, Nov 23, 2000 at 03:36:33PM +0000, David Mckay wrote:
> On Nov 23,  2:57pm, pr...@pa... wrote:
> > Subject: Re: [linuxsh-dev] Re: bad alignment fixup
> >
> > On Thu, Nov 23, 2000 at 02:28:57PM +0000, David Howells wrote:
> > >
> > > > and adds unaligned userspace access emulation, which I still think is a
> > > > terribly bad idea;
> > >
> > > insmod can do this a lot.
> >
> > fix insmod.  it seems to work on other architectures that don't support
> > unaligned accesses.
> 
> What version of insmod are you using? I've used it a fair bit here, and have
> seen no problems with it. We are using 2.3.16 plus a few superH specific
> patches. Is the problem being caused by loading a specific module?
> 

> I'm also not keen on having the kernel fix up unaligned accesses for me, as
> if I have a bug in my program I want to know about it. Much of the software
> I work with has to run under different OSes and processors, some of which
> silently truncate the bottom bits when you do unaligned accesses! This is
> not a fun bug to try to track down.

Many CPUs don't architecturally support unaligned accesses.  We're currently
lucky in that Linux doesn't run on those CPUs, or no users use weird network
protocols on them.

> The fact that the i386 handles unaligned accesses for you is the exception
> rather than the rule.

It's also not strictly speaking true;  486 and newer CPUs can generate
unaligned traps if asked to, and KNI requires aligned operands.

The rule for Linux definitely seems to be not to emulate unaligned user
accesses.  The exception is alpha, which seems to have some architectural
support for unaligned accesses.  SuperH doesn't.

Re: [linuxsh-dev] Re: bad alignment fixup

[Philipp R. <pr...@pa...>]

On Thu, Nov 23, 2000 at 05:55:40PM +0000, David Woodhouse wrote:
> 
> pr...@pa... said:
[dropped the network stack discussion, as it's offtopic here]

> pr...@pa... said:
> >  Do it correctly or don't do it at all.  "We emulate all unaligned
> > memory accesses except 3 or 4 we didn't bother with" isn't a sensible
> > rule.
> 
> It's correct, or certainly getting there. It's not _complete_ but I'm sure

generating SEGV for unknown unaligned instructions isn't correct.

> someone will contribute the missing insns, even if _we_ don't actually get 
> round to it.

I think that would add prohibitively large amounts of code, and quite
possibly new security holes.

> pr...@pa... said:
> >  which makes using a syscall return value constant confusing.
> 
> It doesn't confuse me. Standard error numbers are used _internally_ 
> throughout the kernel, even where they're not actually being returned to 
> userspace.

I can remember no case where it's impossible for userspace to see the error,
except for module_init until a few versions ago. 

> Are there other causes of address error in SH-[45]?

unprivileged accesses to 0x80000000 .. 0xffffffff

Re: [linuxsh-dev] Re: bad alignment fixup

[David W. <dw...@in...>]

pr...@pa... said:
>  no.  we have the code for the few insns actually used by the kernel,
> and it can go away as soon as someone convinced DaveM having the
> network stack use unaligned accesses is silly. 

Not going to happen, mainly because having the network stack use unaligned
access _isn't_ silly.

Unaligned accesses in the network stack are a _very_ uncommon case, but a 
case which we have be able to deal with nonetheless. Having checks for 
alignment in all the networking fast paths would be insane.

What we're doing here is very similar to what we do in __copy_user() - 
optimising the common case and letting the CPU raise an exception so we can 
fix up the rarer cases. Doing the check in software is silly when the CPU 
can do it for you instead.


pr...@pa... said:
>  Do it correctly or don't do it at all.  "We emulate all unaligned
> memory accesses except 3 or 4 we didn't bother with" isn't a sensible
> rule.

It's correct, or certainly getting there. It's not _complete_ but I'm sure
someone will contribute the missing insns, even if _we_ don't actually get 
round to it.

pr...@pa... said:
>  which makes using a syscall return value constant confusing.

It doesn't confuse me. Standard error numbers are used _internally_ 
throughout the kernel, even where they're not actually being returned to 
userspace.


pr...@pa... said:
>  address error doesn't necessarily mean unaligned access.

P485 of the SH-3/SH-3E/SH3-DSP Programming Manual says:

"Address errors are caused by instruction fetches and by data reads or
writes. Fetching an instruction from an odd address or fetching an
instruction from an on-chip peripheral register causes an instruction fetch
address error. Accessing word data from other than a word boundary,
accessing longword data from other than a longword boundary, and accessing
an on-chip peripheral register 8-bit space by longword cause a read or write
address error."

OK, so PC could be the address of an on-chip peripheral register. Sick, but
vaguely possible. I'd still say that such is a 'should never happen' 
event, but I have no particular attachment to that comment so if it really 
offends you it can go.

Are there other causes of address error in SH-[45]?

Perhaps we also need to explicitly check for the case of a wrongly-sized 
access to the on-chip peripheral space. Simply refusing to fix up any 
exceptions on accesses to on-chip peripheral space should be sufficient.

--
dwmw2