search for: hardbounds

On Tue, Sep 10, 2013 at 1:47 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 10 Sep 2013, at 10:28, Kostya Serebryany <kcc at google.com> wrote: > > > > > > > > > On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall < > David.Chisnall at cl.cam.ac.uk> wrote: > > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at

On 10 Sep 2013, at 12:13, Kostya Serebryany <kcc at google.com> wrote: > Well, ok, you can treat this as a 192-bit fat pointer, but AFAICT this is not the real intention of the MPX developers > since a fat pointer will break all ABIs, and MPX tries to preserve them. MPX is an implementation of the HardBound concept from UPenn, where this was a design goal (see also their 'low-fat

When RHEL8 and CentOS8 were released, I was looking forward to setting up SAMBA as a AD DC server for CentOS8. But when I lifed the hood on the samba.spec file I found the option to build the samba-dc binary rpm has been disabled for rhel family builds. Apparently Red Hat does not want to support a unified SAMBA AD DC environment. I believe we have all of the componentns needed to set up a fully

Hello, As far as I know, there is no MPX pass in LLVM (though the x86-64 backend already declares MPX registers and instructions). I wonder if anyone is currently working on the LLVM pass for MPX instrumentation, similar to Pointer Checker in gcc. If yes, could anyone elaborate on the status and accessability to other researchers? And if any help is needed? Prof. Santosh Nagarakatte, the author

On 10 Sep 2013, at 10:28, Kostya Serebryany <kcc at google.com> wrote: > > > > On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote: > > > How did you come with 320 bits? > > 320=64*4+64, which is the size of the metadata table entry plus

On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote: > > > How did you come with 320 bits? > > 320=64*4+64, which is the size of the metadata table entry plus pointer > size, > > > Sorry, that should have been 192. The specification allows the

On 15/08/11 20:00, gluster-users-request at gluster.org wrote: > Message: 1 > Date: Sun, 14 Aug 2011 23:24:46 +0300 > From: "Deyan Chepishev - SuperHosting.BG"<dchepishev at superhosting.bg> > Subject: [Gluster-users] cluster.min-free-disk separate for each > brick > To: gluster-users at gluster.org > Message-ID:<4E482F0E.3030604 at superhosting.bg>

...f a pointer is not always log2() of its addressable range - There are some registers that either only store pointers or only store pointer metadata - Loads and stores of pointers may need to be treated differently to loads and stores of data I believe that our case and MPX (which is quite close to HardBounds) are close to being opposite end of the spectrum, so it would be nice if we could come up with a generic design that can support both, as it would then simplify life for any future architectures that have this support. In our case: - Fat pointers are 256 bits - The metadata is stored alongside th...

Hi all, I'm currently adding new instructions and registers to the X86 code generator for Intel Memory Protection Extensions [1]. A class of special-purpose registers BNDx each holds 2 x 64-bit values. The components are not individually readable or writable (except by going through memory) but there are instructions that read only one of the two elements. The two 64-bit values can be

...f its addressable > range > - There are some registers that either only store pointers or only store > pointer metadata > - Loads and stores of pointers may need to be treated differently to loads > and stores of data > > I believe that our case and MPX (which is quite close to HardBounds) are > close to being opposite end of the spectrum, so it would be nice if we > could come up with a generic design that can support both, as it would then > simplify life for any future architectures that have this support. In our > case: > > - Fat pointers are 256 bits > - T...