search for: cheri

On 22 Jul 2016, at 07:14, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Just tried to set it up there: https://github.com/joker-eph/llvm-unified > (git log —follow is working fine with this setup). > > While it preserves the history fine (I.e. the hashes are identical to the current git), it has a drawback: there isn’t anymore a common ancestor for the

...:) I've been working on a similar tool but it's not ready yet. Looking forward to trying yours! -David James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes: > I'm about to post exactly this tool -- I've been testing it on the > CHERI forks of llvm/clang/lld (lots of history and merges and stuff > there, makes a pretty nice test case!) > > On Mon, Nov 5, 2018 at 1:07 PM David Greene via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Mehdi AMINI <joker.eph at gmail.com> writes: > >...

...Lists.txt` works fine. > >> can you explain the steps for a downstream user who has clones of the llvm and clang repos that were forked at some point in the past, have been periodically merged, and contain a load of commits on top of upstream would migrate to using this? > > Taking cheri as an example, it seems you have a repo for clang and one for llvm (https://github.com/CTSRD-CHERI/clang and https://github.com/CTSRD-CHERI/llvm) > > You can create the unified repo for cheri quite easily, it is roughly doing this: > > 1) checkout llvm, move everything to a llvm subd...

Hello all, I recently finished merging the last 3.5 months of upstream changes into our CHERI LLVM fork and would like to suggest something to both simplify our future merges and also avoid bugs for targets such as AVR that use non-zero pointer address spaces. We make extensive use of address spaces: all our pointers (CHERI capabilities) use address space 200 instead of the default zero to...

...>> >> We haven't started moving to the monorepo yet so while we haven't hit >> the issues in practice yet, we will. Preserving the history from the git >> mirrors would surely be beneficial. >> > > We are also in the same situation for our out-of-tree CHERI backend > (https://github.com/CTSRD-CHERI/llvm <https://github.com/CTSRD-CHERI/llvm> > https://github.com/CTSRD-CHERI/clang <https://github.com/CTSRD-CHERI/clang> > https://github.com/CTSRD-CHERI/lld <https://github.com/CTSRD-CHERI/lld>). I am aware there were some > a...

...lemented?" > > One obvious drawback to such an approach is that dereferencing char* becomes relatively expensive, though for the sort of code being predominantly run on a DSP that might be acceptable. We're using multiple address spaces to describe two pointer representations for CHERI: AS0 is a 64-bit pointer that's represented as an integer, AS200 is a capability (256-bit fat pointer with base, length, permissions, enforced in hardware). We had to fix a few things where LLVM assumes that pointers are integers, but the different size pointers in different address spaces par...

Hi, Thanks for starting this discussion Justin! On 10/31/18 5:22 PM, Justin Bogner via llvm-dev wrote: > Hi all, > > I've spent some time in the last couple of days trying to figure out how > to adopt the [LLVM git monorepo prototype] for an out of tree backend. > TLDR: I'm not convinced that this prototype is the right approach to > converting to the monorepo, and I

...Nicolai > > >> >> Does this sound like a sensible approach? Should I also attempt to >> implement steps 4 and 5 or is 1-3 sufficient? >> >> I would be great if we could land this upstream as it will >> significantly reduce the maintenance burden for our CHERI LLVM and >> should also prevent AVR issues such as e.g. >> https://reviews.llvm.org/rG215dc2e203341f7d1edc4c4a191b048af4ace43d >> >> Thanks, >> Alex >> >> [1] CHERI is currently available for MIPS and RISC-V and will soon be >> available on the upco...

...@acct @acct_admin @hr @receptionist @"Domain Admins" browseable = yes [plotter] copy = printers comment = "Color Pen Plotter" public = no valid users = @engr @truss @"Domain Admins" browseable = yes oink:/usr/local/samba/lib # net rpc group members hr Password: CORP1\cheri CORP1\carl (my user is cheri btw) oink:/usr/local/samba/lib # lpstat -a acct_hp8500 accepting requests since Jan 01 00:00 engr_hp1300 accepting requests since Jan 01 00:00 PDFcreator accepting requests since Jan 01 00:00 plotter accepting requests since Jan 01 00:00 truss_hp4 accepting requests s...

> On Jul 19, 2016, at 09:52, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The IR disruptions for CHERI aren’t that major (the main thing is that we allow alloca’s in different address spaces, but that’s not too difficult to upstream), but it does fail to tick one box that you didn’t list: We would like this feature upstreamed -Matt -------------- next part -------------- An HTML attachment was scr...

...work - DSL Markus@home - DSL Randy@home - cable Josh - dialup, 45/26 Grig - dialup 28.8/22.6 Jeff@work - dsl Jeff@dialup - 33/20 Keena@home - dialup 48/33.1 Kellie@aol - dialup 33/19 am@home - dialup 48/37 (no icecast test yet. ) am@home - dialup ?/? (icecast, didn't get speed test) cherie@home dialup 48/41 <p><p>The pattern is: anyone with a broadband connection can connect and stay connected for hours. Anyone but Cherie with a dialup can connect, load up the buffer in about 10 seconds, listen for about 2 min, and then get dropped. The last 30 seconds are very traumat...

...dd a -A field to the datalayout string which will specify the address space for allocas. IRBuilder::CreateAlloca and company gain a DataLayout argument, and some intrinsics that currently don't support address spaces need to support them. This has been implemented out of tree before before for CHERI. This has also been proposed before but for different reasons: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089706.html My current proposal is more focused than the previous proposal. Instead of allowing specifying address spaces on individual allocas, this restricts it to one chosen ad...

Hi I want to pursue a project based to improve the existing KCoFI method which is the Control Flow integrity method for commodity os. Since KCoFI is a llvm based project I plan to undertake the project to improve the existing KCoFI method. Following are the improvements that I want to pursue: 1. To improve the call graph used in KCoFI. Implement a stronger call graph. 2. Port the KCoFI to

I am a newbie to samba. I have successfully setup a similar samba share on 1 machine in the past. I have everything setup as User access with the pcguest as a guest account. If I create a share to the /tmp, network users can access normally. I created a directory /var/snd and set permissions to be rwxrwxrwx. I changed the smb.conf so that permission were identical to the share for /tmp. I

...ommit themselves to maintain the LLVM back-end to avoid bit-rot, * the back-end is free of contentious features that would mean breaking every other target. For example: * a PIC back-end ticks many of the boxes, but it doesn't have a community around it and would very quickly bit-rot, * the CHERI back-end has an active community and interested developers, but it would disrupt the IR too much, * the BPF back-end has been added mostly as-is and is actively maintained, so gained the status of non-experimental. The main difference between experimental and official is that they get built by de...

On Fri, 7 Sep 2018 at 17:48, Tim Northover <t.p.northover at gmail.com> wrote: > I looked at your diffs and you've only changed one of the functions to > return SDValue(), you need to change lowerFP_TO_SINT itself too. The > one with the store is just there as an optimization; if it doesn't > trigger (because of your diff) then lowerFP_TO_SINT will still create > a

> I might be missing your point here - but don't forget that the local globals are always PC-relative direct loads/stores. I did forget! Thanks for clarifying, now I understand. On Fri, 18 Sep 2020 at 20:51, Evgenii Stepanov <eugenis at google.com> wrote: > > > > On Fri, Sep 18, 2020 at 12:18 PM Mitch Phillips via llvm-dev <llvm-dev at lists.llvm.org> wrote:

.../samba/log.%m max log size = 50 socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192 SO_KEEPALIVE preferred master = Yes domain master = No dns proxy = No guest account = [Oracle] path = /home/oracle valid users = cherie,devinb,admin,mshepard,equser,hjg,dianew,accounting force user = oracle read only = No [Equinox] path = /home/oracle/equinox write list = katherine,cherie,dianew,janice,hjg,sai,accounting force user = oracle [Bills] path = /home/oracle/equinox/Bills...

On 20 Feb 2014, at 06:11, Ivan Godard <ivan at ootbcomp.com> wrote: > It's not just old mainframes, it's some of the newest architecture as well. > The Mill general-purpose architecture (http://ootbcomp.com) has non-integer > pointers and distinct pointer operations too. That LLVM loses pointerhood is > the biggest problem that we have identified while looking into using

...2&action=edit Patch to pass ciphers by name rather than by virtual address The newkeys_(from|to)_blob() functions currently pass a pointer to the static cipher structure between processes. This works as long as pointers are opaque integer data. With upcoming pointer integrity schemes such as CHERI (which ensures pointer derivations are valid with hardware tags) this no longer works and the pointer is instantiated out of thin air from the perspective of the receiving process. Given the current structure of the cipher code, it's trivial to pass the name instead as is done in the attached...